The practical answer is to audit every sender first, remove SPF includes that are not used by the 5321.From domain, move separate sending streams onto subdomains where the bounce domain can live there, and then use SPF flattening or hosted SPF for the remaining sources that must stay on the root domain.
I treat 11 DNS lookups as a broken SPF record, even when a few receivers stop evaluating after an earlier match. The SPF limit is 10 DNS-querying mechanisms and modifiers. Once a receiver evaluates more than that, the result is a permanent error, and SPF stops being reliable for that message. The cleanup work is worth doing before deliverability problems become hard to trace.
- Audit first: Confirm which services actually use your domain in the Return-Path or envelope sender.
- Remove junk: Delete old includes, copied vendor snippets, and duplicate sender entries.
- Split senders: Use subdomains for apps, stores, newsletters, and support systems when each can control its own bounce domain.
- Flatten carefully: Use flattening when you still need several senders on one domain and can keep vendor IP changes updated.
The direct fix
Start with the root problem: SPF checks the envelope sender domain, not the visible From address that people see in the email client. If a vendor sends with its own bounce domain, or with a delegated subdomain that the vendor gave you, adding that vendor to the root SPF record does not help that message pass SPF for your root domain. It only adds another lookup.
That distinction changes the whole decision. Do not ask, "Which vendors send email for us?" Ask, "Which domains appear in the 5321.From or Return-Path for real production messages?" Those are the domains that need SPF coverage.
Overloaded root SPF exampledns
example.com TXT "v=spf1 include:_spf.google.com include:vendor-a.example -all" example.com TXT "v=spf1 include:vendor-b.example include:vendor-c.example -all"
The example above also shows another common error: a domain must publish only one SPF TXT record. Multiple SPF records do not merge. They create an SPF error. Keep one SPF record per domain, then make that one record smaller and more accurate.
Do not rely on receiver behavior
Some receivers stop SPF evaluation when an earlier mechanism matches the sending IP. Others return a permanent error once the evaluation needs the 11th lookup. The record is still outside the limit, so the safe engineering choice is to fix it.
- Ten means ten: The limit applies during SPF evaluation, not during a quick visual count of include terms.
- Hidden lookups count: An include can point to more includes, mx, a, or exists mechanisms.
- Pass is not enough: A pass today can become a permerror after a vendor changes its SPF tree.
- Check often: Vendor SPF records change without warning, so a valid record can become invalid later.
What counts toward the SPF lookup limit
SPF does not count every word in the record. It counts DNS-querying mechanisms and the redirect modifier that are evaluated for a message. The common offenders are include, a, mx, exists, ptr, and redirect. The ip4, ip6, all, and exp terms do not add to the 10-lookup limit in the same way.
A record with five include terms can still exceed the limit because one of those include trees expands into several more DNS lookups. This is why visual counting is unreliable. Use a parser that follows the SPF tree and shows the total lookup count.
SPF include chains can hide extra DNS lookups under one visible record.
|
|
|
|---|---|---|
include | Yes | Follow nested records |
a | Yes | Avoid unless needed |
mx | Yes | Counts extra hosts |
exists | Yes | Usually vendor logic |
ip4 | No | Keep ranges current |
ip6 | No | Keep ranges current |
all | No | Use one final policy |
SPF terms and lookup impact
For the rule itself, the SPF lookup limit is the hard boundary to design around, not a suggestion. Use a focused SPF checker before and after each edit so you know whether the DNS tree is actually under 10.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Audit every sender before changing DNS
The most useful SPF cleanup step is boring: collect real messages from each sending service, open the headers, and identify the envelope sender. In many cases, an app that asks you to add an SPF include is already using its own bounce domain or a vendor-controlled subdomain. That include does not belong in your root SPF record.
I usually make a sender inventory with four fields: service name, visible From domain, Return-Path domain, and the DNS record that controls SPF for that Return-Path domain. If the Return-Path is not your root domain, the root record is probably not where that vendor's SPF belongs.
Cloudflare DNS record editing screen with an SPF TXT record and sender subdomain entries.
Keep on the root domain
- Direct mail: The root domain is in the Return-Path for employee mail or core transactional mail.
- Shared root: The service cannot use a delegated bounce subdomain.
- Strict match: Your DMARC setup requires the envelope sender to match the visible From domain exactly.
- Small count: The total SPF tree remains under 10 with room for vendor changes.
Move to a subdomain
- App mail: A SaaS app can send bounces through app.example.com or return.example.com.
- Campaign mail: Newsletter and lifecycle mail can use mail.example.com or news.example.com.
- Vendor control: The vendor provides CNAME records that point the bounce domain to its platform.
- Cleaner root: The root SPF record keeps only sources that truly send with the root envelope sender.
This is also where I check DMARC behavior. In relaxed DMARC mode, a bounce domain such as mail.example.com can still match a visible From domain at example.com because both share the same organizational domain. In strict mode, that subdomain does not match exactly, so DKIM often has to carry DMARC for that stream.
The best order for reducing SPF lookups
I do this in a fixed order because it avoids unnecessary flattening. Flattening is useful, but it should not preserve a messy sender list. First remove records that do nothing. Then split the domains that can be split. Then flatten what remains.
SPF lookup count bands
Use the count after nested lookups are followed, not the visible include count.
Healthy
0-7
Enough room for normal vendor changes.
Tight
8-9
Audit senders before adding any new service.
At limit
10
No spare room for hidden vendor changes.
Broken
11+
Receivers can return a permanent SPF error.
- List senders: Export every service that sends employee, app, marketing, support, billing, store, and notification email.
- Capture headers: Send a real message from each service and inspect the Return-Path.
- Delete unused: Remove includes for services that no longer send, never used your envelope sender, or were replaced.
- Delegate streams: Move apps and campaigns to subdomains when the sender supports a custom bounce domain.
- Flatten leftovers: Flatten only the remaining required sources and monitor for vendor IP changes.
- Validate results: Check SPF, send test mail, and watch DMARC reports for new failures.
Cleaner split-domain SPF layoutdns
example.com TXT "v=spf1 include:_spf.google.com -all" mail.example.com TXT "v=spf1 include:spf.sender.example -all" app.example.com TXT "v=spf1 include:spf.app.example -all"
That layout keeps the root domain reserved for sources that need it. It also lets each subdomain have its own 10-lookup budget, because SPF is evaluated against the domain in the envelope sender.
After the split, use a broader domain health checker to check SPF beside DMARC and DKIM. SPF can be technically valid while DMARC still fails because the domain match rule is wrong for the stream.
When SPF flattening is the right answer
Use SPF flattening when a domain still needs too many DNS-querying mechanisms after the sender audit. Flattening resolves include chains into IP addresses or managed records so the receiver performs fewer DNS lookups during SPF evaluation.
Manual flattening can work for static infrastructure, but it is risky for SaaS senders because IP ranges change. If you paste IP ranges into DNS and never refresh them, SPF starts failing when the vendor rotates infrastructure. That is why hosted SPF is usually the cleaner operating model.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
Suped's Hosted SPF is built for this workflow. You manage allowed senders in Suped, Suped hosts the SPF include, and the platform monitors SPF, DMARC, DKIM, blocklist status, and deliverability signals in one place. It also gives issue detection, real-time alerts, and fix steps, which matters when a vendor change breaks a record that looked fine last week.
Flattening checklist
- Keep ownership: Know which sender each flattened IP range belongs to.
- Refresh changes: Update records when a vendor publishes new infrastructure.
- Avoid bloat: Do not replace lookup errors with a TXT record that exceeds DNS response limits.
- Monitor reports: Watch DMARC aggregate data for SPF errors after every change.
How subdomains reduce risk
Subdomains are often better than flattening when the sending services are operationally separate. A newsletter platform, a support desk, an ecommerce notification system, and a product app do not all need to share the root SPF budget. Each can use its own envelope sender domain and its own SPF policy.
This does not mean the visible From address must always change. Many setups keep the visible From at example.com while the Return-Path uses mail.example.com or app.example.com. Whether that satisfies DMARC depends on your DMARC mode and DKIM setup, so test real messages rather than assuming the DNS plan is enough.
Decision flow for keeping a sender on root SPF, moving it to a subdomain, or flattening it.
The strongest setup pairs subdomain routing with DKIM on the same organizational domain. That way SPF and DKIM both support DMARC, and one overloaded root SPF record no longer controls every sender in the business.
Common mistakes that keep SPF bloated
The most common mistake is accepting every vendor setup page literally. Some setup pages tell you to add an SPF include to your root domain even when the vendor uses a separate bounce domain. That instruction is harmless only until the root record hits the lookup limit.
|
|
|
|---|---|---|
Old sender | Remove | No current mail |
Vendor bounce | Do not add | Wrong domain |
App subdomain | Delegate | Own SPF budget |
Static IPs | Use ip4 | No lookup |
Vendor chain | Flatten | Fewer lookups |
SPF cleanup decisions
Another mistake is using a or mx in SPF because it feels compact. Both trigger DNS lookups, and mx can expand into additional address lookups. If the sender has stable IP addresses, explicit ip4 or ip6 mechanisms are clearer and cheaper for SPF evaluation.
Flattened record patterndns
example.com TXT "v=spf1 ip4:192.0.2.10 include:_spf.google.com -all"
The record above is only a pattern. Do not copy documentation IPs into production. Use the real ranges for your own infrastructure and a monitored process for every vendor-maintained sender.
Views from the trenches
Best practices
Verify the Return-Path for every sender before adding that service to the root SPF.
Keep the root SPF record for senders that truly use the root envelope domain in production.
Use subdomains for separate apps so each stream has its own SPF budget and sender history.
Common pitfalls
Old vendor includes often stay in SPF long after the service stopped sending mail.
A vendor setup page can request SPF even when its bounce domain is separate and safe elsewhere.
Manual flattening breaks when provider IP ranges change and nobody updates DNS on time.
Expert tips
Treat 11 lookups as broken even when one receiver appears to pass a single test message.
Compare DMARC reports before and after SPF edits to catch missed senders early and fast.
Leave spare lookup room because nested vendor SPF records change over time without notice.
Marketer from Email Geeks says SPF lookup failures should be fixed at the source, because relying on receiver-specific evaluation creates inconsistent authentication results.
2024-02-11 - Email Geeks
Marketer from Email Geeks says the first cleanup step is removing unnecessary SPF includes, especially old SaaS entries that were copied during setup and never reviewed.
2024-02-12 - Email Geeks
My recommended path
If your domain is at 11 lookups, fix it now. The cleanest path is not to flatten everything immediately. Start by proving which services need SPF on the root domain, remove the rest, move suitable senders to subdomains, then use hosted SPF or flattening for the senders that must remain together.
For most teams, Suped is the stronger practical choice because the SPF work sits next to DMARC monitoring, DKIM checks, blocklist monitoring, hosted MTA-STS, real-time alerts, and fix guidance. That matters because SPF optimization is not a one-time DNS edit. It is an operational process that needs ongoing visibility.
The end state I want is simple: one valid SPF record per sending domain, fewer than 10 DNS lookups, no dead vendors, subdomains for separate streams, and monitoring that catches new failures before they turn into delivery problems.
