SPF PermError: How to Count Nested Lookups and Fix the 10-Lookup Limit

The Failure Nobody Sees Coming

The 10-lookup limit is cold email's most common silent killer because it fails invisibly and arrives gradually. Your record was fine at 6 lookups. Then marketing added HubSpot, support added Zendesk, someone added a second ESP "just to test", and one Tuesday you crossed 10. Nothing errored, no dashboard turned red; receivers just started returning permerror, your SPF stopped counting for anything, and placement sagged with no visible cause. The record still reads perfectly, syntax checkers pass it, because the problem isn't syntax, it's arithmetic.

How the Counting Actually Works

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org a mx ~all

include:_spf.google.com          = 1
  └ 3 nested _netblocks includes = 3     (hidden inside Google's record)
include:sendgrid.net             = 1
  └ 1 nested include             = 1
include:mailgun.org              = 1
a                                = 1
mx                               = 1
                          total  = 9 of 10   ← one more service breaks it

• •Cost one each, at every depth: include, a, mx, ptr, exists, redirect. (ptr is also deprecated, delete it on sight.)
• •Cost zero: ip4, ip6, all, and the v=spf1 tag itself.
• •The nesting is the trap: you can't audit by reading your own TXT record, you have to resolve the whole tree, which is why eyeball audits miss it and why our checker walks it recursively and numbers every lookup.
• •Bonus rule, void lookups: includes pointing at domains with NO SPF record are limited to 2 before permerror. Dead includes hurt twice.

Fix #1: Delete the Dead Weight (Works More Often Than You'd Think)

Audit every include against reality: are you actually still sending through that service, from this domain? Old ESP trials, a switched marketing platform, a survey tool from 2023, records accumulate includes like garages accumulate boxes. Each deletion refunds its whole subtree. Most over-limit records we see fix entirely at this step, and the discipline that keeps them fixed is treating the SPF record as an allowlist you own, not a guestbook anyone can sign.

Fix #2: Split by Subdomain (The Structural Fix)

Each domain and subdomain evaluates its own SPF with its own 10-lookup budget. So move services to where they belong: marketing platform sends from news.yourco.com with its own SPF, support tool from help.yourco.com, and your root (or better, your separate sending domains) carries only what actually sends there. Cold email sending domains done right need just one or two includes, their budget is never the problem; it's shared multi-purpose domains that overflow.

Fix #3: Flatten, Powerful, and a Maintenance Contract

Flattening replaces an include with the ip4/ip6 ranges it resolves to, lookups drop to zero. The catch: providers rotate ranges without telling you, and a stale flattened record silently un-authorizes their new IPs, failing SPF for real mail. So flatten only stable, slow-moving providers, or use tooling that re-resolves and updates automatically, and never hand-flatten Google or Microsoft, whose ranges shift. Flatten last, after fixes 1 and 2, for the stubborn remainder.