SPF glossary
What is the SPF 10-DNS-lookup limit and how do you fix 'too many DNS lookups'?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
RFC 7208 caps SPF evaluation at 10 DNS lookups: include, a, mx, ptr, exists, and redirect each count, while ip4:, ip6:, and all don't. Exceed the cap and evaluation stops with a permerror — SPF silently breaks. The fix is pruning and flattening lookup-hungry terms, not adding more includes.
10-DNS-lookup limit at a glance | |
|---|---|
| Tag | Processing limit (RFC 7208 §4.6.4) — not a tag you publish |
| Valid values | Max 10 lookup-triggering terms per evaluation: include, a, mx, ptr, exists, redirect |
| Default | ip4:, ip6:, and all cost zero. The 11th lookup-triggering term makes the result permerror. |
| Where it goes | Applies to the whole evaluation — every nested include in the tree counts, not just your top-level record. |
How 10-DNS-lookup limit works
SPF evaluation was designed to be cheap for receivers, so RFC 7208 hard-caps the DNS work: at most 10 lookup-triggering terms per check. include, a, mx, ptr, and exists mechanisms and the redirect modifier all count; ip4:, ip6:, and all are free. Crucially, the count covers the *whole tree* — include:_spf.google.com looks like one term but contains three nested includes, so it really costs four.
Blowing the budget doesn't produce a warning — it produces a permerror, meaning SPF stops evaluating entirely. Under DMARC, that's an invisible downgrade: no aligned SPF pass, everything riding on DKIM. Records drift over the limit gradually, one onboarded SaaS tool at a time, which is why “SPF worked yesterday” tickets so often end here.
The fixes, in order of preference: remove includes for tools you no longer send from, and drop cargo-culted mx/a vanity terms; replace lookups for your own stable infrastructure with zero-cost ip4:/ip6: terms; and only then flatten — resolve a provider's include into its literal IPs. Flattening comes with an honest caveat: providers rotate their ranges, so a flattened record starts going stale the day you paste it. Flattening is viable only with automated upkeep that re-resolves and republishes — as a one-time manual fix, it's a slow-motion outage.
Correct record vs common mistake
Correct
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:sendgrid.net -allThe includes and their nesting stay well inside the budget, and the ip4 term is free.
Common mistake
v=spf1 a mx ptr include:_spf.google.com include:mailgun.org include:servers.mcsv.net include:_spf.salesforce.com include:spf.protection.outlook.com ~allEight lookup terms before nesting — and Google's include alone nests three more. This record is over 10 and permerrors, silently breaking SPF.
Troubleshooting the 10-DNS-lookup limit
| Issue | Likely cause | Fix |
|---|---|---|
| Checker reports 'too many DNS lookups' / permerror | More than 10 lookup terms once every nested include is counted | Prune first: includes for cancelled tools and vanity mx/a terms are the usual dead weight; then move stable hosts to ip4/ip6 |
| Record broke without anyone editing it | A vendor added a nested include inside their own record, pushing your total past 10 | You own the whole tree — recount after vendor changes and re-audit the full chain periodically |
| Flattened record worked, then mail failed weeks later | Flattening froze a provider's IPs, and the provider rotated them | Treat flattening as a subscription, not a paste: automate re-resolving and republishing, or keep includes for senders that rotate |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
Every SaaS tool a client onboards adds an include, and across 50–200 tenants each record creeps toward the wall on its own schedule — then tips over silently, as a permerror no dashboard flags. This is the single most common way “fully configured” SPF dies in a managed fleet, and it's routinely triggered by a *vendor* changing their nested includes, with no edit on your side at all.
Trusted by MSPs
“Palisade allowed our team to deploy DMARC on our domains in minutes instead of hours and making sure our clients are compliant with cutting edge security recommendations from Microsoft.”
Alvin Kalli — CSIO, MSP Corp
Enforce it — don't just monitor it
Pruning a record safely means knowing which sources still send — which is exactly what the DMARC reports show. Palisade reads them for every client domain, so dead includes are removed on evidence, real senders stay aligned, and every tenant advances to `p=reject` without SPF quietly falling over on the way.
Free 15-day trial · No credit card · Your own domain free forever (NFR)