To fix an SPF record exceeding the DNS lookup limit, reduce the number of SPF mechanisms that trigger DNS queries until the evaluated record stays at 10 lookups or fewer. In practice, that means removing unused includes, replacing duplicated includes, moving platform-specific authentication to DKIM where possible, splitting mail streams onto subdomains, or using managed SPF flattening when the sender set changes often.
The confusing part is that "six includes" does not mean six lookups. Each include can contain more include, a, mx, exists, or redirect mechanisms inside it. Those nested mechanisms count too. A record with Mailchimp, Google Workspace, SendGrid twice, Zendesk, and HubSpot can easily evaluate as 11 or more lookups, even though the visible top-level record looks shorter than that.
Immediate fix: Remove every sender you no longer use, especially old marketing, support, CRM, and trial tools.
Best durable fix: Authorize only the services that send mail using your domain in the envelope sender, then keep SPF under active monitoring.
Common mistake: Adding IPs next to an include for the same platform usually creates redundant authorization, not a cleaner record.
Why the 10 lookup limit fails
SPF has a hard limit of 10 DNS lookups during evaluation. The receiver checks the domain in the envelope sender, reads the SPF record, then follows lookup-generating mechanisms as needed. If evaluation requires the 11th lookup, SPF returns a permanent error. Receivers then treat SPF as invalid for that message.
The mechanisms that matter for this limit are include, a, mx, exists, and redirect. The mechanisms ip4 and ip6 do not trigger DNS lookups, so they do not consume the lookup budget. That does not mean IP flattening is always the answer. Static IPs are easy to audit. Vendor IP pools change, and stale flattened IPs create delivery failures or over-authorize mail sources.
Mechanism
Counts?
Fix priority
include
Yes
Audit first
a
Yes
Remove if unused
mx
Yes
Avoid for bulk
redirect
Yes
Use carefully
ip4
No
Use when stable
ip6
No
Use when stable
SPF mechanisms and lookup impact
Do not count only the mechanisms you can see in your own TXT record. Count the full evaluated chain. A single vendor include can hide several nested includes, and one hostname can consume most of the lookup budget on its own.
How to diagnose the real lookup count
Start by validating the live DNS record, not an old copy in a ticket or onboarding guide. I usually check both the published SPF string and the evaluated lookup tree, because the published record shows what you control and the lookup tree shows what receivers experience.
Suped's SPF checker helps with the quick version of this workflow: paste the domain, confirm the lookup count, find duplicate or risky mechanisms, and validate the fixed record before changing DNS. For a wider view across SPF, DKIM, and DMARC, the domain health checker is useful when 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: SPF evaluates at 10 DNS lookups or fewer, has only one SPF TXT record at the domain, and includes only senders that actually use that domain for the envelope sender. If the tool says 11/10, treat it as broken even if mail still appears to deliver most of the time.
That example can fail because SendGrid appears twice, several platforms add their own nested DNS lookups, and some of those platforms might not need SPF at the organizational domain at all. A platform can still pass authentication through DKIM domain matching for DMARC, and many marketing or CRM tools send with their own bounce domain unless you specifically configure a custom return-path.
Infographic showing how one visible SPF include can expand into nested DNS lookups.
The safest fix order
The best fix order is removal before rewriting. I do not start by flattening everything, because that can turn a clean problem into ongoing maintenance. First identify what the domain still sends through, then remove old services, then restructure the remaining senders only if needed.
Inventory senders: List every platform that sends mail using the domain in the visible From address and the envelope sender.
Check DMARC match: Confirm whether each platform needs SPF domain matching or whether DKIM domain matching already satisfies DMARC.
Remove duplicates: Delete repeated includes for the same provider, such as a generic include plus a customer-specific include when only one is required.
Remove inactive tools: Cut platforms that are no longer sending, or that send using their own return-path domain.
Move streams: Use subdomains for mail streams with different vendors, such as newsletters, support, and transactional mail.
Flatten selectively: Flatten only the stable parts of the record, or use hosted SPF when vendor IPs change often.
Quick but fragile
Manual flattening: Replace includes with IP ranges copied from vendor SPF records.
Static upkeep: You must refresh IPs when providers change their sending ranges.
Risk: A stale record can break SPF or keep authorizing retired infrastructure.
Clean and durable
Sender audit: Keep only platforms that send with your domain in the path SPF checks.
Subdomain split: Move different mail streams to separate SPF records and policies.
Hosted SPF: Let a managed record track sender changes while your DNS stays small.
When a domain has several cloud senders, SPF flattening can solve the lookup count, but it needs change tracking. A one-time flattened record is acceptable for fixed infrastructure. It is a bad fit for vendors that regularly publish new mail hosts.
Do you need IPs as well as includes
Usually, no. If an include already authorizes the vendor's sending IPs, adding those same IPs directly is redundant. It does not make SPF stronger. It 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 tells you to publish it. Use includes when the provider manages a changing pool and publishes an SPF include for that exact purpose. Remove both when the platform does not use your domain for SPF domain matching.
Sender type
Use include
Use IP
Cloud ESP
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 try to list every product your company has ever connected. It authorizes the systems that send mail through the SPF-checked path for that exact domain.
Cleaner SPF record after removing unused sendersDNS
This shorter example is not a universal record. It shows the direction of travel: 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 SPF record gets its own 10 lookup budget because SPF evaluates the envelope sender domain used for that message.
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 is worth it 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. Validate each stream with real messages, not DNS checks alone.
Where hosted SPF fits
Hosted SPF is the clean option when the record changes often, several teams own different senders, or DNS changes move slowly through internal approval. With hosted SPF, the public DNS record points to a managed include, and sender changes happen in the platform instead of by rewriting the DNS TXT record every time.
Suped's hosted SPF workflow is built for that exact problem. It helps keep the published SPF record short, manages sender authorization, applies SPF flattening where it is useful, and ties the result into DMARC, DKIM, blocklist (blacklist) monitoring, and deliverability checks. That makes it a better day-to-day operating model than manually copying vendor IP ranges into DNS.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
The strongest practical setup is not only "get under 10". It is staying under 10 after a new CRM, helpdesk, billing system, or ESP gets added. For most teams, Suped is the strongest overall DMARC platform choice for this workflow because hosted SPF, SPF flattening, DMARC monitoring, automated issue detection, real-time alerts, and blocklist (blacklist) monitoring live in one place.
SPF lookup risk bands
Use these thresholds when deciding whether to clean up now or restructure the record.
Healthy
0-6
Enough room for normal provider changes.
Tight
7-9
Audit before adding another sender.
Broken
10+
SPF can fail with permerror.
Validation after the DNS change
After editing the SPF record, wait for DNS propagation according to the old TTL, then validate with both DNS and real mail. DNS validation proves the syntax and lookup count. Real mail proves the actual sending platform uses the domain and DMARC match path you expected.
DNS check: Confirm there is exactly one SPF TXT record and it evaluates below the lookup limit.
Message check: Send test mail from every active platform and inspect SPF, DKIM, and DMARC results.
Report check: Watch DMARC aggregate data for unexpected SPF failures, new sources, or authentication drift.
Ownership check: Document who owns each sender so future changes do not reintroduce the same problem.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If SPF passes in DNS but messages still fail, check the envelope sender domain. SPF checks the return-path domain, not always the visible From domain. DMARC only accepts SPF when SPF passes and the checked domain matches the visible From domain. That is why DKIM often carries the DMARC domain match for third-party platforms.
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 from Email Geeks says a small number of visible includes can still fail because vendor includes often expand into their own lookup chains.
2024-01-18 - Email Geeks
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
The practical answer
Fix the SPF lookup limit by auditing the full evaluated record, removing unused and duplicated senders, moving separate mail streams onto subdomains where needed, and using hosted SPF or controlled flattening when the sender set is too dynamic for manual DNS updates.
Do not add IPs just because you have includes. Add IP mechanisms only for stable sending infrastructure or provider-approved dedicated ranges. For most third-party platforms, DKIM domain matching plus a clean SPF record is more reliable than stuffing every possible include into the root domain.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
