SPF, DKIM and DMARC checker
Enter a domain to check SPF record contents, DKIM selectors and the DMARC policy at once. It says what each one actually does, and counts SPF's ten-lookup limit: the failure that breaks mail while the record still looks perfectly fine.
The ten-lookup limit, which is where mail actually breaks
An SPF record may cost at most ten DNS lookups to
evaluate, and that budget includes everything your include:
statements pull in, and everything those pull in. Add one more
provider and you can cross the line without touching the record itself.
Past ten, the record is a PermError. Receivers treat it as
though you published no SPF at all, so mail that used to pass starts
failing, while the record still reads correctly to a human and still
shows as "found" in most checkers. This is the single most common way a
working SPF setup breaks silently.
Most SPF record checkers stop at "found": they confirm a record exists and parse its syntax, which is the part that was never in doubt. The table above shows the whole include chain and what each step costs, so you can see which one spent the budget rather than only that it was spent. SPF record syntax lists every mechanism and what it costs.
What each record does
The three answer three different questions, which is why a domain can pass one and fail the others without anything looking obviously broken.
- SPF lists the servers allowed to send as your domain. An SPF checker answers "is this server permitted", and, if it is thorough, whether the record can still be evaluated at all.
- DKIM signs messages with a key published in DNS. A DKIM checker answers "was this message altered in transit", by confirming the public key for a selector is really published.
- DMARC ties the two to the visible From address and tells receivers what to do when they fail. A DMARC checker reads that policy; without one, SPF and DKIM are advisory.
All three are needed. SPF alone does not protect the address a recipient actually sees, which is the one being spoofed.
Two settings nearly everyone gets wrong
~all versus -all. A soft fail
(~) asks receivers to accept the mail but mark it; a hard
fail (-) asks them to reject it. Start with ~all
while you are still discovering which services send on your behalf, and
move to -all once you are sure. Ending with +all
authorises the entire internet and is worse than publishing nothing.
p=none does nothing. It is monitoring only:
you get reports, and receivers take no action. Plenty of domains publish
DMARC, never move past p=none, and believe they are
protected. A DMARC record checker that reports this as "DMARC found" is
telling you almost nothing, so the verdict here names the policy. Read the
reports, confirm your own mail passes, then move to
p=quarantine.
About the DKIM check
DKIM offers no way to discover which selectors a domain uses, so this
tries a list of common ones. Finding none does not mean DKIM is missing: it may simply use a name not on the list. To find yours, open any message
you sent, look at the DKIM-Signature header, and read the
s= tag.
Nothing is sent to us
Every lookup here is a DNS query made by your browser directly to Cloudflare, exactly as with the DNS lookup. The domain you type never reaches a Kodura server, because there is no server involved.