SPF record has too many DNS lookups: how to fix the "permerror"
TL;DR: SPF's own specification (RFC 7208) caps the number of DNS lookups a validator will perform while evaluating your record at 10. Every include, a, mx, ptr, exists, and redirect mechanism costs at least one lookup, and nested includes (a common one being a marketing or CRM tool's own SPF record, which itself includes others) add up faster than most people realize. Once you exceed 10, receiving mail servers return a permanent error and, per spec, are supposed to treat the entire SPF check as a fail, regardless of whether the actual sending server was legitimate.
Why the 10-lookup limit exists
SPF validation happens on every single inbound email a receiving mail server processes, and each mechanism in an SPF record that requires resolving a DNS lookup (rather than being a literal IP address) adds latency and load to that per-message check. The 10-lookup ceiling in RFC 7208 exists specifically to prevent SPF checks from becoming a denial-of-service vector, either accidentally through a runaway chain of nested includes, or deliberately through a maliciously crafted record designed to make a receiving server perform excessive DNS resolution work per message.
The limit is not a soft guideline implemented inconsistently across providers; it is part of the specification, and compliant mail servers (which includes the major providers you care most about, Gmail, Microsoft, and others) are expected to enforce it. This is why a record that exceeds the limit does not just "mostly work," it produces a hard permerror.
What counts as a lookup, exactly
Several SPF mechanisms trigger a DNS lookup as part of evaluation, and it is easy to undercount because some are indirect. include:domain.com costs one lookup for the include itself, plus every lookup the included domain's own SPF record requires when it is evaluated recursively, which is the primary reason totals balloon unexpectedly. a and mx mechanisms each cost one lookup. ptr (rarely used and generally discouraged specifically because of its lookup cost and unreliability) costs one lookup, plus additional lookups for each PTR record returned. exists costs one lookup. redirect costs one lookup for the redirect target's own record evaluation.
Mechanisms that do not cost a lookup: ip4 and ip6 (literal IP addresses, no resolution needed), and modifiers like all.
The critical detail most people miss: an include is not one lookup, it is one lookup for that include plus the total lookup cost of everything the included record itself brings in, recursively. A single include:_spf.google.com, for example, itself references several sub-includes internally, meaning one line in your SPF record can silently account for several of your 10 available lookups.
How to count your current total
Manually tracing this by reading raw DNS TXT records and following every nested include by hand is tedious and error-prone, particularly once you have five or more third-party services (email marketing platform, CRM, transactional email API, helpdesk software) each contributing their own include. A dedicated SPF lookup counter tool traces the full chain automatically and reports your actual total against the 10-lookup ceiling, including flagging exactly which include is contributing the most lookups, which is the information you need to prioritize a fix.
Run this check any time you add a new third-party sending service to your SPF record, not just when you suspect a problem, since the failure is silent right up until the moment you cross the threshold, and by then mail may have already started failing for a period before anyone notices the pattern.
Fix 1: remove or consolidate includes
The most direct fix, when it is available, is genuinely using fewer services that require their own SPF include. This is worth a real audit rather than assuming every current include is still necessary: old marketing tools no longer in active use, a previous CRM you migrated away from months ago but never removed from SPF, or a transactional email service that was replaced but whose include was never cleaned up, are common sources of unnecessary lookup cost sitting unused in a record nobody has revisited.
Where consolidation is genuinely possible, some providers offer a single combined include covering multiple of their own services rather than requiring several separate includes, worth checking each vendor's current documentation rather than assuming the include you added years ago is still the minimal correct one.
This fix is the cleanest because it does not add any new infrastructure or ongoing maintenance burden; it simply removes complexity that should not have accumulated in the first place. Its limitation is that it only works if you genuinely have removable or consolidatable includes, which is not always the case if every current include reflects an actively used, necessary service.
Fix 2: SPF flattening
SPF flattening resolves every included domain's SPF record down to its underlying literal IP addresses (ip4/ip6 mechanisms, which cost no lookups) and publishes those directly in your own SPF record instead of the include mechanism that would otherwise trigger a recursive lookup. This reduces your lookup count without removing any actual sending service, since the same servers are still authorized, just referenced by IP instead of by a lookup-costing include.
The trade-off: flattened IP lists are a snapshot in time. If the underlying service changes its sending IP ranges, which legitimate email providers do periodically for infrastructure reasons, your flattened record becomes outdated and either fails to authorize their new IPs (causing legitimate mail to fail SPF) or, if not properly maintained, requires manual updates you have to remember to make. Our SPF flattener tool handles the flattening calculation, but the ongoing maintenance question below is worth understanding before relying on this approach long-term.
Comparing the two fixes
| Factor | Removing/consolidating includes | SPF flattening |
|---|---|---|
| Reduces lookup count | Yes, if removable includes exist | Yes, always |
| Works even with many necessary services | Not always | Yes |
| Ongoing maintenance required | Minimal | Requires monitoring for IP changes |
| Risk if provider changes sending IPs | N/A (still using dynamic include) | Legitimate mail can start failing SPF |
| Best for | Records with unused/redundant includes | Records with many necessary services and no redundancy left to trim |
The maintenance trap flattening creates
This deserves emphasis because it is the most common way a flattening fix quietly breaks months later. When you flatten, you are trading a dynamic reference (the include, which always reflects the provider's current IPs automatically) for a static snapshot (literal IPs, which do not update themselves). If the third-party service later adds or migrates sending infrastructure, your flattened SPF record does not know about it, and mail sent from the new, unlisted IPs will fail SPF at your domain even though the sending service itself did nothing wrong.
If you flatten, set a recurring reminder (quarterly is a reasonable interval) to re-run the flattening process and confirm no IP ranges have changed, or use a tool that offers ongoing monitoring rather than a one-time flatten. Treating a flattened SPF record as "fixed forever" is the setup for a delayed, confusing deliverability failure that is hard to trace back to this cause months later.
FAQs
What happens to email when SPF hits a permerror?
Per RFC 7208, a permerror should be treated as equivalent to a fail by the receiving server, though exact handling varies somewhat by provider implementation. In practice, this typically means significantly worse deliverability or outright rejection for mail from domains with a permerror'd SPF record, since the receiving server cannot meaningfully evaluate authorization at all.
Does DKIM or DMARC help if my SPF has too many lookups?
DMARC can pass based on DKIM alignment alone even if SPF fails or errors, provided DKIM is correctly configured and aligned, which is why having both SPF and DKIM properly set up, not relying on either alone, provides resilience. However, a permerror'd SPF is still worth fixing directly rather than relying entirely on DKIM to compensate, since some receiving systems weigh SPF status independently in spam scoring beyond just DMARC evaluation.
How do I know which include is costing the most lookups?
An SPF lookup counter tool that traces the full recursive chain will show lookup cost attributed to each top-level include, including how many lookups are consumed by that include's own nested includes. This is the fastest way to identify the single largest contributor, often one specific third-party service, without manually tracing DNS records by hand.
Can I just use "-all" more strictly to fix this instead?
No, the all mechanism and its qualifier (-all, ~all, +all) determine what happens for senders not matched by any prior mechanism; it does not affect lookup counting at all and cannot fix a permerror caused by exceeding the 10-lookup ceiling elsewhere in the record.
Is there a way to increase the 10-lookup limit?
No, it is fixed in the SPF specification and is not configurable per domain or per receiving server; every compliant SPF validator enforces the same limit. The only paths forward are reducing your actual lookup count through consolidation or flattening, not raising the ceiling itself.
Will SPF flattening break if I add a new email service later?
Adding a new service after flattening requires manually adding its IP ranges (or its include, if you have lookup budget remaining) to your flattened record; it does not update automatically. This is part of the same maintenance burden described above and is worth factoring into whether flattening or consolidation is the better long-term fit for how often your sending services change.
How often should I check my SPF lookup count?
At minimum, any time you add a new third-party sending service to your SPF record, since that is when the count changes. Beyond that, a periodic check (quarterly is reasonable) catches drift from services you have added and forgotten about, or from a flattened record that has silently gone stale relative to a provider's IP changes.
Conclusion
The 10-lookup SPF ceiling is a hard specification limit, not a best-practice suggestion, and it is easy to exceed without realizing it because nested includes from third-party services add lookups recursively rather than one-for-one. A permerror from exceeding this limit is treated as a fail by compliant receiving servers, which can silently degrade deliverability for mail that was otherwise entirely legitimate.
Count your actual current lookup total first, since guessing at which includes are expensive is unreliable. Removing genuinely unused includes is the cleanest fix where available; flattening is the fallback for records where every current service is actually necessary, but it trades dynamic accuracy for a static snapshot that needs periodic re-checking.
HostCloud's free SPF lookup counter and SPF flattener tools handle both the diagnosis and the fix without needing to trace DNS records by hand. Try them at https://hostcloud.in/tools.