Live lookups against public resolvers, the same ones a mailbox provider uses. Nothing is stored and no account is needed. Twenty checks an hour.
The two failures worth checking for
Most authentication problems in cold email are not missing records. They are records that exist, look correct in the registrar interface, and fail anyway. Two causes account for most of them, and both produce a permanent error, which means the receiving system cannot evaluate SPF at all rather than merely evaluating it as a soft fail.
Two SPF records on the same host. One arrives with the website host, another with the mail provider, and each is valid on its own. Published together they are a permanent error. The fix is a merge: one record, one v=spf1, every include inside it. This checker lists every v=spf1 record it finds rather than the first, which is how you see the problem at all.
An include chain past ten DNS lookups. Every include, a, mx, ptr, exists and redirect costs one lookup, includes nest, and the eleventh fails the record. A chain that worked with one provider breaks silently when a second is added, and nothing in a registrar dashboard counts for you. This checker walks the chain and reports the number.
Reading the four cards
- SPF passes when exactly one record is served, it ends with ~all or -all, and the chain stays inside ten lookups. A record without a fail qualifier allows any sender, which defeats the point of publishing one.
- DKIM is probed at the common selectors. A hit proves a key is published; it does not prove the provider is signing with it. Confirm that in the provider's own console, and remember that Microsoft's CNAME target contains a per-tenant value that has to be read from the tenant rather than copied from a guide.
- DMARC passes when a policy is enforcing. p=none is a legitimate starting point and a bad resting point.
- MX passes when the domain can receive mail at all, which it needs in order to collect replies and bounces.
What a clean score does not tell you
Authentication is the entry requirement, not the outcome. A domain scoring one hundred here can still land in spam, because placement is decided by sending history: how long the mailbox has been sending, how much, how suddenly that changed, how many recipients reply, and how many press the spam button. Google publishes the one threshold that matters, a complaint rate under 0.1 percent and never above 0.3 percent, and no DNS record moves it.
If the records pass and the mail still lands wrong, the next places to look are the warm-up, the daily volume per mailbox, and the list. The spam words checker covers the content side, which matters least of the four and is the only one you can fix in five minutes.
Questions, answered straight
- What does this checker do that others do not?
- Two things that decide whether cold email authenticates at all. It reports every v=spf1 record served at the apex rather than the first one it finds, so a second record shows up as the permanent error it is. And it walks the include chain and counts the DNS lookups the record costs, because the eleventh lookup fails the domain exactly like a duplicate record does. Both look perfectly fine in a registrar dashboard.
- Why does my domain show DKIM missing when my mail is signed?
- The checker probes the selectors providers commonly use: selector1, selector2, google, s1, s2, k1, default, dkim and mail. A domain signing with a private selector is signed correctly and will still show missing here. Read the Authentication-Results header on a message you actually sent to settle it.
- Is a DMARC policy of p=none a failure?
- Not a failure, but not finished either. p=none tells receivers to do nothing and send you reports, which is the right place to start and the wrong place to stop. After two clean weeks of reports, move to p=quarantine. For a dedicated cold-sending domain, quarantine is a sensible destination and reject adds little.
- Why does MX matter on a domain that only sends?
- Because a domain that cannot receive cannot collect bounces, out-of-office replies or the actual replies you are sending to get. It is also a signal in its own right: a sending domain with no way to receive looks like exactly what it is.
- Does this send any email?
- No. Every answer on this page comes from DNS lookups against public resolvers. Nothing is sent, nothing is stored, and no account is needed. A placement test, which answers whether mail lands in the inbox or in spam, genuinely needs seed mailboxes at each provider and is a different thing entirely.
- How often can I check?
- Twenty checks an hour from one address, which is plenty for a fleet you are setting up and not enough to be useful as someone else's bulk scanner.
Published 19 September 2026. Updated 19 September 2026. Written by the team that runs the infrastructure; numbers come from the platform's own provisioning and sending, and from the providers' published documentation at the time of writing.