How to check SPF, DKIM and DMARC records

How do you check an SPF record from the command line?

SPF lives as a TXT record at the domain's own name, so query the domain directly:

dig TXT example.com +short
nslookup -type=txt example.com

A domain can have several unrelated TXT records at the apex (domain verification strings, other services), so look specifically for the one starting with v=spf1. If more than one TXT record starts with v=spf1, that is itself a problem: RFC 7208 treats multiple SPF records on the same name as an error, not something to be merged automatically. See what an SPF record is for what each mechanism and qualifier in the result means, and check its ending in particular - a record closing in +all authorizes literally anyone and is worth fixing before anything else.

How do you check a DKIM record when you know the selector?

DKIM keys live at selector._domainkey.domain, so the selector has to be known first. With it in hand:

dig TXT google._domainkey.example.com +short

A working record starts with v=DKIM1 and includes a p= value holding the public key; an empty p= means the key was deliberately revoked, and no answer at all means that selector is not configured. Some providers, notably Microsoft 365, publish the selector as a CNAME pointing at their own infrastructure rather than a TXT record directly - dig follows that automatically and still returns the underlying key data. See what DKIM is for where to find a selector you do not already know, most directly from the DKIM-Signature header of a message the domain sent.

How do you check a DMARC record?

DMARC always lives at a fixed subdomain, regardless of what the domain itself is:

dig TXT _dmarc.example.com +short

No answer at all means no DMARC record is published, which is common but leaves receivers with no instructions for handling mail that fails alignment. A record that exists but reads p=none is only in monitoring mode; see what DMARC is for how the three policies differ and how alignment between SPF, DKIM and the visible From: address decides pass or fail.

How do you read the Authentication-Results header on a message you received?

DNS lookups show what a domain published; they do not show what happened when a real message was delivered. That evidence lives in the Authentication-Results header, defined in RFC 8601 and added by the receiving mail server before the message reaches an inbox. Opening a message's full headers (in Gmail, "Show original"; in Outlook, the message details view) typically shows something like:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Each check reports its own result independently - pass, fail, softfail, neutral, none or an error code - along with which domain it evaluated (smtp.mailfrom= for SPF, header.d= for DKIM, header.from= for the address DMARC compared everything against). A message can show spf=pass and still show dmarc=fail, which is exactly the alignment gap described in the DMARC guide above: SPF passed for a domain that does not match what DMARC compared it to. Reading this header on a genuine delivered message is the only way to see the actual verdict, since receiving providers apply their own additional checks and reputation signals that a DNS lookup alone cannot show.

What order should you fix problems in?

Fix records in the order a message is actually evaluated: SPF and DKIM first, since DMARC's alignment check has nothing to align if neither one is passing yet, then DMARC last, and only once the first two are solid. Concretely:

1. Confirm SPF exists, is a single record, lists every real sending source, and does not end in +all.
2. Confirm DKIM is configured and actively signing outgoing mail, not just published in DNS with nothing using it.
3. Send a real test message through every sending source the domain uses and check the Authentication-Results header on each one, since a source that looks fine on paper can still fail in practice.
4. Only then add or tighten DMARC, starting at p=none with reporting turned on, and move to quarantine and reject in steps once the reports confirm every legitimate source is aligned.

What are the most common failures, and how do you spot them?

• A second SPF record. Someone added a new sending service by publishing a brand-new TXT record instead of editing the existing one. The fix is merging both into a single record with one include or mechanism per service, then deleting the duplicate.
• A DKIM selector that does not resolve. The signing system is stamping a DKIM-Signature header with a selector whose DNS record was never published, was deleted during a migration, or has a typo. dig against the exact selector named in s= shows this immediately - no TXT answer means the signature can never verify no matter how correct the signing itself is.
• DMARC stuck at p=none indefinitely. The record was added, reports started arriving, and nobody went back to read them or tighten the policy. This provides visibility but stops no forged mail at all; treat p=none as a temporary monitoring phase with a planned end date, not a finished state.
• SPF passing while DMARC fails. Usually a marketing or forwarding platform sending with its own envelope domain while showing the customer's domain in From:. The Authentication-Results header makes this visible directly: spf=pass paired with dmarc=fail on the same message is the signature of an alignment problem, not a broken SPF record.

Where to check the records that feed into this

The DNS lookup tool queries TXT records - the record type SPF, DKIM and DMARC all use - from HostTracker's network of checkpoints, useful for confirming a record change has reached the resolvers being checked from. The MX lookup tool lists a domain's mail servers and can check each one's port 25 status and DNS blacklist standing on demand, which is a separate but related question from whether outgoing mail is properly authenticated. HostTracker has monitored websites since 2004, checks from 300+ checkpoints in 158 cities, and can alert by email, SMS, voice call, Slack, Telegram and more when a monitored check changes state.

Frequently asked questions

Do I need to check SPF, DKIM and DMARC every time I send a campaign?

No, these are DNS-level configuration checks, not something that changes per message. Recheck them after adding a new sending platform, migrating DNS providers, or when delivery problems appear with no other obvious cause.

Why does dig sometimes return nothing for a record I know exists?

A recently changed record can still be cached as empty or as its old value at some resolvers until the cache entry's TTL expires. Query from more than one location, or wait past the TTL, before concluding the record is genuinely missing.

Can a message fail DKIM but still pass DMARC?

Yes, since DMARC only requires that at least one of SPF or DKIM pass and align, not both. A message with a broken DKIM signature but an SPF pass that aligns with the visible From: domain still passes DMARC overall.

What does dkim=neutral or spf=none mean in Authentication-Results?

These mean the check reached no definite verdict rather than an outright failure - none for SPF usually means no SPF record was found at all, and neutral for DKIM commonly means the message carried no DKIM signature to evaluate in the first place. Both point at a missing record or missing signature rather than a broken one.

Is a DNS lookup enough to prove email authentication is working?

It proves the records are published correctly, but only a real delivered message's Authentication-Results header proves they actually worked for that message, at that receiving provider, from that sending source.