SPF's 10-lookup limit applies to specified DNS-dependent terms evaluated during an SPF check. It is not a rule allowing ten visible include statements in the root record. Nested policies share the evaluation's limit, and an early match can stop the check before later branches are reached.
When the counted-term limit is exceeded, the result is permerror. A useful diagnosis traces the connecting sender through the applicable policy and records where evaluation continues, matches or fails. That trace shows which dependencies need attention and which permissions the business still needs.
Understand what SPF counts
RFC 7208 §4.6.4 identifies include, a, mx, ptr and exists, plus the redirect modifier, as DNS-query-causing terms subject to the overall limit when evaluated. Under RFC 7208 §4.1, referenced policies share the evaluation's global limit rather than receiving fresh independent allowances.
The all, ip4 and ip6 mechanisms do not consume that term limit. The exp modifier does not consume it during the SPF evaluation, although an explanation lookup can occur later. Other limits and operational constraints still apply, including requirements involving MX/PTR expansion and void lookups.
The initial SPF TXT lookup should not be confused with an evaluated include mechanism. A diagnostic should state what its displayed number represents: a protocol-term count, a static expansion estimate, or observed DNS queries.
Worked example: two includes lead to an eleventh term
The following is a synthetic fixture using reserved example domains and documentation IP addresses. It is not live DNS and is not a production record to paste.
The root policy is:
v=spf1 include:billing.example.net include:messages.example.org -allAssume the billing policy evaluates three further includes, each containing only an ip4 mechanism and -all. Assume the messages policy evaluates six further includes built the same way. Assume every reached policy has one syntactically valid SPF TXT record, all DNS retrievals succeed, each intermediate policy ends in -all and no other terms are present. For this example, none of their authorised addresses matches the connecting sender.
- Root billing include: running total 1.
- Three nested billing includes: running total 4.
- Root messages include: running total 5.
- First five nested messages includes: running total 10.
- Sixth nested messages include: would exceed the limit, producing permerror.
The root contains only two visible includes. The complete non-matching path attempts an eleventh counted term.
Now consider a different sender that matches the first nested billing policy. In this fixture, it can pass after two counted includes. Evaluation does not continue through the later message-service branch just to use up the allowance.
This is why a path trace and its input address matter. It is also why a static expansion tool and a receiver's particular evaluation can display different-looking counts without measuring the same thing.
Trace the actual failing evaluation
Collect the connecting IP, the SPF-evaluated envelope domain, the complete relevant TXT answers and the receiver's diagnostic. Preserve timing: a provider's referenced policy can change after the original delivery.
Record each counted term reached, the referenced policy and the result that causes evaluation to continue, match or fail. Distinguish an excessive-term error from malformed syntax, several SPF records, a circular dependency or a temporary DNS failure.
A root-record lookup helps establish the starting point:
dig TXT example.com. +noall +answerThe BIND dig manual documents these DNS-query/display options. It does not, by itself, evaluate SPF or establish the lookup count. A DNS query command is not a substitute for the trace.
Choose a maintainable correction
Start with obsolete permissions. Confirm that an include is no longer needed before removing it; shared services and seasonal mail can make a quiet interval misleading.
For active services, check the provider's supported configuration. A dedicated sending subdomain or a supported custom envelope identity may reduce unrelated dependencies and improve governance, but the identities and alignment still need verification.
Changing mechanism order can alter the evaluated path. Test representative legitimate and non-matching inputs rather than moving the busiest service first and declaring the entire policy fixed.
Flattening can replace referenced policies with address data and reduce counted terms. It also creates maintenance work: provider address changes must be reflected, obsolete permissions removed and failures detected. Record-length and DNS constraints do not disappear. Do not use broad ranges or permissive +all as a shortcut.
Check the effect on legitimate services
A business can reach this problem after years of adding services to the same domain. Old includes remain, providers add dependencies and nobody owns the full permission set.
Ask for a service-level explanation: which legitimate messages encounter the failing path, which permissions are still needed and who will maintain the replacement. The cheapest apparent fix can become expensive if it copies provider addresses into a record that nobody keeps current.
Judge the outcome by restored legitimate mail and controlled permissions. A lower checker count is useful evidence, but it is not the whole business result.
Verify the resulting permissions and DMARC alignment
Require a maintained service-to-permission map, an accountable change and evidence for all affected legitimate routes. Ask whether the fix introduced a new live DNS dependency, outsourced maintenance or retained unnecessary infrastructure access.
Track the reason for each permission and the condition for retirement. A technically valid SPF policy can still authorise too much. It also does not establish sender reputation or the safety of a message's contents.
After correction, re-evaluate the previously failing inputs and representative legitimate traffic. Then verify DMARC alignment separately. A restored raw SPF pass for an unrelated envelope domain does not fix an alignment failure.
The practical takeaway
A successful correction demonstrates a compliant evaluation for the relevant inputs and continued legitimate sending. Keep the dependency trace and the reason for each retained permission. Then verify alignment on real messages; a repaired raw SPF result is only one part of DMARC.
Record the next decision
The nonmatching fixture has 1+3+1+6=11 attempted counted terms; the sixth nested messages include exceeds the limit after 10. The early billing match needs only two includes. Retain this assumption set with any tool comparison and label graph expansion separately from evaluated-path count. No evaluator or network query was executed for these examples.