What is SPF flattening?

SPF records delegate trust through include: mechanisms: include:_spf.google.com means "whatever IPs Google lists are allowed to send as my domain." Every include costs a DNS query at check time, and RFC 7208 puts a hard cap on those queries. Section 4.6.4 states: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS." Exceed it and the RFC is equally blunt: "If this limit is exceeded, the implementation MUST return 'permerror'." The full mechanics live in the glossary entry for the SPF lookup limit at /learning/glossary/spf-lookup-limit; this page is about the workaround everyone reaches for.

Flattening is that workaround. You resolve each include: down to the raw addresses behind it, publish those as ip4: and ip6: terms, and delete the include. Since IP terms cost zero lookups, a record that blew past the limit at 14 lookups can flatten to one that needs none. Your mail passes SPF again, and every checker goes green.

The catch is that an include is a live pointer and a flattened IP list is a snapshot. The provider keeps updating what sits behind their include; your snapshot does not update itself. Flattening trades a visible, immediate problem (permerror today) for an invisible, deferred one (valid mail failing SPF whenever a provider shuffles ranges). That trade can still be worth making, but only deliberately, and only for the right senders.

Take a record that authorizes Microsoft 365, a marketing platform, a helpdesk, and a billing tool through four includes. Each include costs at least one lookup, and includes nest: a vendor's include often contains further includes, and every layer counts against your 10. Fewer than ten include: statements in your record does not guarantee fewer than ten lookups. The glossary entry at /learning/glossary/spf-include covers the nesting mechanics.

A flattening pass resolves that whole tree. include:spf.protection.outlook.com currently expands to six ip4: ranges and five ip6: ranges (checked 2026-07-20 via live DNS); the marketing platform expands to a dozen more. You publish the union as literal IP terms and your lookup count drops to zero. The record gets long (often past the 255-character single-string limit, so it gets split into multiple quoted strings) but it evaluates instantly.

Note what did not change: the set of servers allowed to send as your domain is identical the moment you flatten. Flattening is not a security change. It is a caching decision, and like all caches, the interesting question is what happens on invalidation.

Providers treat their include as the contract and everything behind it as an implementation detail they can change without notice. Microsoft is explicit about its own service in its SPF documentation: do not flatten include:spf.protection.outlook.com, because "Microsoft's sending infrastructure uses dynamic IP addresses that change frequently." The same page allows flattening only for vendors with "stable, documented IP address ranges" and tells you to "review and update the flattened entries at least quarterly." That is the vendor selling you the mail service telling you the workaround needs a recurring calendar entry.

The failure mode is nasty because it is quiet. When a provider adds a range your snapshot lacks, mail from the new IPs fails SPF while mail from the old IPs keeps passing, so delivery degrades partially and intermittently instead of all at once. Nobody gets paged. The evidence shows up in DMARC aggregate reports as authorized senders failing SPF, and, once receivers enforce, as bounced campaigns. If you are at p=reject with no DKIM backstop for that sender, a stale flattened record turns provider maintenance into your outage.

The other cost is ownership. An include meant the provider maintained the record; a flattened record means you do, for every vendor, forever. Multiply that by each domain you run and flattening quietly becomes a standing operational chore with an SLA nobody agreed to.

Prune before you flatten. Most over-limit records carry dead weight: includes for tools the company dropped two years ago, an mx mechanism for a host that no longer sends, a stray ptr. Deleting a defunct include recovers its whole nested lookup cost and removes an authorized sender you no longer trust. Plenty of records get back under 10 on pruning alone.

Segment senders onto subdomains. Point marketing at marketing.example.com and billing at billing.example.com, each with its own SPF record. Every subdomain gets its own 10-lookup budget, and Microsoft's documentation recommends the split for an independent reason: a bulk sender's reputation problem stops bleeding into the domain your employees mail from.

Macro-based (dynamic) SPF. A single exists: mechanism with a macro, like exists:%{i}.spf.example.com, turns each check into one per-IP DNS query against a zone you control, replacing any number of includes with one counted lookup. It is the most elegant answer and the easiest to get wrong, since your DNS zone becomes the authorization engine. See the glossary entry at /learning/glossary/spf-exists for the pattern.

Hosted SPF. A managed service publishes and continuously re-resolves your record, so provider IP rotations propagate without you touching DNS. This is flattening with the maintenance burden moved to software that actually runs on a schedule, and it is the practical choice once the record protects revenue mail. Palisade hosts SPF records this way, alongside hosted DKIM, DMARC, and MTA-STS, with a 100% DNS uptime guarantee.

Nobody flattens SPF for fun. You are fixing lookups because SPF has to pass, aligned, for DMARC to move to enforcement without dropping your own mail. A record that validates today but decays as providers rotate ranges is exactly the kind of landmine that stalls domains at p=none forever, or worse, detonates after you reach p=reject.

Palisade's agent hosts the SPF record, keeps it current as providers change ranges, reads the DMARC aggregate reports to confirm every legitimate sender authenticates, and executes the move to p=reject when the data says it is safe. Monitoring tells you the record broke; enforcement with a maintained record is the point.

Flattening is barely defensible on one domain and indefensible on two hundred. Every tenant that stacks Microsoft 365 plus a PSA-linked mail tool plus a marketing platform is flirting with the limit, and hand-flattened records across a client book means every provider IP rotation becomes a fleet-wide stale-record hunt. Standardize instead: prune at onboarding, segment bulk senders onto subdomains as policy, and put client records on hosted SPF so rotations propagate without a ticket. Palisade hosts SPF, DKIM, and DMARC records per client domain at $9/domain/mo (dropping to $7 at 100+ domains and $5 at 1,000+), walks each domain to p=reject, and files the alerts through native ConnectWise, HaloPSA, and Autotask integrations. Your own MSP domain is a free NFR domain to test the pattern on.