What is SPF flattening (and when to actually use it)

v=spf1 include:_spf.google.com include:sendgrid.net -all

v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20
  ip4:167.89.0.0/17 ip4:168.245.0.0/17 ... -all

The trap: providers' IPs change

Here's what enthusiastic guides often forget to say. The IP ranges behind a provider's include are not frozen. Microsoft, Google, SendGrid and the rest add, remove or reorganize their servers regularly. That's the whole point of the include: it points to a record the provider maintains on the domain's behalf.

Flattening breaks that link. It freezes a snapshot of the provider's IPs as of the flattening date. The day the provider switches to a new range that wasn't copied, mail sent from that range fails SPF — and the failure isn't visible right away. That's the cruel irony of flattening: it fixes a PermError today and opens the door to silent failures tomorrow.

The other hidden cost: record size

Maintenance isn't flattening's only downside — there's a purely mechanical one. Replacing a handful of includes with every address range they contain can turn a one-line record into an enormous one. DNS imposes real constraints there: a single TXT string is capped at 255 characters, so a long record has to be split into several strings, and a very large response can exceed what some resolvers handle comfortably over UDP, causing truncation and retries. None of this is insurmountable, but it adds fragility exactly where robustness was the goal — and every re-flattening makes the record churn again. Before flattening everything, the question worth asking is whether the cure produces a record so bulky that it becomes an operational risk of its own.

Manual or automated flattening

To manage that risk, two schools:

• Manual flattening means resolving and copying the IPs by hand. Simple to understand, but that's exactly where the debt bites: without monitoring, the record goes stale the moment the provider moves. It's reserved for providers whose ranges are stable and documented.
• Automated flattening delegates the tracking to a service that re-flattens periodically and updates the record (often via DNS delegation or an include to a managed record). Maintenance debt is swapped for a dependency on that service — and, in practice, an include (to the service) comes back into the SPF. That's not bad in itself, but the include machinery hasn't really been removed, only moved.

A real case: the multi-provider SMB

A very common situation illustrates the point. A small business sends from Microsoft 365 (email), a marketing router, a billing tool and an e-signature service. Its SPF stacks four includes, which unfold into thirteen resolutions — PermError guaranteed. The temptation is to flatten everything at once. Bad idea: three of those four providers change their IP ranges several times a year.

Reading the case correctly starts with sorting providers by the stability of their IPs, not by their volume. Microsoft 365 publishes a rich but well-maintained include: it stays an include, because freezing it would mean chasing its monthly updates. The signature service, on the other hand, has only a handful of documented fixed IPs: they can be written as ip4: with no risk, saving a resolution. The marketing router, a heavy consumer, moves to a news.company.com subdomain with its own SPF — so it leaves the root domain's count entirely.

Result: the root domain now carries only Microsoft 365 (as an include), billing (as an include) and signature (as ip4:), about five or six resolutions — under the limit, and without flattening the most unstable provider. Only what was safe to flatten got flattened. That's the right use of flattening: a targeted scalpel on stable IPs, not an axe on the whole record. The residual maintenance is limited to watching the handful of frozen ip4:, which a quarterly check covers easily.

When flattening is a good idea…

Flattening isn't to be demonized. It has its place when:

• the count is genuinely stuck above ten resolutions and the other levers aren't enough;
• the providers have stable IP ranges (some infrastructure rarely changes);
• monitoring is in place to flag a change in a provider's IPs, or a reliable automated service handles it.

Under those conditions, it's a legitimate tool for keeping a complex record under the bar.

…and when to avoid it

For many organizations, flattening is a disproportionate response. The healthier options come first:

1. Cleaning out unnecessary includes. Half of all overflows come from tools no longer in use. It's free and risk-free.
2. Splitting the streams by subdomain. Marketing on news.example.com, transactional on notif.example.com: each subdomain has its own ten-resolution budget, and the includes stay maintained by the providers. It's the most durable approach, and the one we recommend first.
3. Replacing only the stable-IP providers with ip4:, leaving the moving ones as includes.

In the vast majority of cases, those three levers are enough to get back under ten without the debt of full flattening. The detailed sequence is in the 10-lookup limit.

The terminal qualifier is not to be sacrificed

A reflex to avoid, often seen alongside flattening: using the overhaul as an excuse to switch to ~all "to be safe." Flattening changes nothing about an SPF's strictness — -all (hardfail) remains the right terminal qualifier for a controlled domain. Flattening and weakening are two separate decisions, not to be conflated. The nuance is explained in the -all and ~all mechanisms.

Verifying after flattening

Once the record is flattened, two things call for a check:

1. The resolution count is back under ten, and the syntax is valid — a glance in our free analyzer, as described in how to check an SPF record.
2. The sources still pass, over time. The aggregate reports of the following weeks tell: a source that suddenly starts failing SPF is the signal that an IP range changed and the flattening aged out.

Frequently asked questions

Does flattening improve deliverability? Not directly. It fixes a PermError that was hurting deliverability — so the net effect can be positive. But flattening an SPF already under the limit adds nothing and brings debt.

Does re-flattening come up often? It depends on the providers' stability. Some almost never move, others change ranges several times a year. Without an automated service, regular reviews are the rule — that's exactly the debt to anticipate.

Does flattening also bypass DKIM's limits? The question doesn't arise: DKIM has no resolution limit. The ten-lookup problem is specific to SPF. That's actually a reason to take care of the more robust DKIM alignment — see how the three protocols work together.

Can everything go in ip4:, with no includes at all? Technically yes, but that means becoming responsible for every IP of every provider, forever. That's rarely reasonable, except for a fully in-house-controlled sending infrastructure.

Does flattening fix the duplicate SPF record problem? No, those are two separate issues. Having two v=spf1 records is a configuration error to fix by merging into one — independently of the resolution count.

Is there an official "right" number of includes? No fixed number — what matters is the total resolution count staying at ten or below, not how many include lines are written. Two includes that each unfold into six resolutions are worse than five that resolve to one apiece. What counts is the unfolded tree, not the visible lines.

Should small senders bother with flattening at all? Usually not. A domain with one or two providers is comfortably under the limit and gains nothing from flattening — only the maintenance debt. Flattening is a tool for the genuinely overloaded record, not a default best practice. No PermError in sight means the includes are best left alone.

Thomas picks the right approach

Flattening, cleaning up, or splitting into subdomains? The answer depends on the real providers in play and the stability of their IPs. Thomas, the virtual CISO, unfolds the SPF, identifies the greedy includes, separates the ones that can be frozen safely from the ones that move, and recommends the most durable fix for the case at hand — not the most fashionable.

Analyze a domain for free or create an account to keep a clean SPF under the bar.