Defaults.Exposed › Reports
The SPF PermError Report: 100× More Domains Break the 10-Lookup Limit Than Surface Counts Show (2026)
Published 2026-07-03
Figures as of 2026-06-29 · methodology v7, plus a chain-pricing pass run 2026-07-03. From the census of 261 million graded domains, we resolved every SPF
include:target referenced 100 or more times — 10,842 targets covering 95.2% of all include references — and priced each domain’s retained chain against that map. Unresolved tail targets counted as zero and chain contents reflect resolution day, so the headline is a conservative, floor-biased approximation: we say “at least”. Aggregate only; never an individual business’s record. See how we grade.
How many domains break the SPF 10-lookup limit?
At least 797,263 — because SPF has a self-destruct built into the standard, and the trigger hides where owners can’t see it. RFC 7208 §4.6.4 caps an SPF check at 10 DNS lookups; past ten, the receiver stops and returns PermError, and a PermError record protects nothing. Count only the lookups visible in the record itself — as most tooling does, and as our own census did until this report — and you find about 8,000 offenders (7,958, precisely). Price the include: chains those records actually pull in, and the count reaches 797,263: roughly 100 times larger.
Why can’t owners see it coming?
Because the budget is spent by other people’s records. include:onetool.example.com reads as one line in your DNS panel — but the receiver must fetch that record too, and count every lookup mechanism it contains, recursively. A record with three includes can cost eleven. Nothing in your own zone changed on the day you went over; a provider nested one more include, and your SPF died without warning.
Worse, DMARC treats a PermError as a fail on the SPF leg — so a domain that broke its SPF this way is now failing half of its own authentication.
What the chain-pricing found
| Finding | Domains |
|---|---|
| Over the 10-lookup limit, chains priced | 797,263 |
| Over the limit counting only visible mechanisms | 7,958 |
Over the limit while ending in strict -all | 112,215 |
| At exactly 9–10 lookups — the cliff edge | 2,119,539 |
Two stories in that table — the third, the cliff edge, gets its own section below:
- Surface counts miss ~99% of the breakage. The visible-mechanism count finds 7,958; pricing the chains finds 797,263. Nearly all of the damage is inherited from what the includes include.
- 112,215 of the broken records end in
-all. Their owners did everything right — climbed the wall, chose the strict ending — and one include too many voided the lot. Strict-looking and broken is the harshest failure mode in email security.
2.1 million domains are one tool away from the cliff
The number that should worry readers who are currently fine: 2,119,539 domains resolve to exactly 9 or 10 lookups — under the limit today, dead the day someone connects one more platform. That is roughly 1 in 66 of all SPF publishers, and it matches the shape of the distribution: the 99th-percentile SPF record already sits at 9 lookups. Sign up for one more marketing tool, paste its “just add this include” line, and a record that was under the limit at breakfast is void by lunch.
Whose fault is it? Increasingly, the stack’s
The biggest providers have quietly flattened their SPF — Google’s _spf.google.com and Microsoft’s spf.protection.outlook.com now expand to plain IP lists costing zero internal lookups (we verified both against live DNS during this analysis). The blowouts come from elsewhere: hosting-panel chains that nest three deep, regional providers whose include costs 7–10 lookups by itself, and the honest accumulation of SaaS — mailbox plus newsletter plus CRM plus helpdesk, each “just one include”. Almost nobody adds the eleventh lookup on purpose. It arrives as the sum of reasonable decisions.
How to check and fix yours — free
- Count your real total — our free check resolves your chain, or use any SPF lookup counter.
- Prune dead weight: tools you stopped using, duplicate includes, and the deprecated
ptrmechanism. - Flatten only what you control. Replacing a deep include with its IP blocks works for your own infrastructure; third-party IPs change without notice.
- Give bulk senders a subdomain. Newsletters from
news.yourdomain.comget their own record and their own 10-lookup budget.
Frequently asked questions
What is the SPF 10 DNS lookup limit?
RFC 7208 §4.6.4 allows at most 10 DNS lookups to evaluate one SPF record — counting the lookups inside every include: recursively. Exceeding it returns PermError: the record is treated as invalid and provides no protection.
What does SPF PermError mean? A permanent evaluation error — the receiver could not process your record (too many lookups, multiple records, or broken syntax) and treats your domain as having no usable SPF. DMARC counts it as a fail on the SPF leg.
How many domains exceed the SPF lookup limit? At least 797,263 of 139 million SPF publishers, per our chain-pricing pass — about 100× the 7,958 visible without resolving chains. A further 2,119,539 sit at 9–10 lookups, one include from the limit.
Does a PermError stop my email being delivered? Usually not — receivers proceed without SPF, and your mail rides on DKIM and reputation. What stops working is protection: forgers are no longer rejected, and every DMARC check of your mail loses its SPF leg. It’s invisible until it’s expensive.
How do I reduce my SPF lookup count?
Remove unused includes and ptr, flatten your own infrastructure to ip4:/ip6:, move bulk senders to subdomains, and re-count after every new tool. The fix guide walks through it.
Find out your real number
The mechanisms you can see are not your lookup count — the resolved number is the one receivers compute, and it’s a 30-second check.
Check your domain → · Fix SPF → · The SPF maturity model → · Two SPF records = none → · The ptr trap → · Aggregate data only. Data stored and processed in the EU.