163 domains enforce DMARC on top of an SPF record that cannot be evaluated

We expanded the complete SPF tree of the top 10,000 domains and counted DNS lookups the way a receiving mail server does. 163 exceed the limit that makes SPF fail. 104 of them publish an enforcing DMARC policy regardless.

Method, first

Everything below is public DNS data. You can reproduce any single row with dig, and the aggregate figures with the tool described here.

• Corpus. The top 10,000 domains of the Tranco ranking, retrieved 23 July 2026. Tranco ranks web popularity, so it contains CDN and infrastructure hostnames that never handle mail.
• Segmentation. Because of that, the headline figures cover only the 7,279 domains publishing MX records. Including the rest understates adoption; silently excluding them would overstate it. Both are in the raw data.
• Exclusions. 28 domains (0.28%) had lookups that did not resolve and are excluded entirely. A domain we failed to measure is not a domain with no record.
• Lookup counting. Every include, a, mx, ptr, exists and redirect is counted against one shared budget across the whole recursive tree, per RFC 7208 §4.6.4.
• Macros. Targets containing SPF macros (e.g. %{ir}.%{v}.%{d}.spf.has.pphosted.com) expand at delivery time and cannot be resolved statically. They are counted as one lookup and not expanded, so totals for those domains are lower bounds. 6.0% of domains with SPF use them.
• Transport. DNS-over-HTTPS against Cloudflare and Google resolvers, with retry and backoff. Long TXT records are reassembled from their 255-byte segments before parsing.

Adoption is high. Enforcement is not.

Among mail-handling domains, 92.5% publish SPF and 81.8% publish DMARC. Those are healthy numbers, and considerably better than the picture before Google, Yahoo and Microsoft began requiring authentication from bulk senders. But publication is not protection.

The last row is the one that matters. A third of the domains that have "done DMARC" are in a state where it does no work. 382 of them publish p=none and no reporting address — a record that neither blocks anything nor tells anyone what is happening. It exists purely to satisfy a checkbox.

p=none with no rua is the email-security equivalent of an unplugged smoke alarm. It passes inspection.

The lookup limit

RFC 7208 allows an SPF evaluation ten DNS-querying mechanisms, counted across the entire chain of nested includes. Exceed it and the result is PERMERROR. SPF does not fail open — a receiver treats the record as unusable.

This is invisible to the tools most people use, for a simple reason: checking whether an SPF record exists costs one query, while counting its true cost means recursively resolving every include. Here is the distribution across the 6,735 mail-handling domains that publish SPF:

163 domains (2.4%) are over the limit. A further 252 sit exactly on it, meaning the next SaaS tool anyone signs up for breaks SPF. And 1,105 domains (16.4%) are at eight or more — close enough that the failure is a matter of time rather than chance.

The failure mode is what makes this worth attention. Nobody publishes an eleventh include deliberately. It happens when marketing adds a newsletter platform, or support adds a helpdesk, and the record quietly crosses a threshold nobody is watching. There is no error, no bounce, no alert. The record still looks fine to every tool that only asks whether it exists.

The intersection

The finding we did not expect: 104 of the 163 over-limit domains publish an enforcing DMARC policy — 50 at p=reject and 54 at p=quarantine. 25 of them additionally end their SPF record in -all, the strictest available setting.

This is the part we could not find measured anywhere. Studies of the lookup limit count the domains that are over it; studies of DMARC count adoption and policy. Crossing the two is what turns a configuration error into a ranked list of who is actually exposed — because an over-limit domain at p=none has a latent problem, while an over-limit domain at p=reject has a live one.

This is a specific and self-defeating combination. The organisation has done the difficult, deliberate work of turning enforcement on — which usually means someone understood the risk and argued for it — while the SPF half of the mechanism silently returns PERMERROR. Authentication rests entirely on DKIM alignment, and almost certainly nobody has been told.

These are named so the finding is checkable, not to single anyone out — this is an accumulation problem that afflicts organisations precisely because they use many tools, and it is genuinely easy to miss. Verify any row with dig +short TXT <domain> and follow the includes.

Enforcement drops as you go down the ranking

Adoption of SPF is essentially flat across the ranking — everyone has a record. What changes is whether the record does anything.

SPF adoption varies by half a percentage point across the whole range. Full enforcement varies by nineteen. Publishing a record is now table stakes; finishing the rollout is what separates the top of the list from the rest.

Two vendors carry most of the ecosystem

57.2% of mail-handling domains authorise Google Workspace or Microsoft 365. The mean domain authorises 1.5 identifiable third-party senders.

Smaller findings

• 58 domains publish more than one SPF record. This is an immediate PERMERROR under RFC 7208 §3.2 — SPF does not function at all, no matter how correct either record is individually.
• 5 domains end their SPF record in +all, authorising every host on the internet to send as them.
• 5.9% publish neither SPF nor DMARC despite accepting mail.
• MTA-STS adoption is 3.5%, against 12.3% for BIMI — the standard with a visible brand logo attached is being adopted three times faster than the one that encrypts mail in transit.

If you want to check your own

The checker on the front page runs the same engine used for this study, in your browser, against public DoH resolvers. Nothing is sent to us and nothing is stored. It expands your full SPF tree and gives you the real lookup count.

Data

The complete aggregate dataset behind every figure on this page is available as report.json. Corrections are welcome and will be published — if a number here is wrong, we would rather know.