SPF, DKIM & DMARC checker

Why these three records decide your fate

Cold email copy gets endless attention while authentication gets almost none, which is backwards. A domain with no DMARC record sending from a fresh IP will land in spam no matter how well the email is written. These records are the foundation everything else sits on.

Since 2024, Google and Yahoo have required SPF, DKIM and DMARC for bulk senders. Cold outreach at any volume falls squarely inside that.

What each one does

SPF — who is allowed to send

A DNS record listing the servers permitted to send as your domain. Two failure modes matter: having more than one SPF record breaks it entirely (receivers return a permanent error rather than merging them), and ending in +all authorises the whole internet — worse than having none.

DKIM — proof it was not altered

A cryptographic signature on each message, verified against a public key in your DNS. Records live at selector._domainkey, and selectors cannot be enumerated — so this tool probes the eleven most common ones, chosen by measurement rather than guesswork. A custom selector will not show up, which is why a negative result here is a prompt to check, not a verdict. We measured how much that caveat is worth across 4,879 domains: it depends almost entirely on your mail provider, ranging from 3.8% of Amazon SES domains exposing a guessable selector to 97.2% on Cloudflare. Where we can identify your provider, the result above says which case you are in.

DMARC — what to do when checks fail

Ties SPF and DKIM together and tells receivers how to treat failures. p=none monitors only, p=quarantine sends failures to spam, p=reject blocks them. Start at none with a rua= reporting address, read the reports, then tighten.

The SPF limit most checkers do not count

This is the check that made us build the tool. RFC 7208 §4.6.4 allows an SPF evaluation to make at most 10 DNS lookups. The include:, a, mx, ptr and exists mechanisms each cost one, and the count carries recursively into every policy you include. Go past ten and a conforming receiver returns permerror: SPF stops authenticating your mail entirely.

The dangerous part is what that looks like from outside — nothing. The record is still there, still parses, and every “do you have SPF?” checker still says yes. You have simply stopped being authenticated, and the only symptom is mail landing in spam for reasons nobody can explain. Each SaaS tool you add costs a lookup, so domains drift over the line years after anyone last touched the record.

We resolved the SPF policies of the top 5,000 domains on the web to see how common this is. Of the 3,708 that publish SPF, 92 are already over the limit and 20 publish more than one SPF record — also a permanent error — for 3.0% broken in total. 139 sit at exactly ten, one added tool from breaking, including GitHub, eBay, Oracle, Intuit and MIT. Full study and the harvesting script. The checker above counts your policy recursively and shows the total against the limit.

If you are over, the usual advice is to “flatten” your record — replace include: mechanisms with the ip4: ranges they resolve to. That works, and it trades a DNS problem for a maintenance one: when your provider changes their sending IPs, your flattened record is silently wrong and nothing tells you. Removing senders you no longer use is the cheaper fix and worth trying first.

Two false positives we deliberately avoid

Both are cases where a record exists and a naive check reports success.

A revoked DKIM key still looks configured

RFC 6376 uses an empty p= to signal that a key has been revoked. The DNS record is still published, so a checker looking only for “does a record exist?” reports DKIM as configured while mail signed with that key fails verification. That is worse than having no record at all, because it looks fine. We report it as a failure, not a pass.

Null MX means the domain accepts no mail

RFC 7505 defines a single MX of 0 . as an explicit declaration that a domain receives no mail. Counting that as a working mail server is wrong. The trap is priority zero on its own being harmless — ietf.org publishes 0 mail2.ietf.org., a real host at priority zero — so the check requires the target to be exactly . before calling it null.

The check that leaves DNS: MTA-STS

SPF, DKIM and DMARC all authenticate the message. None of them protects the connection. An attacker positioned on the network can strip the STARTTLS upgrade and read the mail in plaintext, and every one of those three records still passes. MTA-STS (RFC 8461) is the standard that closes that gap.

It is also the only mail standard that needs two independent things right at once: a DNS record at _mta-sts, and a policy file served over HTTPS at mta-sts.yourdomain.com/.well-known/mta-sts.txt. The DNS half is the half every checker looks at, and it is the half that tells you least — the word enforce only ever appears in the file.

We measured the gap across 5,000 domains: 133 announce MTA-STS and 70 enforce it. So this checker fetches and parses the policy rather than trusting the record, and reports the four ways to announce MTA-STS and be protected by none of it:

• Testing mode.Senders report TLS failures and deliver anyway. It is the RFC's recommended first step and it enforces nothing. If there is also no TLS-RPT record, there are no reports either, so it is not a stage on the way to enforcement — it is a permanent no-op, and we say so.
• A policy that is never served. The record is published and the file 404s, times out, or the mta-sts hostname has no address at all. We name which, because a 404 and a certificate error are different mistakes with different fixes.
• HTTP 200 carrying something that is not a policy.A live domain in our sample serves an HTML page at the policy URL. Any checker that asks “is the file reachable?” passes it. Reachability is not validity.
• An enforce-mode policy that does not cover your live MX.The rare dangerous one: a sender obeying it refuses your real mail servers, so it breaks delivery rather than merely failing to protect it. We compare the policy's mx: patterns against your current MX hosts, treating a leading *. as covering exactly one label, as RFC 8461 §4.1 requires.

Redirects are deliberately not followed. RFC 8461 §3.3 forbids it, so a policy you can only reach through a 3xx is one a real sending server will not use — reporting it as protection would be reporting something that does not exist.

A reasonable starting DMARC record

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:you@yourdomain.com

p=none changes nothing about delivery — it only asks receivers to send you reports. That makes it safe to add today, and it starts the data collection you need before tightening the policy.

Is my domain data stored?

No. The lookup reads public DNS records and returns them. Nothing is logged or retained, and every record this tool reads is already publicly visible to anyone who queries DNS.

Records in order? The next constraint is usually warmup and mailbox rotation, which is what a sending platform handles. Our tool finder matches you to one, or check your copy with the spam word checker.