We recently went back through the validation logic behind our free Email Security Checker and found it was too generous. It confirmed a TXT record started with v=spf1 and called SPF "Pass." It found v=DMARC1 anywhere in a string and called DMARC "configured." Neither check reflected how mail servers actually evaluate these records against the RFCs.
We rebuilt the checks against RFC 7208 (SPF), RFC 7489 (DMARC), and RFC 6376 (DKIM), and tested them against real, public domains along the way. Here are five edge cases that a surface-level checker will pass right by — none of them hypothetical.
1. Multiple SPF records silently break authentication for everyone
RFC 7208 permits exactly one SPF record per domain. If a domain has two, receiving mail servers are required to return a PermError — and that failure applies to every message from every legitimate sender on that domain, not just whichever record is "wrong."
This is an easy trap to fall into. A common cause is switching email providers: the old provider's setup guide added one SPF record, the new provider's guide added another, and nobody removed the first. A checker that just finds the first record starting with v=spf1 and calls it good will report a clean pass on a domain that is, in practice, completely broken for SPF purposes.
2. The "+all" mechanism quietly authorizes anyone
An SPF record ends with a mechanism — -all, ~all, ?all, or +all — that tells receivers what to do with mail from a server not on the approved list. -all (hard fail) and ~all (soft fail) are the two you want. +all means "allow all," which authorizes literally any server on the internet to send mail as your domain. It defeats the purpose of having SPF at all.
+all is rare in real production traffic, but it's an easy record to end up with — it's the kind of thing that gets copy-pasted from an outdated tutorial or left over from testing. A checker that only confirms an SPF record exists, without reading how it ends, will report "Pass" on a record that authorizes anyone to spoof the domain.
3. SPF has a 10-lookup budget — and a normal vendor stack can hit it
Every include, a, mx, ptr, and exists mechanism, plus the redirect modifier, causes a DNS lookup — and RFC 7208 §4.6.4 caps the total across the entire record, resolved recursively through every included domain, at 10. Go over, and the result is a PermError, which breaks SPF for every sender on the domain, not just the one that pushed it over the edge.
This is easy to miss because checking it properly means resolving every include: chain recursively, not just reading the top-level record. When we tested this against real domains, we found github.com's public SPF record — once every include chain (Microsoft, Google, Zendesk, Salesforce, Mailchimp, Marketo, and SendGrid, among others) is fully resolved — sits at exactly 10 of the 10 lookups allowed. That's not a mistake on GitHub's part; their record is valid today. It's a useful, real illustration of how little headroom the limit actually gives a company running a normal-sized stack of SaaS email tools, and why it's worth checking before adding one more vendor.
4. "redirect=" is valid SPF — and looks broken if you don't follow it
hubspot.com's published SPF record is simply:
v=spf1 redirect=_hspf.hubspot.com
There's no all mechanism anywhere in that record. To a checker that only looks for a terminating mechanism at the domain root, this looks incomplete or misconfigured. It isn't — per RFC 7208 §6.1, redirect= hands off the entire policy, enforcement included, to another domain's SPF record. HubSpot's actual enforcement (a properly hardened -all) lives one hop away, at _hspf.hubspot.com. A checker needs to know to follow that pointer before it can say anything meaningful about the policy.
5. Null MX and revoked DKIM keys look like failures but aren't
Two RFC-defined signals are easy to mistake for missing configuration if you don't know to look for them specifically:
- RFC 7505 defines a "null MX" — a single MX record pointing to
.— as the standard way for a domain to declare it does not accept email at all. This is intentional, not an oversight, on domains that only send mail (or none). - RFC 6376 defines an empty
p=tag on a DKIM key record as an explicit signal that the key has been revoked, which is different from there being no DKIM record at all.
IANA's reserved documentation domain, example.com, actually publishes both, specifically to illustrate these mechanisms: a null MX record, and DKIM keys at several common selectors with the p= tag left empty. A checker that only asks "does an MX record exist?" or "does a DKIM record exist?" will report both as healthy — when they are, in fact, RFC-defined ways of saying "there is no mail here" and "do not trust this key."
Why this matters even if you didn't create the record
DNS records accumulate over years, across multiple admins, email providers, and marketing platforms. Nobody sits down and designs an SPF record from scratch very often — it gets edited, extended, and occasionally left half-finished, one vendor onboarding at a time. A green checkmark from a shallow tool doesn't mean the record is correct; it can just mean the tool didn't look closely enough.
The Email Security Checker now checks for all five of these — plus DMARC's pct= enforcement percentage and missing aggregate reporting, and DKIM keys restricted to the deprecated SHA-1 hash. It's free, requires no account, and runs entirely in your browser. If it finds something on your domain you're not sure how to fix, get in touch.