How to fix SPF record exceeding DNS lookup limit?
Published 25 Jul 2025
Updated 4 Oct 2026
12 min read
Summarize with
Updated on 4 Oct 2026: We clarified how SPF counts nested lookups and added a message-header check to verify the fix for each sender.
To fix an SPF record exceeding the DNS lookup limit, reduce the number of DNS-querying SPF terms until every required evaluation path stays at 10 counted terms or fewer. In practice, that means removing unused includes, replacing duplicated includes, relying on aligned DKIM for DMARC when a platform uses its own return-path, splitting mail streams onto envelope-sender subdomains, or using managed SPF flattening when the sender set changes often.
The confusing part is that "six includes" does not mean six counted terms. Each include can contain more include, a, mx, exists, or redirect terms inside it. Those nested terms count too. A record with several office, marketing, support, and transactional senders can require 11 or more counted terms, even though the visible top-level record looks shorter than that.
- Remove every sender you no longer use, especially old marketing, support, CRM, and trial tools.
- Authorize only services that send with your domain in the envelope sender, then monitor the SPF policy as senders change.
- Adding IPs next to an include for the same platform usually creates redundant authorization.
How SPF reaches the 10 lookup limit
RFC 7208 sets a hard limit of 10 DNS-querying mechanisms and modifiers during one SPF evaluation. The initial DNS query used to retrieve the SPF record does not count. If evaluation reaches an 11th counted term, SPF stops and returns the permanent error result permerror. Receivers cannot use SPF as a passing authentication result for that message.
The terms that matter for this limit are include, a, mx, ptr, exists, and redirect. The mechanisms ip4, ip6, and all do not consume this term budget. The exp modifier also does not count during SPF evaluation. Raw DNS query totals can be higher because one mx term can require an MX query plus address queries. That still counts as one term toward the overall limit, subject to separate address-processing limits.
Static IP mechanisms are easy to audit, but flattening every include is not automatically safe. Vendor IP pools change, and stale flattened IPs create delivery failures or keep retired infrastructure authorized. Changing ~all to -all does not reduce the lookup count.
|
|
|
|---|---|---|
include | Yes | Audit first |
a | Yes | Remove if unused |
mx | Yes | Avoid unless needed |
exists | Yes | Audit carefully |
ptr | Yes | Remove |
redirect | Yes | Use carefully |
ip4 | No | Use when stable |
ip6 | No | Use when stable |
all | No | Keep as terminator |
SPF mechanisms and lookup impact
Do not count only the mechanisms visible in your own TXT record. Count the full evaluated chain. A single provider include can hide several nested terms, and the 10-term budget applies globally across those recursive evaluations. Adding another include layer does not reset it.
SPF also has related processing limits. Implementations should limit void lookups, DNS answers with no usable data or a name error, to two; when that limit is enforced, exceeding it returns permerror. An mx mechanism can query no more than 10 A or AAAA address records per MX record; exceeding that separate limit returns permerror.
Why the error can affect only some senders
SPF evaluates mechanisms from left to right and stops when a mechanism matches the connecting IP. That makes the lookup count path-dependent. A sender matching an early include can pass, while a sender that requires later nested includes can reach the 11th counted term and return permerror.
This behavior can make the problem look intermittent even though the published record has not changed. A validator often reports the maximum possible path, while a message header shows the path taken by one real sender. Check both, then fix every authorized path rather than accepting a pass from the sender that happens to match first. Reordering terms can help one path, but it cannot make an over-limit path valid.
- An early sender match can pass before SPF reaches the expensive part of the record.
- A late sender match can encounter nested includes that consume the remaining budget.
- A sender with no match can traverse the longest path and expose the lookup-limit failure.
How to diagnose the real lookup count
Start by validating the live DNS record, not an old copy in a ticket or onboarding guide. Check both the published SPF string and the evaluated lookup tree. The published record shows what you control, while the tree exposes nested terms and the maximum paths receivers can evaluate.
Suped's SPF checker supports this workflow: enter the domain, confirm the counted terms and void lookups, find duplicate or risky mechanisms, and validate the fixed record after changing DNS. For a wider view across SPF, DKIM, and DMARC, the domain health checker helps identify whether the SPF issue sits alongside other authentication problems.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
The result you want is simple: every required SPF path evaluates at 10 counted terms or fewer, the domain publishes only one record beginning with v=spf1, and that record authorizes only senders that use the domain for the envelope sender. If a check reports 11/10 on a possible path, treat that path as broken even if some messages still deliver.
Typical failing SPF recordDNS
v=spf1 include:office.example.net include:marketing.example.net include:transactional.example.net include:transactional.example.net include:support.example.net include:crm.example.net ~all
That example can fail because one provider appears twice and several includes can add their own nested DNS-querying terms. An include target with no SPF record also causes permerror, even if the path stays under 10 terms. Some platforms do not need SPF authorization at the organizational domain. A platform can satisfy DMARC through aligned DKIM, and many third-party senders use their own bounce domain unless you configure a custom return-path.
Infographic showing how one visible SPF include can expand into nested DNS lookups.
Read the failed message header
When a real message fails, inspect its Authentication-Results header. Find the SPF result and smtp.mailfrom domain, then compare that domain with the SPF record you checked. A DNS check of the visible From domain can miss the policy that the receiver actually evaluated.
Illustrative authentication resultstext
Authentication-Results: mx.example.net; spf=permerror smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
In this example, SPF fails for bounce.example.com, while aligned DKIM lets DMARC pass for example.com. Inspect several messages from each active sender because an early SPF match can pass while a later path returns permerror. Header wording varies by receiver, so use the recorded domains and results rather than matching one exact error string.
Fix SPF lookup limit step by step
The safest fix order is removal before rewriting. Flattening everything first can turn a clear lookup problem into ongoing maintenance. Identify what the domain still sends through, remove old services, then restructure the remaining senders only if needed.
- Inventory every platform that sends mail using this domain in the envelope sender. Record the visible From domain separately.
- Confirm whether each platform needs SPF alignment or whether aligned DKIM already satisfies DMARC.
- Delete repeated includes for the same provider, such as a generic include plus a customer-specific include when only one is required.
- Remove inactive platforms and entries for platforms that use their own envelope-sender domain, after checking real messages.
- Use subdomains with custom return-paths for mail streams managed by different vendors.
- Flatten stable parts of the record selectively, or use hosted SPF when provider IPs change often.
Quick but fragile
- Manual flattening replaces includes with IP ranges copied from provider SPF records.
- You must refresh those IPs when providers change their sending ranges.
- A stale record can break SPF or keep authorizing retired infrastructure.
Clean and durable
- A sender audit keeps only platforms that send with your domain in the path SPF checks.
- A subdomain split gives different envelope-sender domains their own SPF policies.
- Hosted SPF tracks sender changes while the published DNS record stays short.
When a domain has several cloud senders, SPF flattening can reduce the counted terms, but it needs change tracking. A one-time flattened record can work for fixed infrastructure. It is a poor fit for providers that regularly publish new mail hosts.
When to use IPs instead of includes
If an include already authorizes the provider's sending IPs, adding those same IPs directly is redundant. It does not make SPF stronger and often makes the record harder to maintain.
Use ip4 or ip6 when you own the sending server, the IP range is stable, or the provider gives you a dedicated fixed range and instructs you to publish it. Use includes when the provider manages a changing pool and publishes an SPF include for that purpose. Remove the entry from your domain when the platform uses a different envelope-sender domain, after checking its actual mail flow.
|
|
|
|---|---|---|
Cloud sender | Usually | Rarely |
Own MTA | No | Yes |
Dedicated IP | Sometimes | Often |
Retired tool | No | No |
When to use includes or IP mechanisms
A good SPF record does not list every product your company has connected. It authorizes the systems that send mail through the SPF-checked path for that exact domain.
Cleaner SPF record after removing unused sendersDNS
v=spf1 include:office.example.net include:transactional.example.net ~all
This shorter example is not a universal record. It shows the intended result: fewer mechanisms, no duplicated provider entries, and only senders that still need SPF at this domain.
When subdomains are the better fix
If one organizational domain carries office mail, newsletters, sales automation, support tickets, product notifications, and billing receipts, the SPF record becomes crowded. Subdomains let you give each stream its own SPF record, DKIM selectors, DMARC policy, and operational owner.
For example, keep employee mail on the root domain, move marketing to a newsletter subdomain, support to a helpdesk subdomain, and product mail to an app subdomain. Each envelope-sender domain gets its own 10-term budget. Changing only the visible From address does not move SPF evaluation, so the sending platform must support a custom return-path on the chosen subdomain.
Flowchart showing crowded SPF senders split across root, marketing, support, and product subdomains.
The tradeoff is operational complexity. Subdomains need sender configuration, DKIM setup, DMARC monitoring, and DNS ownership. That work is justified when different teams manage different mail systems or when one root SPF record has become a dumping ground.
A practical split is office mail on the root domain, bulk or lifecycle mail on a marketing subdomain, support mail on a support subdomain, and application mail on a product subdomain. Configure the envelope sender for each stream, then validate with real messages instead of DNS checks alone.
Where hosted SPF fits
Hosted SPF is useful when the record changes often, several teams own different senders, or DNS changes move slowly through internal approval. The public DNS record points to a managed SPF policy, and authorized-sender changes happen in the platform instead of requiring a new TXT record edit every time.
Suped's hosted SPF workflow keeps the published SPF record short, manages sender authorization, and applies SPF flattening where it is useful. It connects lookup monitoring with DMARC reports and change alerts, so owners can check whether a provider update or new sender affects authentication.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
The operational goal is to keep the record valid after a new sender is added. In Suped, owners can review the hosted SPF sender list alongside DMARC authentication results and issue alerts, then test the changed policy against real mail.
SPF lookup risk bands
Operational guide for deciding when to clean up or restructure a record; the standards limit is 10 counted terms.
Healthy
0-6
Room for provider changes.
Tight
7-9
Audit before adding another sender.
At the limit
10
Valid on this path, but one added term can break SPF.
Broken
11+
An evaluated path returns permerror.
Validation after the DNS change
After editing the SPF record, wait for DNS caches to expire according to the previous TTL, then validate with both DNS and real mail. DNS validation checks syntax and evaluated term counts. Real mail shows which envelope-sender domain and DMARC alignment path each platform uses.
- Confirm there is exactly one record beginning with v=spf1 and every required path stays within the 10-term limit.
- Send test mail from every active platform and inspect SPF, DKIM, and DMARC results, including smtp.mailfrom.
- Watch DMARC aggregate data for SPF errors, unexpected sources, and authentication drift.
- Document who owns each sender so future changes do not reintroduce the same problem.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If SPF passes in a DNS check but a message still fails, check the envelope-sender domain in the message headers. SPF normally checks the return-path domain, not necessarily the visible From domain; a null return-path can make the HELO domain the SPF identity. For DMARC, SPF must pass and its authenticated domain must align with the visible From domain. Relaxed alignment accepts the same organizational domain, while strict alignment requires an exact domain match.
For background on the exact limit and how receivers treat failures, the page on the maximum SPF lookups gives the shorter standards-focused explanation.
Views from the trenches
Best practices
Validate the full SPF lookup chain before changing DNS or removing sender entries.
Remove inactive tools and duplicate vendor includes before flattening any SPF record.
Use subdomains when separate teams or mail streams keep crowding one SPF record.
Common pitfalls
Counting top-level includes only hides nested lookups that receivers must evaluate.
Adding IP ranges beside vendor includes often creates redundant SPF authorization.
Flattening once and forgetting updates leaves stale IPs in production DNS records.
Expert tips
Keep root-domain SPF reserved only for senders that genuinely need root-domain SPF.
Use DKIM domain matching for third-party tools when SPF domain matching is not needed.
Monitor DMARC reports after cleanup to catch retired sources that still send mail.
Marketer view
Marketer from Email Geeks says a small number of visible includes can still fail because provider includes often expand into their own lookup chains.
2024-01-18 - Email Geeks
Marketer view
Marketer from Email Geeks says IPs and includes for the same sender are usually redundant, so the sender path should be confirmed before adding both.
2024-02-06 - Email Geeks
Frequently asked questions
Because each include can contain nested DNS-querying terms. SPF counts the evaluated path, not only the mechanisms visible in your own record.
Only when the IP ranges are stable and you are prepared to maintain them. For many cloud senders, includes are safer because the provider manages changing infrastructure.
No. A domain can have unrelated TXT records, but it must publish no more than one TXT record beginning with v=spf1. Multiple SPF records cause permerror and must be merged into one valid policy.
DKIM does not reduce SPF lookups, but aligned DKIM can satisfy DMARC for a third-party sender. You can remove an SPF entry from your domain when that sender uses a different envelope-sender domain and the entry is no longer needed.
Remove unused senders and duplicates first, then validate every lookup path. If the policy still exceeds the limit, split senders by envelope-sender subdomain or use managed SPF flattening.
SPF stops at the first matching mechanism, so different senders can take different evaluation paths. An early sender can pass while a later path reaches the 11th counted term and returns permerror.
