How to Check SPF, DKIM, and DMARC Records for Any Domain

Email authentication is one of those things that looks simple on paper and silently breaks in production. You set up SPF, DKIM, and DMARC. You run an online checker. Everything passes. Then six months later, a DNS migration quietly removes your DMARC record and you only find out when spoofing starts appearing in your aggregate reports.

This happens more often than most practitioners admit. Here is how to check your records right now, and more importantly, how to catch the next failure before it becomes a problem.

The gap most people hit is not the initial setup. It is the months after, when no one is watching. A tool like DMARCFlow monitors your aggregate reports continuously and flags new sending sources, climbing failure rates, and records that stop appearing. That is what one-off checks cannot provide - ongoing visibility into whether your authentication is actually holding.

What SPF, DKIM, and DMARC Actually Do

Before the commands, a quick recap of what each record protects against.

SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses are allowed to send email for your domain. If a server is not on the list, receivers can treat it as unauthorized.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your outbound email. Receivers verify the signature using a public key published in your DNS. If the signature does not verify, the message was altered in transit or sent by someone without your private key.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM. It tells receivers what to do with messages that fail one or both checks. It also requests aggregate reports about authentication results so you can see who is sending email on behalf of your domain.

Each record handles a different piece of the problem. SPF handles source verification. DKIM handles message integrity. DMARC handles policy and visibility.

How to Check SPF, DKIM, and DMARC Right Now

For a one-off check, these are the methods practitioners actually use.

Check SPF with dig


dig TXT yourdomain.com | grep -v "^;"

Or:


nslookup -type=TXT yourdomain.com

Look for an SPF record that starts with "v=spf1". That is your SPF record. It should list all the services and servers authorized to send email for your domain.

A minimal passing SPF record looks like this:


v=spf1 include:_spf.google.com ~all

The "~all" means softfail - receivers should be lenient with emails that fail. A stricter record would use "-all" for hard fail, but that requires a complete sender inventory first.

Check DKIM with dig

DKIM keys are published under a selector prefix. The most common selector is "selector1", but your email service may use something different.


dig TXT selector1._domainkey.yourdomain.com

If the domain uses Google Workspace, the selector is typically "google". For Microsoft 365, it is usually "selector1" and "selector2". Check your email headers for the "dkim-signature" field - it will contain the "s=" selector value.

A DKIM record looks like this:


v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA...

The "p=" field is your public key. If it is empty or missing, your DKIM is not published.

Check DMARC with dig


dig TXT _dmarc.yourdomain.com

A basic DMARC record looks like this:


v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The "p=" value is your policy. "none" means you just want reports. "quarantine" tells receivers to treat failing mail as suspicious. "reject" tells them to refuse it outright.

The "rua" parameter specifies where aggregate reports are sent. If you have no "rua=" entry, you are flying blind - no reports, no visibility.

Online Checkers

If you prefer a web interface, MXToolbox and Port25's Mail Auth Analyzer both pull all three records at once.

MXToolbox: https://mxtoolbox.com/SuperTool.aspx
Port25: https://www.port25.com/dmarc-analyzer/

These are useful for a quick check. They do not replace ongoing monitoring.

Why One-Off Checks Are Not Enough

Setting up SPF, DKIM, and DMARC correctly and then never looking at them again is where most practitioners get into trouble.

The records do not update themselves when your sending infrastructure changes. Here are the most common silent failures.

SPF lookups exceed 10. The SPF specification limits the number of DNS lookups a receiver will follow to 10. Every "include:" directive counts as a lookup. If your SPF record has too many includes, receivers simply stop processing it and treat the result as a failure. This commonly breaks when marketing platforms add themselves to your SPF record without you noticing, one include at a time.

DNS migrations remove your DMARC record. When moving DNS hosting or making bulk DNS changes, it is easy to copy SPF and A records but forget DMARC. The domain continues sending email. SPF still passes. DKIM still passes. But DMARC is gone, and you have no visibility into what is actually happening with your email authentication.

DKIM keys expire. Some email services rotate DKIM keys on a schedule. If the rotation process breaks and your public key is not updated, DKIM verification fails silently. Your emails pass SPF but fail DKIM alignment, which means DMARC fails even though both records look correct individually.

SPF records get overwritten. When another team member updates DNS and does not realize an SPF record already exists, they may add a second TXT record instead of updating the existing one. Two SPF records mean neither is authoritative, and receivers may reject both.

These failures do not generate bounce messages. You do not get a Slack alert. You only know something is wrong when your domain appears in someone else's spoofing reports, or when email deliverability drops for no obvious reason.

