How to Check SPF, DKIM and DMARC Records (Free, With Evidence)

SPF is a TXT record at the domain root, beginning with v=spf1. DKIM is a TXT record at <selector>._domainkey.<domain>, for example google._domainkey.example.com. DMARC is a TXT record at _dmarc.<domain> and begins with v=DMARC1.

A missing record and a malformed record are different problems. A missing SPF record means no sender is authorised. A record with two v=spf1 strings is ambiguous; publish one. A DKIM record with p= empty is revoked, not valid.

SPF allows at most 10 DNS-querying mechanisms during evaluation. include, redirect, a, mx, ptr and exists can each consume a lookup; includes can nest. A domain can look fine in a one-line checker and still fail at a receiver because the recursive chain exceeds the limit.

If you use several SaaS tools, each one may add an include. The fix is to reduce the chain, use a provider that flattens or manages SPF, or move to a subdomain for a separate sending stream. Do not simply add another include and hope.

DKIM is not one fixed DNS name. The selector is chosen by the sending provider and placed before ._domainkey. Google Workspace commonly uses google; Microsoft 365 commonly uses selector1 and selector2; other providers use their own values.

If the common-selector scan finds nothing, ask the provider for the exact selector and check the public key. A key can also be revoked (p= is empty) or rotated. The checker shows what it found and explicitly says when no common selector matched.

DMARC combines SPF/DKIM alignment with a policy. p=none asks receivers to report but not to block. p=quarantine asks them to treat failing mail as suspicious. p=reject asks them to reject it. The policy can be percentage-limited with pct=.

DMARC only works for messages whose From domain matches the policy domain. A valid-looking record for one domain does not protect a different subdomain unless sp= or a subdomain policy applies. Reporting addresses (rua) are important because they show which legitimate senders are still failing.

DNS records do not reveal inbox placement, sender reputation, content quality, list hygiene or blacklist status. This checker deliberately does not invent those results. It also cannot prove DKIM alignment for a particular message unless it can see the message and its signature.

Use the report as a configuration audit. Then send a real test message to multiple inboxes, check the Authentication-Results header and review DMARC aggregate reports before making a policy change.