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

As soon as a domain accumulates too many sending providers, it hits the infamous SPF ten-DNS-lookup limit. Among the fixes that keep coming up, one carries an intriguing name: SPF flattening. The idea sounds appealing on paper — resolve the includes once and replace them with IP addresses — but it hides a maintenance debt many discover too late. This guide explains exactly what flattening is, how it works, its real risks, and the cases where another approach is wiser.

The problem flattening claims to solve

Quick reminder: every include:, a, mx or ptr in your SPF record costs at least one DNS resolution, and RFC 7208 caps the total at ten. Past that, it's PermError: your SPF is no longer evaluated at all, and your legitimate mail risks quarantine or rejection. Provider includes (Microsoft 365, Google Workspace, a marketing router…) often unfold into several resolutions each, so you cross the limit without noticing.

Flattening attacks this at the root: since includes are what cost resolutions, you remove them — by replacing them with the IP addresses they contain.

How flattening works

The principle is mechanical. For each include in your record, you recursively resolve everything it references (sub-includes, a, mx) until you have the full list of authorized address ranges. Then you replace the include with the corresponding ip4: and ip6:.

Take an example. A classic record:

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

After flattening, it might look like:

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 result contains only ip4:/ip6: — literals that don't count toward the ten-lookup limit. The resolution count drops to zero (apart from the terminal mechanism). On paper, problem solved.

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 for you.

By flattening, you break that link. You freeze a snapshot of the provider's IPs as of the flattening date. The day it switches to a new range you didn't copy, mail sent from that range fails SPF — and you won't see it right away. That's the cruel irony of flattening: you fix a PermError today and expose yourself to silent failures tomorrow.

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, your record goes stale the moment the provider moves. Reserve it for providers whose ranges are stable and documented.
• Automated flattening delegates the tracking to a service that re-flattens periodically and updates your record (often via DNS delegation or an include to a managed record). You swap maintenance debt for a dependency on that service — and, in practice, you reintroduce an include (to the service) into your SPF. That's not bad, but know that you haven't really removed the include machinery, you've moved it.

A real case: the multi-provider SMB

Let's illustrate with a very common situation. 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: you keep it as an include, because freezing it would force you to chase its monthly updates. The signature service, on the other hand, has only a handful of documented fixed IPs: you can write them 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. You only flattened what was safe to flatten. 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:

• you're genuinely stuck above ten resolutions and the other levers aren't enough;
• your providers have stable IP ranges (some infrastructure rarely changes);
• you put monitoring in place that warns you if a provider's IP changes, or you use a reliable automated service.

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. Before reaching for it, exhaust the healthier options:

1. Clean out unnecessary includes. Half of all overflows come from tools you no longer use. It's free and risk-free.
2. Split your streams by subdomain. Marketing on news.your-domain.com, transactional on notif.your-domain.com: each subdomain has its own ten-resolution budget, and you keep the includes maintained by the providers. It's the most durable approach, and the one we recommend first.
3. Replace 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.

Don't sacrifice the terminal qualifier

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 your SPF's strictness — -all (hardfail) remains the right terminal qualifier for a controlled domain. Flattening and weakening are two separate decisions; don't conflate them. The nuance is explained in the -all and ~all mechanisms.

Verify after flattening

Once the record is flattened, check two things:

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 your record.
2. Your sources still pass, over time. Watch your aggregate reports in the following weeks: a source that suddenly starts failing SPF is the signal that an IP range changed and your flattening aged out.

Frequently asked questions

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

Will I have to re-flatten often? It depends on your providers' stability. Some almost never move, others change ranges several times a year. Without an automated service, plan for regular reviews — 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 your more robust DKIM alignment — see how the three protocols work together.

Can I put everything in ip4: and have no includes? Technically yes, but you become 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 you write. Two includes that each unfold into six resolutions are worse than five that resolve to one apiece. Always measure 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. If you're not seeing a PermError, leave your includes alone.

Let Thomas pick the right approach

Should you flatten, clean up, or split into subdomains? The answer depends on your real providers and the stability of their IPs. Thomas, your virtual CISO, unfolds your SPF, identifies the greedy includes, separates the ones you can freeze safely from the ones that move, and recommends the most durable fix for your case — not the most fashionable.

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