How can I optimize my SPF record to stay within the lookup limit when using multiple email sending services?
Updated on 5 Nov 2026: We clarified cumulative SPF lookup counts and how to validate changes across multiple sending services.
To stay within SPF's 10-lookup limit, audit each service's envelope sender domain, remove unnecessary includes, and move suitable sending streams to custom Return-Path subdomains. Use SPF flattening or hosted SPF for the senders that still need to share one record.
Treat any sender path that needs an 11th DNS-querying SPF term as broken, even when another sender matches earlier in the policy. The SPF limit is 10 DNS-querying mechanisms and modifiers during evaluation. When a receiver must evaluate an 11th such term, the result is SPF permerror. Each receiver decides how to handle the message.
- Audit first: Confirm which services actually use your domain in the Return-Path or envelope sender.
- Remove unused entries: Delete obsolete includes and duplicate sender entries after confirming which sources still send mail.
- 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.
Check the envelope sender domain first
Start with the root problem: SPF checks the RFC5321.MailFrom domain, also called the envelope sender, and receivers can evaluate the HELO/EHLO identity where applicable. 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 term.
That distinction changes the 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.
Invalid example: two SPF records at one DNS namedns
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 is invalid because both TXT records are SPF policies at the same DNS name. Merge the required sender mechanisms into one SPF record and recheck the combined lookup count. Unrelated TXT verification records can remain at the same name.
Do not rely on one passing path
An individual message can pass when an earlier mechanism matches before the limit. Another valid sender path can still require an 11th DNS-querying term and return a permanent error. Test every authorized sending path instead of relying on one successful message.
- Ten means ten: The limit applies to DNS-querying terms evaluated across the path, not the visible include count.
- Hidden terms count: An include can lead to more include, mx, a, or exists mechanisms.
- One pass is not enough: Another sender can take a longer path through the same SPF policy.
- Check often: Vendor SPF records change without warning, so a valid path can exceed the limit later.
What counts toward the SPF lookup limit
SPF does not count every word in the record or every DNS packet. It counts DNS-querying mechanisms and the redirect modifier that are evaluated for a message. The terms subject to the limit 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 10-term evaluation budget.
A record with five include terms can still exceed the limit because one of those include policies can require several nested DNS-querying terms. Visual counting is unreliable. Use a parser that follows each SPF path and reports the evaluated term count.
Also watch void lookups. RFC 7208 recommends a limit of two DNS lookups that return no data or NXDOMAIN during evaluation. Implementations that enforce this limit return permerror when a third void lookup is required. An evaluated include whose target has no SPF record returns permerror immediately, without waiting to reach the void-lookup limit.
SPF 10-lookup limit showing nested include chains and the DNS-querying terms they add.
|
|
|
|---|---|---|
include | Yes | Follow nested records |
a | Yes | Avoid unless needed |
mx | Yes | Check address expansion |
exists | Yes | Usually vendor logic |
ptr | Yes | Do not use |
redirect | Yes | Shares the evaluation budget |
ip4 | No | Keep ranges current |
ip6 | No | Keep ranges current |
all | No | Omit when using redirect |
exp | No | Lookup follows evaluation |
SPF terms and lookup impact
The SPF lookup limit is a 10-term evaluation boundary, not a suggestion. Use a focused SPF checker before and after each edit so you know whether every sender path stays within the limit.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Count terms, not raw DNS queries
The familiar phrase "10 DNS lookups" is shorthand. RFC 7208 limits the include, a, mx, ptr, and exists mechanisms plus the redirect modifier to 10 terms during one SPF evaluation. The receiver's initial DNS query for the SPF TXT record does not count. Terms reached inside nested include and redirect policies share the same global budget. Count earlier includes that did not match too, including their nested terms. DNS caching does not reduce this term count.
Term-count exampledns
example.com TXT "v=spf1 mx include:spf.sender.example -all"
In this example, mx consumes one DNS-querying term and include consumes another. Any DNS-querying terms evaluated inside spf.sender.example also count. The A and AAAA work triggered while resolving MX hosts is subject to a separate limit, so an oversized MX expansion can return permerror even when the global term count is below 10.
This path-based model explains why a test message can pass even when a checker reports a risky maximum. SPF processes mechanisms from left to right and stops at a match. Validate the paths used by every authorized sender, then leave headroom so a nested vendor policy can grow without crossing the limit.
Why helper SPF records do not reset the limit
Moving includes into helper records shortens the root TXT value, but every evaluated helper include adds a term. The same budget still covers the nested policies.
Helper records still share one lookup budgetdns
example.com TXT "v=spf1 include:_spf1.example.com include:_spf2.example.com -all" _spf1.example.com TXT "v=spf1 include:spf.sender-a.example -all" _spf2.example.com TXT "v=spf1 include:spf.sender-b.example -all"
For an IP that matches only sender B, this example evaluates four include terms before counting any further nesting. Publishing helper records is different from configuring a service to use a separate MAIL FROM subdomain.
redirect= also shares the budget. A hosted redirect reduces lookups only when its destination policy is optimized. Omit all from a redirect policy because any all mechanism causes redirect to be ignored.
For long SPF values, each quoted TXT string has a 255-octet limit, but one DNS record can contain multiple strings. They are joined without added spaces. This addresses formatting, not lookup counts.
Audit every sender before changing DNS
Start the SPF cleanup by collecting real messages from each sending service, opening the headers, and identifying the envelope sender. If a service uses its own bounce domain or a vendor-controlled subdomain, confirm that identity before adding its include to the 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. Record the owner of each sending service and check occasional senders, such as monthly billing jobs, before deleting an include.
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 SPF alignment: The visible From uses the root domain, and SPF itself must satisfy DMARC's exact-domain match for this stream.
- Small count: Every required SPF path remains below the 10-term limit 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 alignment under DMARC needs checking. With relaxed SPF alignment, a bounce domain such as mail.example.com and a visible From domain at example.com satisfy the domain-match requirement because they share the organizational domain. With strict SPF alignment, that subdomain does not match exactly. DMARC can still pass through DKIM that meets the configured DKIM alignment requirement.
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.
Suggested SPF term-count planning bands
These are planning bands, not RFC thresholds. Ten or fewer evaluated DNS-querying terms meet the global lookup limit; other SPF checks still apply.
More headroom
0-6
Spare terms reduce exposure to vendor changes; ongoing checks are still needed.
Tight
7-9
Audit senders before adding any new service.
At limit
10
Within the term budget, with no spare terms.
Broken path
11+
An 11th evaluated term produces 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 every sender path, 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. Each stream gets a separate SPF evaluation only after its service actually uses the matching subdomain in MAIL FROM. SPF records are not inherited from the parent domain.
After the split, use a broader domain health checker to check SPF beside DMARC and DKIM. A valid SPF policy does not guarantee DMARC success: DMARC requires a passing SPF or DKIM result whose domain meets its alignment requirement with the visible From domain.
When SPF flattening is the right answer
Use SPF flattening when a domain still needs too many DNS-querying terms after the sender audit. Flattening replaces selected DNS-querying mechanisms with ip4 or ip6 entries so the receiver evaluates fewer DNS-querying terms.
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. A hosted SPF process can automate those updates, but it still needs monitoring and clear ownership. Partial flattening can retain frequently changing provider includes and replace only stable, documented IP ranges.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
Suped's Hosted SPF lets you manage senders and refresh their published IP ranges without repeatedly editing your domain's SPF TXT record. Compare DMARC aggregate results before and after sender changes to identify new SPF failures.
Flattening checklist
- Keep ownership: Know which sender each flattened IP range belongs to.
- Refresh changes: Add newly authorized IP ranges and remove retired ones when a vendor changes infrastructure.
- Avoid bloat: Keep the published policy small enough for reliable DNS responses.
- Monitor reports: Watch DMARC aggregate data for SPF errors after every change.
Give each sending subdomain its own SPF budget
Subdomains separate the SPF budgets of operationally distinct sending services. 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 alignment and the DKIM setup, so test real messages rather than assuming the DNS plan is enough.
SPF optimization flow for root domains, sender subdomains, and flattening decisions.
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.
Configure DKIM alongside SPF for each sending stream. Either mechanism can provide a DMARC pass when it authenticates successfully and satisfies the configured alignment requirement.
Common mistakes that keep SPF bloated
A 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 unnecessary include consumes lookup terms and authorizes sending IPs the root domain does not need.
|
|
|
|---|---|---|
Old sender | Remove | No current mail |
Vendor bounce | Do not add | Wrong domain |
App subdomain | Delegate | Own SPF budget |
Static IPs | Use ip4 or ip6 | No lookup term |
Vendor chain | Flatten carefully | Fewer evaluated terms |
Dedicated IP | Use selectively | Reputation work |
SPF cleanup decisions
A dedicated IP can reduce lookup terms 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 consume DNS-querying terms, and mx triggers address resolution for the listed mail hosts. If the sender has stable IP addresses, explicit ip4 or ip6 mechanisms are clearer and do not consume the 10-term budget.
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.
Validate SPF changes and monitor each sender
Save the previous SPF value before editing DNS. After the old record's TTL has expired, test a real message from each sending service and inspect the receiver's Authentication-Results header for spf=pass and the expected smtp.mailfrom domain. Check DMARC separately because a DMARC pass through DKIM can hide an SPF error.
Suped's DMARC reporting platform lets you compare SPF authentication results by sending source before and after a change. Investigate new failures and restore any required sender authorization removed during cleanup. Keep monitoring because nested vendor policies change after the initial edit.
Frequently asked questions
Yes. A sender evaluation that reaches an 11th DNS-querying term returns permerror. Another sender can pass if it matches earlier, which is why one successful test does not validate every evaluation through the policy.
Move senders to subdomains when they can use a separate bounce domain. Use flattening or hosted SPF when required senders still need to share one SPF record after cleanup.
No. You need SPF coverage for the domain in the envelope sender, also called the Return-Path or RFC5321.MailFrom. If a service uses its own bounce domain, it usually does not belong in your root SPF record.
Yes. Manual flattening creates risk when vendor IP ranges change. Hosted SPF automates that maintenance, but sender ownership, policy size, and authentication results still need monitoring.
Only one SPF policy is allowed at a given DNS name. Merge the required sender mechanisms into that record and recheck its lookup count. Other TXT records for verification are allowed, and separate sending subdomains can each have their own SPF record.
