SPF · Flattening · Decision guide
SPF flattening: the snapshot bargain, priced honestly
Your include: costs lookups because it is alive: each receiver re-resolves the provider's current ranges at check time (RFC 7208's recursive evaluation — whose result table also means a deleted target returns permerror). Flattening spends that aliveness to buy the limit back. Everything below is about when the trade is fair.
The decision table
| Your situation | Verdict |
|---|---|
| Over the limit because of dead senders still in the record | Prune. Flattening would preserve the corpses in amber — at subscription prices. |
| ESP/marketing sending inflates the ROOT record | Delegate to subdomains (SendGrid/Brevo/SES pattern, Articles #31/#35/#32). The root record shrinks; nothing freezes. |
| Several tools from one vendor family | Consolidate includes where the vendor offers a single family include (Zoho's one.zoho.com, Article #33). |
| Many stable, self-owned servers/ranges, ranges documented and rarely changing | Flattening is legitimate — this is exactly the case RFC 7208 §10.1.2 and Microsoft's guidance bless (with periodic review). |
| Google Workspace / Microsoft 365 among the senders you'd flatten | Don't. Both vendors' own documents say their ranges change often/frequently and flattening is inappropriate there. |
| Still over after all of the above | A monitored flattening service (not a one-time hand flatten) — with the hazards in §3 priced in, and §5's cheaper ladder documented as tried. |
How the services work (their own descriptions)
| Model | As documented by the vendor |
|---|---|
| Managed pointer (AutoSPF, PowerSPF) | Your record is replaced by a pointer (CNAME/TXT) to the vendor, which serves a continuously re-resolved record. AutoSPF states a rescan “every 15 minutes” and prices from its own pages at $37/$97/$387 per month; PowerSPF starts at $8/mo with the flattening as an add-on (their pages). |
| Consolidated include (EasyDMARC EasySPF) | One consolidated include served by the vendor, monitored “every few minutes” (their quotable cadence), with the raw expanded record viewable in their console. |
| One-time/hand flattening (any tool's “flatten” button) | A static expanded record you publish yourself. AutoSPF's own guide concedes the flaw: a hand-flattened record “goes stale” the moment a provider rotates addresses. It has no monitor because it has no service. |
The hazards — mechanism + mitigation
| Hazard | The honest mechanics |
|---|---|
| Staleness window | Between a provider's range change and your next re-flatten, your own mail fails SPF. The window equals the rescan interval (15 min, “a few minutes”) for services — and forever for hand-flattened records. Mitigation: never freeze churning providers (H1 is why the decision table starts there). |
| Size ceilings | Big flat lists hit the DNS string rules (255-octet strings; the RFC's 450-octet UDP guidance — oversized answers risk being “silently ignored”). Vendors split/chunk records to cope (EasyDMARC's own warning echoes the 450 figure) — ask how, before you buy. |
| Policy mangling | Only YOUR root record's all mechanism sets your policy (an included record's -all never governs — RFC 7208 §5.2). A tool that replaces your record writes your policy line: verify the qualifier survives the rewrite, character by character. |
| Availability coupling | With a managed pointer, the vendor's DNS is inside your mail's critical path: a de-provisioned target yields permerror; resolution failure yields temperror (which also fails DMARC's SPF leg). TTLs soften brief outages; they don't repeal the dependency. |
| Exit / lock-in | The expanded record lives in the vendor's zone. No vendor we read documents a post-cancellation grace period — so make exit a pre-purchase question, answered in writing. Exit checklist: export the raw expanded record → publish it as your own record → verify → only then cancel. |
| Over-authorization, frozen | Every range you authorize is attack surface; flattening bakes today's breadth in and removes the provider's own pruning. The inventor's warning list (§4) adds reputation blending and bounces misrouted when subdomains share flattened space. |
| Exposure | A flat record is a complete map of your sending infrastructure in one public answer. Includes were designed, in the RFC's words, for “crossing administrative boundaries” — opacity was part of the point. |
§4 — the inventor's verdict (attributed, in full)
SPF flattening was created by dmarcian (in its SPF Surveyor) — and dmarcian's own retrospective is the most important document in this market: they kept flattening “experimental” for years, concluded the experiment in 2023–24, and declined to productise it, citing reputation blending, misrouted bounces, and over-authorisation risk; their guidance is that flattening is at best a stop-gap whose real danger is permanence, and should be discouraged as a default. When the inventor walks away from his own invention on safety grounds, the honest article reports that before any vendor's pricing table.
And the vendors argue with themselves: EasyDMARC's own blog (“What Is SPF Flattening? How to Avoid It?”) concludes flattening “adds more risk than reliability… it's not advisable. Even automated flattening requires ongoing updates and monitoring” — while EasyDMARC sells EasySPF. PowerDMARC's macros guide argues flattening “becomes outdated quickly and exposes your infrastructure.” AutoSPF promises risks “eliminated” beside its own 15-minute-rescan admission. Read the cautions; they're the vendors' too.
Cheaper first moves (the ladder, in order)
- Count honestly — live-resolve your chain (our lookup guide did this for the big providers: Google costs 1 today, whatever a sales page claims).
- Prune dead senders.
- Delegate ESP sending to subdomains.
- Consolidate vendor families into their single includes.
- Count again. Most domains land under 10 here — flattening never gets its turn, which is the correct outcome.
FAQ
Is flattening against the SPF RFC?
No — the RFC's own appendix blesses flat ip lists as the “best record” shape for stable infrastructure and frames the choice as a resource trade-off (§10.1.2). The sin isn't flattening; it's flattening things that move.
SPF macros instead?
The third road vendors like PowerDMARC argue for (macro-based dynamic records avoid snapshot staleness) — real, more complex, and receiver-support nuances apply. If a vendor proposes macros, evaluate it as its own design with the same hazard questions (§3's exit and availability rows apply to any hosted mechanism).
We're at 9 lookups. Flatten preemptively?
No. 9 is legal; headroom anxiety is a sales tool. Re-count quarterly (cheap) instead of subscribing (permanent dependency).
Sources
RFC 7208 — §5.2 (include semantics/result table), §10.1.1–10.1.2 (the snapshot trade-off in the RFC's own words), §3.3/§3.4 (string/UDP sizes), §4.6.4 (the 10-term limit) · Google Workspace Help (addresses “change often”; use the live record) · Microsoft [MS-SPF] (frequent changes; flattening inappropriate for M365, appropriate for stable ranges, quarterly review) · dmarcian (flattening retrospective) · AutoSPF / EasyDMARC / PowerDMARC (their models, cadences, prices — attributed vendor claims).
Did this guide work for you?
Your reaction tells us whether this guide solved the problem it promised to solve.