Introduction
SPF flattening is the workaround when the 10-DNS-lookup limit blocks you from adding another sender. It replaces include: chains with raw ip4: mechanisms. The trade-off: lookup headroom in exchange for ongoing IP-maintenance work.
This article covers when flattening is the right tool, when it isn't, and the operational shape.
Why this topic matters
Clients exceeding the SPF lookup limit are common in MSP portfolios — typically mid-market companies that have added SaaS senders organically. Flattening is the recovery; doing it badly creates new problems.
What flattening actually does
include:_spf.google.com resolves to a chain of nested includes that ultimately point to IP ranges. Flattening replaces the include with the actual IP ranges:
Before: “text v=spf1 include:_spf.google.com include:mailgun.org -all “
After (flattened): “text v=spf1 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:35.190.247.0/24 ip4:208.117.48.0/20 ... -all “
The flattened version doesn't consume DNS lookups. The trade: when those IPs change, your SPF is stale.
When flattening is the right tool
- Heavy SaaS sender base with no way to consolidate.
- No platform supporting custom DKIM for some senders, forcing them into SPF.
- Multi-tenant clients with consolidated send infrastructure.
When to avoid flattening
- Senders that publish DKIM — move them to DKIM-only instead.
- Stable simple setups — Microsoft 365 alone doesn't need flattening.
- No tooling for maintenance — stale flattened SPFs break silently.
Step-by-step approach
- Audit current SPF. Identify which includes are exceeding budget.
- Try DKIM migration first. Move senders off SPF where possible.
- For senders that must stay, use a flattening platform that monitors IPs.
- Publish the flattened record.
- Set automated re-flattening alerts. IP changes require record updates.
Best practices
- Use platform automation for ongoing flattening. Manual flattening goes stale.
- Monitor SPF pass rate post-flatten. Drift shows up in aggregate reports.
- Don't flatten by hand for high-change senders. Some senders update IPs frequently.
- Keep the source-of-truth include list. When re-flattening, the include list is the input.
- Document the flattening. Future engineers need to understand the record.
Recommended next step
For each client at 9+ SPF lookups, evaluate flattening vs. DKIM migration. DKIM migration is cleaner; flattening is the fallback.
FAQ
How often do SaaS sender IPs change?
Varies — some monthly, some yearly. Major providers (Google, Microsoft) change slowly; smaller services more often.
Can I flatten with a script?
Yes, but maintenance becomes the hard part. Platform automation usually wins.
Will flattening affect deliverability?
Done correctly, no. The receiver sees the same IPs whether flattened or via include.
Is flattening a permanent fix?
It buys time. The underlying issue — too many senders for the lookup budget — is what to address.
What about TXT record length limits?
A flattened record can be long. TXT records can hold up to 255 chars per string but can have multiple strings concatenated. Most DNS providers handle automatically.
Final thoughts
SPF flattening is a workaround, not a strategy. The right answer is usually DKIM migration; flattening keeps you out of the danger zone while you migrate.
For MSPs, productize the flattening as a managed line item if you have clients who can't migrate quickly. The maintenance is real.