How important is the 10 DNS lookups limit on SPF records?
Updated on 22 Jul 2026: We clarified SPF's evaluated lookup paths and added the separate void lookup rule.
The 10 DNS lookup limit on SPF records is important enough that I treat any evaluated path over the limit as production broken, even when today's DMARC reports show SPF passing. RFC 7208 requires SPF receivers to return a permanent error when evaluation exceeds 10 DNS-querying terms. A static checker can also flag a worst-case branch that a particular sending IP does not reach.
That is why a domain can show 12 lookups in a checker while aggregate reports still show SPF pass. The public policy has an over-budget path, but the observed mail can match an earlier mechanism and stop evaluation before reaching it. I do not leave that branch in place because another authorized sender can take the longer path and return permerror.
- Direct answer: The limit matters. Keep every legitimate evaluation path at 10 or below, and aim below 10 so one vendor change does not break mail.
- Operational answer: The eleventh DNS-querying term on an evaluated path produces SPF permerror. The receiver then applies its local message-handling policy.
- DMARC answer: SPF pass in DMARC reports does not prove every SPF path is safe. It proves that the reported messages passed at those receivers.
Why the limit matters
SPF is checked against the connecting server for the envelope sender domain, usually the Return-Path, and sometimes HELO or EHLO. It does not authenticate the visible From header directly. DMARC can use SPF only when the SPF-authenticated domain matches the visible From domain under the DMARC rules.
The SPF lookup limit exists because receivers must bound DNS work. An SPF record can point to another SPF record, which points to more records, which then use a and mx mechanisms. Without a hard cap, one message can force a receiver into excessive DNS work.
The risk is not theoretical
Once evaluation reaches an eleventh DNS-querying term, SPF must return permerror. SPF is then unavailable as an authenticated result for that message. If DKIM also fails, or its signing domain is not aligned, DMARC fails.
- SPF result: A compliant evaluation returns permerror when the term limit is exceeded.
- Message handling: The receiver decides whether to accept, filter, defer, or reject mail with that result.
- Changing vendors: One extra nested include inside a provider record can move a valid path into permerror.
SPF lookup risk by count
How I treat the highest lookup count across legitimate evaluation paths during a production review.
Healthy
0-7
Enough room for provider changes and emergency edits.
Tight
8-10
Still valid, but too close for comfort.
Broken
11+
An evaluated path returns SPF permerror.
What counts as a lookup
The limit is not exactly 10 DNS packets. It is 10 DNS-querying SPF terms used during evaluation. The initial TXT query that retrieves the SPF record does not consume this term budget. Nested include and redirect evaluations share one global count, rather than receiving a fresh allowance of 10.
|
|
|
|---|---|---|
include | Yes | Counts once, plus DNS-querying terms reached inside the included policy. |
a | Yes | Looks up A or AAAA records for the target host. |
mx | Yes | Also has a separate limit of 10 address records per MX name. |
exists | Yes | Used for DNS-based tests and can create void lookups. |
redirect | Yes | Counts when the policy handoff is evaluated. |
ptr | Yes | RFC 7208 says not to use it, and separate PTR processing limits apply. |
ip4/ip6 | No | Direct IP ranges do not use DNS during evaluation. |
all | No | Ends mechanism evaluation with its qualifier. |
exp | No | Its later explanation lookup does not count toward the 10-term limit. |
SPF mechanisms and lookup cost
I check the record with a tool, then manually review the sending sources behind the result. Suped's SPF checker shows the recursive path, and the output is most useful when paired with a current sender inventory.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
The separate void lookup limit
SPF also has a separate safeguard for void lookups. A void lookup is a DNS query that returns NXDOMAIN or succeeds with no answers. RFC 7208 says implementations should limit these results to two and recommends two as the default when the limit is configurable. This is not the same as the mandatory 10-term ceiling.
Policy that can create three void lookupsdns
v=spf1 exists:_spf-a.example exists:_spf-b.example exists:_spf-c.example -all
A low term count can still fail
The example uses only three DNS-querying terms, but it can exceed the recommended void lookup limit if all three names return empty or nonexistent answers. Remove stale targets and investigate unexpected empty DNS responses instead of checking only the headline lookup count.
Why DMARC reports can still show pass
A DMARC aggregate report is evidence of what a receiver saw for a batch of mail. It is not a guarantee that every possible SPF evaluation path is valid. Reports can show SPF pass while the public SPF record still has an over-limit branch waiting for a different sending IP to reach it.
Flowchart showing how an SPF receiver counts lookups before returning a result.
- Early match: The sender matches a mechanism before the over-limit branch is reached.
- Different source: Another authorized sending IP follows a longer path and reaches the eleventh term.
- Nested change: A provider changes its included SPF record and pushes a previously valid path past the limit.
- DKIM cover: DMARC can still pass through aligned DKIM, so the SPF problem sits unnoticed until DKIM breaks.
Do not confuse pass with safe
If DMARC reports show SPF passing while a checker reports a 12-term worst path, I treat the DMARC report as a partial observation. The DNS record still needs work because another legitimate source can reach that path. A valid SPF design keeps all required paths within the limit.
How to fix an overloaded SPF record
I start with deletion, not flattening. Many overloaded records include services that no longer send mail, shared hosting includes that authorize unrelated infrastructure, or mechanisms like mx and ptr that add DNS cost without a clear benefit.
Overloaded SPF exampledns
v=spf1 include:host.example include:send.example include:crm.example ~all
That record looks short, but each include can trigger recursive evaluation of a larger policy. If one provider's required path already needs 11 terms, that include alone produces permerror when the path is evaluated. A short visible TXT string does not mean a cheap SPF check.
- Inventory senders: List every platform that sends with your Return-Path or HELO domain.
- Remove stale includes: Delete services that no longer send mail for the domain.
- Replace broad includes: Use direct IP mechanisms when you control the infrastructure or the provider publishes stable sending ranges.
- Order mechanisms: Place low-cost mechanisms for common senders before expensive includes, but still validate every legitimate path.
- Use subdomains: Split unrelated mail streams onto separate envelope sender domains.
- Automate flattening: Use managed SPF flattening only when pruning and subdomain separation are not enough.
Cleaner SPF exampledns
v=spf1 ip4:203.0.113.10 include:send.example -all
Manual flattening
Manual flattening means replacing included domains with IP ranges yourself. It can work for static infrastructure, but it has a maintenance problem.
- Stale IPs: Provider range changes can leave authorized senders missing.
- Record size: Expanded policies can exceed SPF's practical DNS response-size guidance.
- No alerts: You find breakage after reports or support tickets appear.
Hosted SPF management
Suped's Hosted SPF manages the hosted include and keeps the published SPF path under control without requiring constant DNS edits.
- Central edits: Manage senders in one place instead of many DNS zones.
- Lookup control: Flatten and optimize without hand-maintaining vendor IP ranges.
- Issue alerts: Detect broken SPF, DMARC, and DKIM changes quickly.
A practical review workflow
The safest workflow is repeatable. First check the raw DNS record. Then count the evaluated and worst-case paths, including recursion. Compare the result against actual mail sources in DMARC reports. Suped's domain health checker is useful when SPF is only one part of the domain's authentication setup.
- Check DNS: Confirm there is one SPF TXT record, no duplicate policy, and no circular include or redirect path.
- Count lookups: Include nested records, redirects, costly mechanisms, and void results.
- Match senders: Tie every include to a current system that sends mail.
- Reduce scope: Move unrelated services to subdomains with their own envelope sender domains and SPF records.
- Monitor reports: Watch DMARC results after each change before tightening policy.
The strongest fix is often architectural
If one organizational domain contains every sender, the SPF record becomes a junk drawer. Separate envelope sender domains give each mail stream a smaller policy and make DMARC reporting easier to read.
For a detailed repair path, the related guide on how to fix SPF lookup failures goes deeper into cleanup steps.
Where Suped fits
Suped's product connects the SPF repair work to the evidence behind it. Teams can review recursive SPF paths against DMARC aggregate data, confirm which senders remain active, manage hosted SPF changes, and receive alerts when DNS or authentication results change.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
For teams maintaining many domains, Suped provides hosted SPF, issue detection, alerts, and multi-domain views in one workflow. Hosted DMARC and MTA-STS can remain in that workflow, but they do not change SPF's 10-term limit.
- DMARC evidence: Use report data to see which senders still need authorization.
- SPF control: Manage sender changes without asking for DNS access every time.
- Alerting: Catch lookup, policy, and authentication changes before they spread.
- MSP scale: Manage many domains and client organizations from one dashboard.
Views from the trenches
Best practices
Audit every include against active senders before flattening or adding another vendor.
Keep lookup counts below eight where possible, so provider changes leave room to move.
Split unrelated mail streams onto subdomains instead of overloading one policy.
Common pitfalls
Treating a passing DMARC report as proof that every SPF evaluation path is valid.
Flattening by hand once, then missing later provider IP range changes and failures.
Accepting shared hosting SPF includes that authorize senders the domain never uses.
Expert tips
Remove costly mx and deprecated ptr mechanisms unless a clear sending need exists.
Use monitored hosted SPF when records need flattening but provider IPs still change.
Check blocklist and blacklist status when shared hosting mail or IPs cause issues.
Expert from Email Geeks says SPF requires permerror when an evaluated path reaches an eleventh DNS-querying term.
2020-09-09 - Email Geeks
Marketer from Email Geeks says reports can look healthy when observed senders match before an over-limit branch is evaluated.
2020-09-09 - Email Geeks
The practical answer
The 10 DNS lookup limit is important because it is a hard SPF evaluation boundary. An evaluated path over the limit returns permerror. A static worst-case count above 10 also identifies a path that can break when the matching sender or a nested provider policy changes.
I aim for fewer than 10, preferably fewer than eight. I remove unused senders, avoid broad hosting includes, stop using ptr, split mail streams onto subdomains, and use managed hosted SPF when the domain needs more complexity than plain DNS can handle cleanly.
If DMARC reports show SPF passing while a validator finds a 12-term path, repair that path anyway. Passing reports describe observed mail, not every sender path encoded in DNS.
