How can I optimize my SPF record to stay within the lookup limit when using multiple email sending services?
Updated on 4 Jul 2026: We updated this guide with clearer SPF lookup limits, subdomain handling, and safer hosted SPF cleanup guidance.
The practical answer is to audit every sender first, remove SPF includes that are not used by the RFC5321.MailFrom domain, move separate sending streams onto true branded subdomains where the bounce domain can live on that subdomain, and then use SPF flattening or hosted SPF for the remaining sources that must stay on the root domain.
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 during evaluation. Once a receiver needs 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 several senders still need one domain and vendor IP changes are monitored.
The direct fix
Start with the root problem: SPF checks the RFC5321.MailFrom domain, also called the envelope sender, and receivers also check HELO/EHLO in some cases. SPF does not check 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 RFC5321.MailFrom, Return-Path, or HELO/EHLO identity for real production messages?" Those are the domains that need SPF coverage. For null MAIL FROM bounce messages, the HELO/EHLO identity becomes the SPF identity.
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 terms that query DNS are include, a, mx, exists, ptr, and redirect. The ptr mechanism is expensive and should not be used. The ip4, ip6, all, and exp terms do not consume the same 10-lookup budget.
A record with five include terms can still exceed the limit because one of those include trees expands into several more DNS lookups. Visual counting is unreliable. Use a parser that follows the SPF tree and shows the total lookup count.
Also watch void lookups. SPF evaluators return permerror after more than two DNS lookups that return no data or NXDOMAIN during evaluation. Broken includes and abandoned vendor hostnames can fail this way even when the total lookup count looks acceptable.
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 |
ptr | Yes | Do not use |
redirect | Yes | Use with ownership |
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.
A useful sender inventory has 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 SPF domain matching under DMARC needs checking. With relaxed SPF matching, a bounce domain such as mail.example.com can match a visible From domain at example.com because both share the organizational domain. With strict SPF matching, that subdomain does not match exactly, so DKIM often has to provide the passing DMARC result for that stream.
The best order for reducing SPF lookups
Use 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-6
Enough room for normal vendor changes.
Tight
7-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. Sender changes are managed in Suped, the public SPF record stays small, and Suped's product monitors SPF, DMARC, DKIM, blocklist (blacklist) status, and deliverability signals in one place. That 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 relaxed or strict SPF domain matching 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.
Use true subdomains of the brand domain, not cousin domains such as lookalike brand domains. Cousin domains add extra DNS ownership work, weaken recipient recognition, and make abuse handling harder.
When a live stream moves to a new subdomain, ramp volume with engaged recipients and monitor authentication, complaints, and bounces. Do not change the domain, IP, and authentication records all at once. Change one major variable, measure the result, then continue.
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 |
Dedicated IP | Use selectively | Reputation work |
SPF cleanup decisions
A dedicated IP can reduce lookups when SPF authorizes a stable ip4 or ip6 address, but it is not a cleanup shortcut. Use it for reputation isolation with steady volume, not only because an SPF record reached the limit.
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 root SPF for senders that truly use the root envelope domain in production.
Use true branded subdomains so each separate stream has its own SPF budget.
Common pitfalls
Old vendor includes often stay in SPF long after the service stopped sending mail.
Vendor setup pages can request SPF even when bounce handling lives elsewhere.
Manual flattening breaks when provider IP ranges change and nobody updates DNS.
Expert tips
Treat 11 lookups as broken even when one receiver passes a single test message.
Compare DMARC reports before and after SPF edits to catch missed senders early.
Leave lookup room because nested vendor SPF records change without advance 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
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.
Suped's product fits this workflow when SPF cleanup needs ongoing monitoring. DMARC reports, DKIM checks, blocklist and blacklist monitoring, hosted SPF, real-time alerts, and fix guidance sit beside the DNS work. That matters because SPF optimization is not a one-time DNS edit. It is an operational process that needs ongoing visibility.
The end state 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.
