What are the best practices for using SPF flatteners and managing SPF records?
Published 31 Jul 2025
Updated 25 Jul 2026
11 min read
Summarize with
Updated on 25 Jul 2026: We updated this guide with exact SPF lookup counting, void-lookup checks, safer flattening controls, and forwarding-aware validation.
The best practice is to use an SPF flattener only when it is managed, refreshed automatically, and monitored. A one-time flattened TXT record is an interim fix, not a durable SPF strategy. The durable strategy is to remove unused senders, move unrelated mail streams to subdomains, keep the root domain simple, and use dynamic SPF or hosted SPF when lookup limits still block you.
Treat SPF flattening as a pressure valve for the 10 DNS lookup limit. It works only when the system keeps provider IPs current and alerts you when the record stops matching real mail. Suped's Hosted SPF workflow connects that work to DMARC reporting, DKIM results, blocklist (blacklist) monitoring, and issue detection instead of leaving SPF as a static DNS chore.
When an SPF flattener is the right move
Use an SPF flattener when a domain has a valid need to authorize multiple senders and those senders push the SPF record close to or beyond 10 DNS lookups. The most common case is a main domain that has accumulated mail platforms over several years: corporate mail, ticketing systems, CRM mail, billing mail, webinar mail, and outbound sales tools.
The mistake is treating flattening as the first answer. Before flattening, confirm which domain each sender uses in the SMTP return path. SPF checks the RFC5321.MailFrom domain, often called the envelope sender or bounce domain. For bulk mail, that domain is often a vendor-managed bounce domain or a branded subdomain, not the visible From domain.
- Use flattening tactically: Choose it when cleanup takes time and SPF failures already affect real mail.
- Prefer sender cleanup: Remove includes for platforms that do not send with your return-path domain.
- Separate mail streams: Move marketing, billing, alerts, and sales mail to purpose-built subdomains.
- Keep ownership clear: Document every SPF mechanism with the sender, owner, and business purpose.
SPF lookup budget
Use lookup count as an operating signal alongside the pass or fail result.
Healthy
0-6
Room for routine sender changes.
Tight
7-9
Requires review before adding senders.
Maximum
10
Valid, but another evaluated term can break SPF.
Broken
11+
The evaluated SPF path returns permerror.
Flattening adds operational risk when it turns several provider-maintained SPF includes into one static IP list. Mail providers change IP ranges. If the flattened record does not refresh, valid mail can fail SPF without a DNS syntax problem.
How SPF lookup limits are counted
SPF does not count TXT lines or every DNS packet toward the 10-lookup limit. It counts mechanisms and modifiers that cause DNS queries during one evaluation. The initial query that retrieves the domain's SPF record is outside that budget, but nested lookup terms reached through an include count.
|
|
|
|---|---|---|
include | 1 plus nested terms | Expand the referenced policy when counting |
a, mx | 1 each | Avoid unless the DNS relationship is intentional |
exists | 1 | Often uses macros and needs specialist review |
redirect | 1 when evaluated | Nested lookup terms also count |
ptr | 1 | Deprecated for use and should be removed |
ip4, ip6, all | 0 | These terms do not trigger DNS lookups |
Lookup cost is based on the SPF terms evaluated for a message.
Also track void lookups, which are DNS queries that return no usable answer or a name error. SPF evaluators commonly apply the RFC 7208 recommendation of no more than two void lookups and return permerror when that limit is exceeded. A broken hostname inside an include can therefore fail evaluation before the main 10-term budget is exhausted.
Count every legitimate path
SPF evaluates terms from left to right and stops on the first match. One sending IP can match early while another reaches deeper nested terms and exceeds the limit. Test every approved sending source and use the worst legitimate path as the operating budget.
Publish exactly one TXT record beginning with v=spf1 for each domain. Splitting a policy across multiple SPF TXT records does not create extra lookup capacity; it produces permerror. A single TXT record can contain multiple quoted character strings that DNS concatenates, but those strings still form one SPF policy.
What a safe SPF flattener must do
A safe flattener does more than expand includes into IP addresses. It rechecks upstream SPF records, detects changes, publishes an updated hosted policy, and retains enough history to explain what changed. It must also leave macro-driven mechanisms unflattened because their answers depend on message context. That is the difference between SPF flattening as a managed process and SPF flattening as a risky copy-paste operation.
One-time flattening
- Best for emergencies: It can restore SPF validity while you clean up senders.
- Weak refresh model: Someone must rerun it when upstream sender records change.
- Higher drift risk: DNS can look valid while real sender coverage has aged out.
Dynamic hosted SPF
- Best for operations: It refreshes provider data without constant DNS edits.
- Better change control: The platform can show what changed and why.
- Lower DNS churn: Teams can manage senders without editing the root TXT record.
Evaluate an SPF flattener with practical questions: how often it checks upstream policies, how quickly it publishes detected changes, what happens if an upstream include fails, whether it keeps the DNS response compact, and whether it alerts before SPF failures spread. A static list can help with diagnosis, but it should not run on a production domain without an automated refresh plan, monitoring, and rollback.
Cloudflare DNS screen showing an SPF TXT record being edited.
Clean the SPF record before flattening
Most overstuffed SPF records are not caused by a single unavoidable sender. They come from years of adding includes to the wrong domain. Start by matching each mail stream to the domain used in the return path. If a vendor sends with its own bounce domain, adding that vendor to your root SPF record does not help SPF for that mail.
Crowded root SPF recorddns
v=spf1 include:_spf.mail.example include:spf.crm.example -all
Cleaner SPF patterndns
example.com. TXT "v=spf1 include:_spf.corp.example -all" bounce.example.com. TXT "v=spf1 include:spf.sender.example -all"
That second pattern keeps the root domain focused on corporate mail and puts bulk sender authorization on the bounce subdomain that actually needs SPF. It also makes DMARC easier to reason about because each sending service has a clear identity boundary.
|
|
|
|---|---|---|
include | Vendor SPF | Nested lookups |
ip4 | Stable senders | Manual updates |
a | Rare cases | Extra lookups |
mx | Inbound hosts | Often wrong |
redirect | Full delegation | Less local control |
Use compact mechanisms and avoid lookup-heavy shortcuts where they add no value.
- Audit first: List every sender, return-path domain, DKIM domain, and business owner.
- Remove dead includes: Investigate inactive sources in DMARC reports, then confirm decommissioning with the owner before removal.
- Avoid root bloat: Do not authorize every vendor on the organizational domain by default.
- Use IPs carefully: Static IP mechanisms work well only when ownership and update paths are clear.
If your record has already crossed the limit, use a focused lookup fix before you publish a bigger workaround. If your record depends on static sender ranges, review IP address guidance so you do not trade lookup risk for stale IP risk.
How to manage SPF after flattening
After flattening, SPF management becomes a change-control problem. Someone needs to know when a new sender is added, when a sender stops sending, and when a provider changes its own SPF. The cleanest operating model is to keep one published SPF entry for the domain and manage approved senders inside a hosted policy.
Hosted SPF include patterndns
example.com. TXT "v=spf1 include:spf.hosted.example -all"
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
Suped's Hosted SPF is built for teams that need SPF changes tied to DMARC reporting and DKIM results. Teams can manage approved senders without repeated DNS edits, flatten records automatically, watch the lookup budget, and investigate a source that starts failing.
Alerts need message-level context. A quiet SPF failure is dangerous because the TXT record still exists and a basic DNS check can look fine. Monitor whether approved sources pass SPF, whether the authenticated SPF domain aligns with the visible From domain under DMARC, and whether aligned DKIM preserves DMARC when forwarding changes the sending IP.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
For a quick DNS-level validation, use the SPF checker after each change. Then validate with real message data because SPF syntax is only one part of the authentication outcome.
Validation and monitoring checks
The right validation sequence is DNS check, authentication check, then production monitoring. DNS confirms the policy is valid. Message testing confirms a real sender passes. DMARC reporting confirms the change works across receivers and mail streams over time.
Flowchart showing SPF cleanup, hosted SPF, validation, and monitoring.
- Check lookup count: Confirm every legitimate evaluation path stays at or below 10 lookups, with headroom before adding senders.
- Check TXT size: Keep the DNS response compact to reduce truncation and parsing problems.
- Check real messages: Send from each approved platform and inspect SPF, DKIM, and DMARC results.
- Check drift: Watch for sources that stop authenticating after provider-side DNS changes.
For a wider check across SPF, DKIM, and DMARC, run the domain health checker after the DNS change has propagated. That broader view matters because SPF success does not guarantee DMARC success when the authenticated return-path domain is unrelated to the visible From domain.
A good rollout has a backout plan. Keep the previous SPF record, know the DNS TTL, and schedule the change when someone can watch DMARC and delivery results for the next few hours.
Common failure modes to avoid
The most common failures are not syntax errors. They are operational errors: adding SPF includes for services that never use your return path, flattening once and forgetting it, authorizing broad IP ranges without ownership, and using the root domain for every mail stream.
|
|
|
|---|---|---|
Static flattening | Stale IPs | Dynamic refresh |
Root overload | Lookup pressure | Subdomains |
Unused includes | Permerror risk | Sender audit |
Unreviewed softfail | Ambiguous policy | Validate, then use -all |
Common SPF management mistakes and the cleaner fix.
The last row needs context. DMARC requires an aligned SPF pass, so both softfail and fail are non-passing SPF results for DMARC. After every legitimate sender is documented and tested, -all communicates a clear SPF policy to receivers. Keep monitoring because changing the qualifier does not repair alignment, forwarding, or stale sender data.
The practical operating rule
Flatten only what your team owns operationally. If no one can explain why an include exists, who approved it, and how it will be updated, it should not sit in the production SPF record.
Views from the trenches
Best practices
Confirm the return-path domain before adding any vendor include to the root SPF record.
Use managed refresh for flattened SPF so provider IP changes do not break valid mail.
Move distinct mail streams to subdomains before expanding the root domain policy.
Common pitfalls
A one-time flattened record ages badly when upstream sender SPF records change later.
Teams often add vendor includes to domains that vendor mail never uses for SPF at all.
Free static flattening without monitoring creates hidden risk during DMARC enforcement.
Expert tips
Keep a sender inventory with owner, purpose, bounce domain, DKIM domain, and status.
Set alerts for SPF permerror, lookup growth, and new unverified sources immediately.
Treat hosted SPF as change control alongside shortening a DNS TXT record safely.
Marketer from Email Geeks says managed SPF flattening can work well, but moving mail streams to subdomains is often the cleaner long-term answer.
2022-02-10 - Email Geeks
Marketer from Email Geeks says static flattening creates a single operational dependency, so production domains need automatic refresh and support coverage.
2022-02-10 - Email Geeks
The practical rule for SPF flattening
The best SPF setup is boring: a short record, clear sender ownership, purpose-built subdomains, monitored authentication results, and no surprise includes. Use a flattener when it helps you stay within the lookup limit, but choose a managed flattener that refreshes upstream data and alerts on failure.
For teams managing multiple domains or senders, Suped keeps Hosted SPF beside DMARC reporting, DKIM checks, blocklist (blacklist) monitoring, and issue-specific remediation. That workflow connects DNS changes to message-level results instead of treating flattening as a one-time TXT edit.
