SPF Flattening Explained: When to Do It and the Hidden Risks
By VigilDog Team · August 20, 2026 · 7 min read
SPF flattening is one of those fixes that solves a real, painful problem and quietly hands you a new one. If your SPF record has crept past the DNS lookup limit and mail is failing authentication, flattening looks like the obvious escape hatch. Sometimes it is. But it trades a static limit for an ongoing maintenance burden, and done carelessly it can break the very deliverability it was meant to protect. Here's when it earns its place and when it doesn't.
The problem flattening solves: the 10-lookup limit
SPF is published as a single DNS TXT record that says which servers may send mail for your domain. The catch is a hard rule in the SPF spec (RFC 7208): evaluating your record may trigger no more than 10 DNS lookups. Every include:, a, mx, ptr, exists, and redirect mechanism costs a lookup, and includes nest — one include: can pull in several more.
Stack up Google Workspace, a marketing platform, a helpdesk, a payment processor, and a CRM, and you blow past 10 fast. When you do, the receiver returns a PermError, and many treat that as authentication failure. The record you added to help deliverability now hurts it. That's the pain flattening addresses.
What SPF flattening actually is
Flattening means resolving all those include: chains yourself, ahead of time, and replacing them with the raw IP ranges they point to — ip4: and ip6: mechanisms. IP mechanisms cost zero DNS lookups, so a flattened record can list dozens of sending sources while staying comfortably under the limit.
In effect you're caching, into your own DNS record, the answer that your senders' SPF records would have resolved to. It works because the receiver now sees a flat list of authorized IPs instead of a tree of includes it has to chase. The problem is baked into that same sentence: you've frozen a snapshot of infrastructure you don't control.
When flattening is the right call
Flattening genuinely makes sense in a narrow set of situations — mainly when you've exhausted the cheaper fixes and still can't get under 10 lookups.
- You've already removed unused senders and consolidated overlapping providers, and you're still over the limit.
- You have automation that re-resolves and re-publishes the flattened record on a schedule — this is the non-negotiable part.
- Your senders publish stable IP ranges, or you're only flattening the ones that do.
- You control DNS and can update the record quickly when something changes.
The hidden risks
The big one is IP drift. Large senders — Google, Microsoft, ESPs — change and rotate their sending IPs regularly, and they do it precisely because they publish an include: you're supposed to re-resolve on every check. When you flatten, you snapshot their IPs at one moment. The day they add a new sending range, your flattened record doesn't know about it, that server isn't authorized, and legitimate mail starts failing SPF — silently, because nothing errors; messages just land in spam or bounce.
That turns SPF from set-and-forget into a maintenance commitment. A flattened record is only correct on the day it's generated. Without automation to refresh it, it decays. And a subtler trap: flattening can inflate your record past the 255-character-per-string and 512-byte practical DNS limits, forcing multi-string TXT records that some tools handle badly. You've removed one limit and marched toward another.
Manual flattening — pasting IPs in once and forgetting — is the worst of both worlds and the most common way it's actually done. If you can't automate the refresh, you probably shouldn't flatten.
Safer alternatives, and how to stay safe if you flatten
Before flattening, exhaust the cheaper wins. Audit your record and remove senders you no longer use — old records accumulate dead includes. Consolidate providers where you can. Some organizations also use subdomains to segment sending (marketing mail from a subdomain with its own SPF), which spreads the lookup budget instead of cramming everything into the root domain. Our guide on fixing SPF, DKIM, and DMARC covers the full cleanup, and you can check your current record and lookup count with the free DMARC checker.
If you do flatten, treat the record as live infrastructure: automate the re-resolution, and monitor the published record for changes and for authentication failures. Because SPF underpins DMARC, a quietly broken SPF record can stall a DMARC enforcement rollout or cause legitimate mail to fail once you're at p=reject. Continuous monitoring of SPF, DKIM, and DMARC — like VigilDog's email deliverability checks — catches a stale flattened record before it turns into a deliverability incident.