Defaults.Exposed › Виправлення › Guides

SPF PermError: How to Fix "Too Many DNS Lookups" Without Breaking Your Email (2026)

Опубліковано 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

At least 797,263 domains break SPF’s 10-DNS-lookup limit, according to the Defaults.Exposed census of 261,086,232 domains — out of 139 million SPF publishers. Past ten lookups a receiver stops and returns PermError: your SPF is void, and DMARC counts a PermError as a fail.

The fix has a strict order, and most guides get it backwards. Count your real, resolved lookups; delete dead and unused includes — that alone fixes most records; move bulk senders onto subdomains with their own SPF budget; flatten only as a last resort, and only with automated re-flattening, because static flattening rots and silently breaks delivery.

What does “SPF PermError: too many DNS lookups” mean?

RFC 7208 §4.6.4 caps every SPF check at 10 DNS lookups. Past ten, the receiver stops and returns PermError — the entire record is treated as broken, not just the part over budget. The same section adds a lesser-known second ceiling: at most 2 “void lookups” (queries returning no answer or NXDOMAIN), so a couple of dead include: entries for cancelled services can void your SPF on their own.

The consequence is worse than “no SPF”: DMARC treats a PermError as an SPF fail, so a domain that breaks its own SPF is unauthenticated on the SPF leg of every DMARC evaluation. If DKIM isn’t set up or breaks in transit, that mail now fails DMARC outright.

One census number shows how cruel this failure mode is: 112,215 domains publish a strict -all record that is void because of lookup overflow — out of the 54,655,923 domains that publish -all at all. Their owners did the hard part — chose the strict ending — and one include too many switched the whole record off. They look strict; they are broken. For the full data picture, see the SPF PermError report.

Why did my SPF break when I didn’t change anything?

Because the budget is mostly spent by other people’s records. Every include: is evaluated recursively, and every lookup mechanism inside it counts against your ten. One line in your DNS panel can cost four or five lookups once resolved. A provider nests one more include, and your SPF dies without a single change in your zone.

The big platforms are not the problem: Google and Microsoft have both flattened their own SPF — _spf.google.com and spf.protection.outlook.com expand to plain IP lists costing zero internal lookups (verified against live DNS, July 2026). Real-world blowouts come from hosting-panel include chains nested several layers deep, and from honest SaaS stacking — mailbox plus newsletter plus CRM plus helpdesk, each “just one include”. Nobody adds the eleventh lookup on purpose; it arrives as the sum of reasonable decisions. That is why the cliff edge is so crowded: 2,119,539 domains sit at exactly 9–10 resolved lookups — roughly 1 in 66 of all SPF publishers, fine today, void the day someone pastes in one more include. The 99th-percentile SPF record already resolves to 9 lookups. If your stack is SaaS-heavy, the SPF failing for SaaS tools guide covers the vendor-by-vendor version.

Which parts of an SPF record count as DNS lookups?

Count the resolved total, not the visible lines. Four includes can be four lookups or fourteen.

How do I fix “too many DNS lookups” without breaking email?

1. Run the free scan before touching DNS. It resolves your full include chain and shows your real lookup count, so you fix the actual problem — not the record as it appears in your panel. (If it says you have no SPF at all, that’s a different failure — see “SPF record not found”.)
2. Delete dead and unused includes first. The tool you dropped in 2023, the old host’s include that survived a migration, duplicates, any ptr mechanism. Dead includes are doubly toxic: they burn lookup budget and they’re the usual source of void lookups. Most over-budget records get back under 10 in this step alone. If your record still carries a previous provider’s mechanisms, follow the migration cleanup guide.
3. Check each remaining include is doing anything. Receivers evaluate SPF against the Return-Path (RFC5321.MailFrom) domain, not the From header — and many SaaS tools put their own bounce domain on the Return-Path, so their include in your record does nothing except spend budget. Keep includes only for services that use your domain as the Return-Path; for the rest, enable the vendor’s custom-domain DKIM instead.
4. Move bulk senders to subdomains. Newsletters from news.yourdomain.com, transactional mail from mail.yourdomain.com. Each subdomain gets its own SPF record with a fresh 10-lookup budget, and a problem in one stream stops bleeding into the others.
5. Only then consider flattening — and only automated flattening. See below.
6. Re-scan to confirm you’re comfortably under 10 — aim for headroom, not 10 exactly, or you’ve just rejoined the 2.1 million domains on the cliff edge. Then work through anything else the scan flags on the fix SPF page.

Should I flatten my SPF record?

Flattening replaces includes with their underlying ip4:/ip6: blocks, which cost zero lookups. It works — and done by hand, it’s a delayed-action delivery outage.

Providers rotate sending IPs routinely and announce it to nobody. A static IP list is correct the day you paste it and quietly wrong within months — and because the failure shows up as other people not receiving your mail, you find out late. If pruning and subdomains get you under the limit, stop there; never hand-copy a third party’s IP blocks into your record as a permanent fix.

Frequently asked questions

Does an SPF PermError mean my email stops being delivered? Not instantly — that’s what makes it dangerous. DMARC counts a PermError as an SPF fail, so delivery leans entirely on DKIM; if DKIM is missing or breaks in transit, you’re failing DMARC. Of 139 million SPF publishers in our census (as of 2026-06-29), at least 797,263 are in this state — most without knowing.

My record only has four includes — how can it be over 10 lookups? Includes are counted recursively: everything inside each include (and inside its includes) is charged to your budget, so four visible lines can resolve to fourteen lookups. Count with a resolving tool, not by eye — resolving the chains is how our PermError report found ~100× more broken domains than surface counts show.

I end my record with -all — surely I’m protected? Only if the record evaluates. Our census (as of 2026-06-29) found 112,215 domains whose strict -all records are void from lookup overflow. A strict qualifier on a PermError record protects nothing.

Is the limit 10 lookups per include or for the whole record? The whole evaluation: RFC 7208 §4.6.4 caps the complete check at 10, plus at most 2 void lookups. Each subdomain has its own record and budget — which is why step 4 works.

Do ip4 and ip6 entries count toward the limit? No — IP mechanisms cost nothing, which is exactly why flattening reduces the count.

Send the owner the report

If you’re fixing this for a client or your employer, finish the job with evidence. Re-run the free scan after your changes and forward the graded report to the business owner: plain language, dated, PermError gone. That’s the artefact they’ll need for the cyber-insurance renewal and the next customer security questionnaire — the difference between “I changed some DNS records” and a documented before-and-after.

Check your domain free

See your real, resolved lookup count — and everything else SPF, DKIM and DMARC — privately and owner-only.

Check your domain → · Fix SPF → · SPF failing for SaaS tools → · Set up SPF on GoDaddy → · How we grade → · Aggregate data only. Data stored and processed in the EU.