SPF / DKIM / DMARC Checker

Email authentication lives entirely in DNS, which is why it breaks quietly and gets discovered when messages start landing in spam. This checker reads the SPF, DKIM and DMARC records for a domain and lays them out so you can see what is published, whether the syntax holds up, and whether the policy is strict enough to be worth anything.

SPF is a single TXT record at the root of the domain listing who may send on its behalf, for example v=spf1 include:_spf.google.com ip4:203.0.113.10 -all. Receivers check the envelope sender — the MAIL FROM address, not the From: header the recipient sees — against that list. Two details cause most SPF failures. The first is the qualifier at the end: -all is a hard fail, ~all is a soft fail that says “probably not us, deliver anyway”, and +all is functionally the same as publishing nothing. The second is the ten-DNS-lookup limit. Every include, a, mx, ptr, exists and redirect counts against it, and once the chain exceeds ten the record is a permerror, which many receivers treat as no SPF at all. Stack Google Workspace, a CRM, a helpdesk and a marketing platform and you will cross that line without noticing; flattening the record or moving senders onto subdomains is the fix.

DKIM signs the message itself rather than authorising an IP. Your sending platform holds a private key, adds a DKIM-Signature header covering the body and a chosen set of headers, and publishes the matching public key at selector._domainkey.yourdomain.com. The selector is just a label — google, k1, s1, mail — and it is the piece people cannot find, because it only exists in the headers of a message that platform actually sent. Send yourself a test, open the raw source, and the s= tag in the DKIM-Signature line names the selector. Use 2048-bit keys; 1024 is still accepted but on the way out. Signatures also break when something in transit rewrites the message, which is why mailing lists that append a footer or prefix the subject cause DKIM failures that are not your fault.

DMARC is where the two are tied back to the domain the recipient actually sees. Published at _dmarc.yourdomain.com as something like v=DMARC1; p=none; rua=mailto:reports@yourdomain.com, it does two jobs: it tells receivers what to do when authentication fails, and it requires alignment — the domain that passed SPF or DKIM must match the From: header domain. Alignment is the part that surprises people. A message can pass SPF cleanly and still fail DMARC, because the envelope sender was bounces@sendgrid.net while the From: header said you@yourdomain.com. Only one of the two needs to pass and align, which is why DKIM is the more durable mechanism: it survives forwarding, and SPF frequently does not.

Roll DMARC out in stages. Publish p=none first and read the aggregate reports for a few weeks — they arrive as XML from every major receiver and show which sources are sending as your domain and whether they align. There are always two or three that nobody remembered: an old invoicing system, a monitoring tool, a form on a legacy site. Move to p=quarantine, then to p=reject, once the legitimate senders are all passing. Going straight to p=reject is a fast way to find those forgotten systems, and an expensive one. The pct= tag lets you ramp a policy across a fraction of mail while you watch the reports.

Reading the results: an SPF record that exists but ends in ~all is doing very little on its own. A DMARC record at p=none is a monitoring configuration, not a protection — spoofed mail still gets delivered. Two v=spf1 records on the same domain is a permerror, not a merge, and it happens whenever someone adds a second provider by creating a new TXT record instead of editing the existing one. A DKIM lookup only works if you supply the selector, so an empty result usually means the wrong selector rather than a missing key.

Other things that regularly go wrong: publishing the DMARC record at yourdomain.com instead of _dmarc.yourdomain.com; a DNS panel that appends the domain again so the host ends up as _dmarc.yourdomain.com.yourdomain.com; forgetting sp= so subdomains inherit a policy you did not intend; and leaving parked or unused domains without an SPF -all and a DMARC p=reject, which makes them ideal for spoofing precisely because nobody watches them. Note also that a domain does not need an MX record to send mail — but if it doesn’t receive mail, publishing a null MX and a strict SPF closes off a whole category of abuse.

This tool reads public DNS, so it reflects what receivers can see, subject to TTL and resolver caching after a change. Treat it as a pre-flight check rather than a deliverability audit: authentication is necessary but not sufficient, and IP reputation, list hygiene, complaint rates, content and engagement all still decide where mail lands. It does not evaluate BIMI, ARC or MTA-STS, and it cannot tell you whether a specific message you sent passed — for that, read the Authentication-Results header on a delivered copy, or your DMARC aggregate reports.