When an SPF record gets close to the 10-lookup limit, teams usually hear the same suggestion: flatten it.
That advice is not wrong, exactly. It is just incomplete.
SPF flattening can reduce lookup depth by replacing include: chains with explicit ip4: and ip6: mechanisms. But it also changes the operational model. Instead of depending on a provider to keep its own SPF data current, the domain owner now has to keep copied IP authorization data current. That tradeoff is where most real-world breakage starts.
If the lookup-limit side of SPF needs a refresher first, keep SPF 10 DNS lookup limit explained nearby while reading this.
SPF flattening is not a formal SPF feature. It is an operational technique.
A normal SPF record might look like this:
example.com. IN TXT "v=spf1 include:_spf.mailer.example.net include:spf.protection.outlook.com -all"That design delegates sender-IP maintenance to the providers behind those include: targets.
A flattened version replaces those upstream references with explicit IP ranges:
example.com. IN TXT "v=spf1 ip4:192.0.2.10 ip4:198.51.100.0/24 ip6:2001:db8:100::/48 -all"This can cut DNS-querying terms dramatically, which matters because SPF evaluation has a global limit of 10 lookup-causing terms across the whole evaluation path, per RFC 7208 section 4.6.4.
The catch is obvious once it is stated plainly: flattened records age.
There are usually three motivations:
Those are all understandable. RFC 7208 explicitly tells publishers to keep the amount of DNS information needed for evaluation to a minimum, and it also warns about oversized TXT responses and DNS transport issues in section 3.4.
So the instinct behind flattening is often healthy: make SPF smaller, simpler, and more predictable.
Maintaining include: mechanisms means delegating part of SPF maintenance to the service you use.
That has benefits:
Flattening swaps those benefits for different ones:
Neither model is universally correct.
The question is not "is flattening good or bad?" It is "who is more likely to keep authorization data accurate over time: the provider, or the local automation and change process?"
This is the classic failure mode.
An ESP, CRM platform, or ticketing system adds new outbound IP space, retires an old pool, or shifts traffic between regions. Their published SPF include changes. Your flattened copy does not.
Now legitimate mail starts producing SPF failures or SPF permerror elsewhere in the graph. If DKIM is missing or not aligned on that stream, DMARC can fail too, because DMARC needs at least one aligned authentication pass from SPF or DKIM, as described in RFC 7489 section 4.2.
This is why flattening often looks successful right up until the day it does not.
Reducing lookup terms does not automatically produce a healthy SPF record.
A heavily flattened record can become long enough to be awkward to publish, review, and troubleshoot. RFC 7208 recommends keeping published SPF data small enough that query results fit within traditional UDP response limits, and specifically notes the risk of oversized answers and TCP fallback issues in section 3.4.
So flattening can solve one limit while pushing you toward another operational edge.
Many providers publish support documentation that assumes their include: domain remains in place. Microsoft, for example, documents include:spf.protection.outlook.com in Microsoft 365 SPF guidance and recommends subdomains for external services that are not under direct control.
Once a provider-specific include: is replaced with copied IP ranges, troubleshooting with vendor support becomes harder. The first question is often whether the supported SPF record is still published. If the answer is no, the burden of proof shifts back to the domain owner.
Some teams flatten SPF once during an incident and then never revisit it.
That turns SPF into configuration debt. Months later, nobody remembers where the copied ranges came from, which ones belong to which sender, or which business system would break if one line were removed.
The record may still "work" for the busiest sources and still be wrong for the less visible ones.
RFC 7208 notes that when SPF records are changed, there should be a transition period so the old policy remains valid long enough for legitimate mail that is already in transit to be checked under the expected policy. This matters for all SPF changes, but it matters even more when flattening creates larger, more frequent record rewrites.
Small, repeated authorization edits are not free.
Includes are not magically safe either.
They become a problem when teams keep stacking vendors into one root-domain SPF record until it turns into a dependency graph nobody can audit. That is how domains hit the 10-lookup limit, inherit nested includes they do not understand, and end up with SPF permerror.
Includes are also risky when the sender inventory is unclear. Old vendors often stay authorized long after they stop sending.
So this is not a case of "includes good, flattening bad". It is usually a case of "unsegmented sender architecture bad".
Use this rule of thumb:
include: entries when the provider changes infrastructure dynamically and publishes a supported SPF include for that purposeip4: or ip6: only for sources under direct control or for very stable ranges with a clear ownerThat last point matters most. A surprising number of SPF problems are really domain-design problems.
For example:
example.com for employee and core transactional mailmarketing.example.com for campaign platformssupport.example.com for ticketing systemsalerts.example.com for product notificationsThat approach reduces lookup pressure, reduces blast radius, and makes it much easier to know which team owns which authorization path.
Microsoft's guidance explicitly recommends subdomains for email services that are not under direct control, which lines up with what tends to work best operationally.
This is the highest-value cleanup step.
Before flattening anything, verify which platforms still send mail. Old ESPs, HR systems, event tools, and support desks are often still in SPF long after migration.
Deleting one dead include is better than flattening five live ones.
If one record is carrying too many unrelated services, segmentation is usually cleaner than flattening.
It also improves reputation isolation and troubleshooting. A broken marketing sender should not force emergency SPF edits for employee mail on the organizational domain.
SPF is path-based and tied to the envelope sender domain. DKIM is usually more resilient to infrastructure changes because the signed domain can remain stable even when IPs or outbound relays move.
That does not mean SPF can be ignored. It means the safest posture is usually:
If one sender's SPF design is operationally messy, solid DKIM alignment keeps that stream from becoming a DMARC single point of failure.
Sometimes partial flattening is sensible.
If one source is a stable in-house relay with fixed ranges, publishing those IPs directly may be cleaner than another include. Meanwhile, dynamic providers can stay as includes.
That hybrid model often gets the lookup count down without creating a fully copied third-party dependency map in your DNS.
Automated flattening is much safer than manual copy-and-paste, but only if it has controls:
Without those controls, "automated flattening" is just stale SPF at higher speed.
Best when:
Main risk:
Best when:
Main risk:
Best when:
Main benefit:
Work through this short checklist:
For the DMARC side of the decision, DMARC alignment: From vs Return-Path is the right companion post.
SPF flattening is a tool, not a best practice by itself.
Use it when it reduces real risk and when someone, preferably automation, can keep the copied data current. If the real issue is too many unrelated senders sharing one domain, flattening is usually treating the symptom.
The safest default is usually this: keep supported provider includes, segment mail by subdomain, remove stale senders aggressively, and reserve flattening for stable or tightly managed cases.