How to Set Up Ongoing Monitoring

One-off checks catch the state of your records at a moment in time. What you need is continuous visibility.

DMARC aggregate reports are the answer. When you publish a DMARC record with an "rua=" parameter, participating receivers send you daily XML reports summarizing authentication results for your domain. These reports tell you:

Which servers are sending email for your domain
What percentage of that email passes SPF, DKIM, and DMARC alignment
Which receivers are seeing failures and why
Whether third parties are sending unauthenticated email using your domain

Without these reports, you are guessing about your email authentication posture. With them, you can catch problems within hours rather than weeks.

Reading a DMARC aggregate report. The XML format is dense. A typical report covers a 24-hour window and lists each sending source with pass/fail counts for SPF, DKIM, and alignment. The key sections to check:

"source" org: which organization sent the report
"policy_evaluated": what the receiver concluded (pass or fail, and why)
"auth_results": detailed SPF and DKIM outcomes for each sending IP

Reviewing these manually is time-consuming. Tools that parse and summarize the reports make the process practical.

DMARCFlow processes DMARC aggregate reports automatically and flags anomalies: a new sending source that was not there last week, an authentication failure rate climbing above your baseline, a domain you do not recognize appearing in your reports. This is what one-off checks cannot provide.

Moving from p=none to p=quarantine (Or p=reject)

Most domains start with "p=none" in their DMARC record. This collects reports without changing how receivers handle your email. It is a monitoring mode, and it only works if someone is actually watching those reports.

Without ongoing monitoring, p=none tells receivers to collect reports and then does nothing with them. You may have DMARC failures happening right now and not know it. A vendor may be sending email that is not DKIM-aligned. A DNS change may have broken your SPF alignment. You will not find out until something goes wrong.

Moving to "p=quarantine" tells receivers to treat failing email as suspicious. Moving to "p=reject" refuses it entirely.

Neither step is trivial. Before you change your policy, you need to know what is actually sending email using your domain. If you have a third-party vendor sending marketing email that is not DKIM-aligned, a hard reject policy will bounce it. If you have internal systems sending transactional email without SPF or DKIM, the same thing happens.

The practical path:

1. Run at p=none for at least 30 days to establish a baseline
2. Review aggregate reports to identify all legitimate sending sources
3. Ensure every legitimate sender has valid SPF or DKIM alignment
4. Move to p=quarantine and watch for two weeks
5. Move to p=reject if no failures appear

If aggregate reports show failures after moving to quarantine, investigate before moving to reject. The failures are telling you something legitimate is misconfigured.

Quick Checklist

Before you close this tab:

1. Run a DMARC check on your domain using an online tool. Note whether you have an "rua=" entry. If not, add one today.
2. Open your last DMARC aggregate report. Check whether any new sending sources appeared that you do not recognize.
3. Count your SPF includes. If you are near 10, simplify before adding more.
4. Pick a date 30 days from now to review your DMARC reports again. Put it in the calendar.

The records you set up today will not maintain themselves. The practitioners who avoid email authentication problems are the ones who built in a way to catch the next failure.

FAQ

How often should I check my SPF, DKIM, and DMARC records?
At minimum, check manually after any DNS change or email service update. Better: set up DMARC aggregate report monitoring so you receive reports automatically and can review them monthly without running commands.

What does it mean if my SPF check shows two TXT records?
Two SPF records for the same domain is an error. Receivers may process either one unpredictably, which can cause intermittent failures. Remove the duplicate and keep only one SPF record.

My DMARC record has p=none. Does that mean my email is protected?
No. p=none collects reports but does not instruct receivers to take any action on failing email. Your domain is still open to spoofing. Think of p=none as a visibility tool, not a protection policy. And visibility only helps if someone is watching the reports - which is why ongoing monitoring matters more than the policy setting itself.

What causes DMARC to fail silently?
Common silent failures include: DMARC record removed during DNS migration, DKIM key rotation that did not propagate, SPF record overwritten by a second TXT record, or sending infrastructure changes that break alignment. Aggregate reports catch most of these. One-off checks do not.

How do I read a DMARC aggregate report without a tool?
Open the XML file in a text editor. Look for the "record" entries. Each record has a "row" section (source IP, count, policy result) and an "auth_results" section (SPF and DKIM details). For most users, a parsing tool is worth the setup time.

---

Oliver H.-Gary has been working with email authentication since the early days of DMARC adoption. He has seen what breaks when monitoring stops.