DMARC, SPF & DKIM Checker

SPF publishes which servers may send mail for your domain; receivers check the connecting server against it. DKIM signs each message cryptographically with a key whose public half sits in DNS, proving the content was not altered. DMARC ties both to the visible From address (alignment), tells receivers what to do when checks fail, and requests reports. You want all three: SPF alone breaks on forwarding, DKIM alone does not stop spoofed From headers, and DMARC without the other two has nothing to enforce.

RFC 9989, published in May 2026, replaced the original 2015 DMARC specification (RFC 7489). The biggest mechanical change is discovery: instead of a Public Suffix List guess at the organizational domain, receivers now perform a DNS Tree Walk, querying _dmarc names up the DNS tree. Tags also changed: pct, rf and ri were removed, and t, np and psd are current. This checker implements the Tree Walk, shows every name it queried, and marks retired tags with migration advice instead of explaining them as current controls.

RFC 7208 allows at most 10 DNS-querying terms (include, a, mx, ptr, exists, redirect) across the whole evaluation, counted every time a term is evaluated, plus at most 2 void lookups. Go over and receivers return a permanent error, which can make SPF fail for all your mail. Every include you copy from a provider brings its own nested includes, so the tree adds up fast. This checker walks the full tree recursively, shows each branch, and reports capped or unresolved traces as Incomplete rather than pretending they passed.

No, and this tool deliberately never says "pass" for DKIM. A published record at a selector proves exactly one thing: a structurally valid public key exists in DNS. It does not prove outgoing mail is signed, that the mail server uses this selector, that signatures verify, or that the signing domain aligns with your From address. Those require checking a real message. What this tool does verify: the record grammar, the base64, the actual DER-decoded key type and size, revoked and test-mode flags.

DNS has no way to enumerate them; a selector is an arbitrary name the sender chooses, like google or s1. When you leave the selector field empty, this tool tries a short list of common names and reports exactly that: no record found at N guessed selectors, which is not evidence that DKIM is absent. The reliable way to find your selector is to open a message you sent and read the s= tag inside the DKIM-Signature header.

Not during rollout; it is the correct first step. Publishing p=none with a rua reporting address gives you visibility into every source sending as your domain without risking legitimate mail. The staged path: publish p=none with reports, watch the reports, fix SPF and DKIM alignment for every real sender, then move to quarantine and eventually reject. Jumping straight to reject before alignment is clean is how companies block their own invoices.

Straight from your browser to Cloudflare DNS-over-HTTPS (cloudflare-dns.com), not through DevDome servers, and checked domains are never sent to analytics. The trade-off is that you see one resolver's view of DNS at one moment, which can differ from other resolvers during propagation. Each result shows the resolver and the query time for exactly that reason.

Because something in it is invalid, and publishing an invalid SPF record can break mail delivery. The generator validates every IP octet and prefix length (999.999.999.999/99 is not an address), checks include targets, re-parses the finished record through the same engine the checker uses, and counts DNS lookups before enabling copy. It also imports your existing record first and merges instead of replacing, so authorized senders you already have do not silently disappear.