SPF, DKIM & DMARC Checker

SPF, DKIM, and DMARC are the three DNS records that decide whether mail claiming to be from your domain is trusted or dropped. They work as a set: SPF says which servers may send for the domain, DKIM cryptographically signs the message so it cannot be altered in transit, and DMARC ties the two to the visible From address and tells receivers what to do when a check fails. Miss one and the other two do less than you think: spoofers slip through the gap, and legitimate mail lands in spam.

This checker queries all three at once from our servers and reports back in plain language. It parses your SPF record and counts the DNS lookups it triggers against the hard limit of ten, reads your DKIM public key and estimates its bit length, and grades your DMARC policy from monitoring-only up to full rejection. One domain in, three verdicts out. No signup, and nothing about your domain is stored.

SPF: which servers may send for your domain

An SPF record is a single TXT record on your domain that starts with v=spf1 and lists the hosts allowed to send mail as you. Each term either names sources directly (ip4:, ip6:) or points elsewhere (include:_spf.google.com pulls in your provider’s ranges, a and mx authorize your own A/MX hosts). A receiving server walks that list and checks whether the connecting IP is covered. The record ends with an all mechanism that catches everything not already matched, and the qualifier on that all is the whole policy in one character.

The qualifiers, from strictest to weakest: -all (hard fail) tells receivers to reject anything from an unlisted source; ~all (soft fail) says treat it as suspicious but still accept, the pragmatic default while you are confident your list is complete; ?all (neutral) expresses no opinion and buys you nothing; and +all explicitly authorizes the entire internet to send as you, which is almost always a misconfiguration that defeats the record’s purpose. Most well-run domains sit at ~all or -all.

The catch that breaks more SPF records than any other is the ten-lookup limit. Every include, a, mx, ptr, exists, and redirect term forces the receiver to do a DNS lookup, and those nest: an include can contain its own includes. RFC 7208 caps the total at ten across the whole chain, and exceeding it is a permerror that makes the entire record fail, silently. This is why large senders publish "flattened" records that inline IP ranges instead of chaining includes. The checker counts your real, recursive lookup total so you know how much headroom is left before you tip over.

DKIM: a signature that proves the message is unaltered

DKIM adds a cryptographic signature to every outgoing message. Your mail server holds a private key and signs each message; the matching public key is published in DNS, and the receiver uses it to verify that the signed parts of the message were not changed after they left you. A valid signature proves two things at once: the message genuinely originated from a system holding your key, and its headers and body arrived intact.

The public key lives at a selector: a label you choose that namespaces the key in DNS, published at <selector>._domainkey.<domain>. Selectors exist so you can run several keys at once (one per sending service) and rotate them without downtime: publish a new selector, switch signing to it, then retire the old one. The selector name is not secret, but it is not discoverable from the domain alone; you find it in your mail provider’s DNS setup (Google uses google, Microsoft 365 uses selector1/selector2, many ESPs use their own) or by reading the DKIM-Signature header of a message you already received, where it appears as the s= tag. This tool can also probe a list of common selectors for you when you don’t know it.

Key length matters. A 1024-bit RSA key was the historical default and is now considered weak: it is within reach of a determined attacker and some providers have begun distrusting it. 2048-bit is the current baseline and what you should publish; some setups use ed25519 keys, which are short but strong. Rotate keys periodically regardless of length, since a key that never changes is a key that never recovers if it leaks. The checker reads your published key and estimates its size so you can tell a modern 2048-bit key from a legacy 1024-bit one at a glance.

DMARC: alignment, policy, and reports

DMARC is the record that makes SPF and DKIM add up to something. It lives at _dmarc.<domain> as a TXT record starting v=DMARC1 and does three jobs: it requires alignment, the domain that passed SPF or DKIM must match the visible From domain, closing the loophole where a message passes SPF for some unrelated domain while still spoofing yours; it declares a policy telling receivers what to do when a message fails; and it requests reports so you can see who is sending as you.

The policy is the p= tag and it is a ladder you climb, not a switch you flip. p=none is monitoring only: receivers still deliver failing mail but send you reports, which is exactly where every deployment should start so you can watch traffic without breaking anything. p=quarantine tells receivers to treat failing mail as suspicious, typically routing it to spam. p=reject tells them to refuse it outright, and is the end state that actually stops spoofing. Two more tags shape the rollout: pct= applies the policy to only a percentage of mail (a way to ramp reject from 10% upward), and a pct below 100 means most failing mail is still getting through.

The rua= tag is where you send aggregate reports: daily XML summaries from receivers listing every source sending as your domain, which pass or fail, and how. Without rua you are enforcing a policy blind; with it you can find every legitimate sender before you tighten to reject, so you don’t accidentally block your own invoices or newsletters. A DMARC record with no reporting address is the single most common reason a rollout stalls at p=none forever.

Deploying the three in the right order

The order matters because each record depends on the ones before it. Get SPF and DKIM passing and aligned first, then layer DMARC on top in monitoring mode, then tighten. Rushing straight to p=reject before you have confirmed every legitimate sender is aligned is how you block your own mail.

A minimal, correct starting point looks like the records below: an SPF record that authorizes your provider and soft-fails the rest, a DKIM key published at your provider’s selector, and a DMARC record in monitoring mode with a reporting address so you can watch before you enforce.

• Publish SPF first: list every sending source and end with ~all, e.g. v=spf1 include:_spf.google.com ~all. Re-check the lookup count stays under ten.
• Add DKIM: enable signing at your mail provider and publish the public key at the selector it gives you (e.g. google._domainkey.example.com). Prefer a 2048-bit key.
• Add DMARC in monitoring mode: v=DMARC1; p=none; rua=mailto:[email protected]. Collect reports for a few weeks and confirm all real senders pass.
• Tighten gradually: move p=none → p=quarantine → p=reject, optionally ramping with pct=, only once the reports show every legitimate source is aligned.