What SPF flattening is and when you actually need it

SPF records that use several include: mechanisms - one per email provider you use - can quietly exceed SPF's 10-lookup limit, especially once some of those includes nest further includes of their own. When that happens, SPF evaluation returns permerror, which most receivers treat as a failure regardless of whether your actual sending IPs would have been authorised.

The problem in a real record

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:_spf.salesforce.com ~all

Each include: costs at least one lookup to resolve, and if any of those includes itself contains further includes (common - _spf.google.com nests several), the total lookup count climbs fast. Four top-level includes can easily total eight or more actual lookups once nesting is counted, leaving almost no room before hitting the limit of 10.

What SPF flattening does

Flattening resolves every include:, a, and mx mechanism down to the literal ip4:/ip6: ranges they currently point to, then publishes those ranges directly instead of the include:

Before flattening:

v=spf1 include:sendgrid.net ~all

After flattening (illustrative - the actual ranges are whatever SendGrid currently publishes):

v=spf1 ip4:167.89.0.0/17 ip4:168.245.0.0/17 ip4:198.37.144.0/20 ~all

An ip4:/ip6: mechanism costs zero additional lookups during evaluation - the IP is already in the record, nothing further needs resolving. This is why flattening solves the lookup-count problem.

Why you should think twice before flattening everything

The IP ranges behind an include: are not static. ESPs add and retire sending infrastructure regularly, and the entire reason include: exists is so that when they do, your SPF record updates automatically - you're pointing at their hostname, not a frozen snapshot of their IPs. Flatten a record and that automatic update disappears: if the provider adds new sending IPs and you haven't manually re-flattened, mail from those new IPs will fail SPF, silently, until someone notices and investigates.

Flattening is a reasonable fix when you're clearly over or very close to the 10-lookup limit and reducing the number of senders isn't realistic. It is not a general best practice to apply by default.

Reducing lookups without flattening

Before flattening, check whether you can simply reduce lookups directly:

• Remove unused or dead includes. A sender you stopped using a year ago is still consuming lookup budget.
• Consolidate where a provider offers a single combined include instead of several narrower ones.
• Watch the 2-void-lookup limit too - DNS lookups that return no answer or an error count separately and more strictly; stale includes pointing at decommissioned hostnames are a common source of these.

If you do flatten

1. Resolve every include's current IP ranges (manually with dig, or with a flattening tool - verify its output rather than trusting it blindly).
2. Publish the flattened ip4:/ip6: list in place of the includes.
3. Set a recurring reminder to re-flatten periodically - this is now a manual process you own, not something that updates itself.
4. Monitor DMARC aggregate reports for new, unrecognised sending IPs from the same providers, which would indicate the provider added infrastructure your flattened record doesn't yet cover.

What not to do

• Don't flatten a record that isn't near the lookup limit - you're trading a working automatic system for a manual one with no actual problem to solve.
• Don't flatten once and never revisit it. A flattened record is a snapshot, not a sync.
• Don't flatten as a substitute for removing dead, unused includes - clean those up first; it's usually enough on its own.

Flattening trade-off summary

FAQ

Is SPF flattening the same as "SPF macros" or other advanced SPF features? No - flattening is purely about replacing include: mechanisms with their resolved IP ranges. SPF macros are a separate, more advanced mechanism for dynamic evaluation that most senders never need and that flattening has nothing to do with.

If I flatten once, how long until it's likely to go stale? There's no fixed timeline - it depends entirely on how often the providers you've flattened change their sending infrastructure. Large ESPs can add or retire IP ranges multiple times a year. A monthly or quarterly re-check is a reasonable default absent more specific guidance from the provider.

Does flattening affect DKIM or DMARC at all? No - flattening only changes how SPF's underlying mechanisms are expressed in DNS. It has no effect on DKIM signing or DMARC policy evaluation, which are independent checks.

MailPilot checks SPF validity as part of ongoing authentication monitoring, so a flattened record that's gone stale after a provider's IP change shows up as a failing check rather than an unexplained drop in delivered mail.