The 10 DNS lookup limit on SPF records is important enough that I treat any record over the limit as production broken, even when today's DMARC reports show SPF passing. SPF receivers are supposed to return a permanent error when evaluation exceeds 10 DNS-lookup mechanisms. Some receivers enforce that strictly. Others are looser, and some checks only follow the branch needed for the sending IP.
That is why a domain can show 12 lookups in a checker while aggregate reports still show SPF pass. The record is over budget in its worst path, but the actual mail stream can hit an earlier match, or a receiver can tolerate the excess. I do not rely on either behavior. It turns SPF into a receiver-by-receiver gamble.
- Direct answer: The limit matters. Stay at 10 or below, and aim below 10 so one vendor change does not break mail.
- Operational answer: A record at 11 or more lookups creates intermittent authentication results across receivers.
- DMARC answer: SPF pass in DMARC reports does not prove the SPF record is safe. It proves that specific evaluated mail 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 finish checks quickly. 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 goes over 10 DNS-lookup mechanisms, SPF can return permerror. That means SPF is not authenticated for that message. If DKIM also fails, or DKIM passes under a different domain, DMARC can fail.
- Strict receivers: They stop evaluation and return a permanent SPF error.
- Loose receivers: They still pass some mail, which hides the problem until a different receiver rejects it.
- Changing vendors: One extra include inside a provider record can move a working domain into failure.
SPF lookup risk by count
How I treat lookup counts 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+
Receivers can return SPF permerror.
What counts as a lookup
The limit is not exactly 10 DNS packets. It is 10 SPF terms that require DNS lookups during evaluation. That distinction matters because a single mx mechanism counts as one SPF lookup term but can trigger several DNS queries underneath.
|
|
|
|---|---|---|
include | Yes | Common source of nested lookups. |
a | Yes | Adds DNS work for host addresses. |
mx | Yes | Often expensive and rarely needed. |
exists | Yes | Used for dynamic checks. |
redirect | Yes | Counts after policy handoff. |
ptr | Yes | Deprecated, slow, avoid it. |
ip4/ip6 | No | Direct IP ranges are cheap. |
all | No | Ends the policy. |
SPF mechanisms and lookup cost
I check the record with a tool, then I manually review the sending sources behind the result. Suped has a focused SPF checker for this, 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
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. I have seen reports show SPF pass while the public SPF record still has an over-limit branch waiting to fail.
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 receiver: Another mailbox provider enforces the limit and returns permerror.
- Nested change: A provider changes its included SPF record and pushes your domain past the limit.
- DKIM cover: DMARC can still pass through 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 12 lookups, I treat the DMARC report as a partial observation. The DNS record still needs work. A valid SPF record should pass because it is within the limit, not because a receiver tolerated excess complexity.
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 expand into a large tree. If one provider include already needs 12 lookups, adding it alone breaks SPF for strict receivers. A shorter visible TXT string does not mean a cheaper SPF evaluation.
- 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 the provider publishes stable sending ranges.
- Use subdomains: Split transactional, marketing, and web-hosted mail onto separate envelope 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.
- Long TXT: Expanded records can hit DNS provider length limits.
- 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 boring and repeatable. First check the raw DNS record. Then count the real evaluation path. Then compare the result against actual mail sources in DMARC reports. A broad 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 and no duplicate policy.
- Count lookups: Include nested records, redirects, and costly mechanisms.
- Match senders: Tie every include to a current system that sends mail.
- Reduce scope: Move unrelated services to subdomains with their own 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 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
This is where Suped's product is useful in a practical way. SPF lookup failures rarely exist alone. They show up beside DMARC gaps, DKIM failures, stale senders, DNS mistakes, and sometimes blocklist or blacklist reputation problems. Suped brings those checks into one workflow so the fix is not limited to editing a TXT record.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
For most teams, Suped is the stronger practical choice when the goal is ongoing control rather than a one-time lookup count. Automated issue detection, real-time alerts, hosted SPF, hosted DMARC, SPF flattening, hosted MTA-STS, and multi-domain dashboards keep the work visible after the first cleanup.
- 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 clean 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 the SPF specification treats more than 10 DNS-lookup terms as unauthenticated mail, and some receivers enforce that directly.
2020-09-09 - Email Geeks
Marketer from Email Geeks says receiver behavior differs, so a domain can appear healthy in reports while strict receivers still reject the SPF path.
2020-09-09 - Email Geeks
The practical answer
The 10 DNS lookup limit is important because it is a hard interoperability boundary. A record over the limit is not merely untidy. It is a record that works only when the receiver, the sender path, and the current vendor includes happen to cooperate.
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 truly needs more complexity than plain DNS can handle cleanly.
If DMARC reports show SPF passing at 12 lookups, fix it anyway. Passing today is useful evidence, but it is not a stable control.
