Tools and techniques for flattening an SPF record

SPF flattening converts include: mechanisms into their literal resolved ip4:/ip6: ranges, which cost zero additional DNS lookups to evaluate instead of one or more each. This section assumes you've already confirmed your record needs it - near or over the 10-lookup limit, with no further includes to simply remove.

Doing it manually with dig

For each include: in your current record, resolve what it ultimately authorises:

$ dig txt sendgrid.net +short
"v=spf1 ip4:167.89.0.0/17 ip4:168.245.0.0/17 ... ~all"

If that include itself nests further includes, repeat the lookup on each nested one until you reach only ip4:/ip6: mechanisms. Collect every range, then assemble:

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

This is tedious for a record with several includes, which is exactly what flattening tools automate - but understanding the manual process is what lets you sanity-check a tool's output rather than trusting it blindly.

Using a flattening tool

A flattening tool takes your current SPF record, walks every include recursively, and outputs the flattened equivalent. Several SPF-focused generator and checker tools on the market include this as a feature, alongside dedicated SPF management services aimed at teams who flatten routinely because they manage many sending domains.

Whichever tool you use, treat its output as a draft to verify, not a final answer:

1. Feed it your current record exactly as published.
2. Compare its output's IP ranges against a manual `dig` spot-check of at least one of the includes it resolved - confirming the tool's nesting logic matches what you'd get by hand.
3. Check the output record's total character length. A single DNS TXT record has practical length limits, and a heavily flattened record with many IP ranges can require splitting across multiple quoted strings within the one TXT record - most DNS panels handle this automatically, but verify after publishing.

Step-by-step: from current record to flattened

1. Record lookup. Pull your current SPF record with dig yourdomain.com TXT +short.
2. Pick a flattening approach - manual dig walk for a record with one or two includes, a tool for anything more complex.
3. Generate the flattened record.
4. Spot-check against a manual lookup of at least one included provider.
5. Publish the flattened record, replacing the original - not alongside it; a domain gets exactly one SPF TXT record.
6. Verify with `dig` that the published record matches what you generated.
7. Set a recurring calendar reminder (monthly is reasonable for most) to re-run the flattening process, since a flattened record goes stale the moment any included provider changes its IP ranges.

What a flattening tool does not do for you

• It does not monitor for IP changes after the fact - that re-check is on you, on whatever schedule you set.
• It does not tell you whether flattening was the right call in the first place - removing a genuinely unused include is usually a better fix than flattening a record that's bloated with dead weight.
• It does not replace DMARC aggregate report monitoring - that's still how you'd actually notice a provider added new sending IPs your flattened record doesn't cover, when mail from those new IPs starts failing SPF.

What not to do

• Don't flatten and then never revisit the record - this is the single most common way flattening backfires, turning a working automatic system into a silently stale manual one.
• Don't trust a flattening tool's output without at least one manual spot-check, particularly on records with deeply nested includes.
• Don't flatten a record you could instead fix by simply removing dead or duplicate includes - try that first.

Flattening tool evaluation checklist

FAQ

Is there a difference between flattening SPF manually and using a dedicated SPF management service? A dedicated service typically re-checks and can alert you automatically when a flattened provider's IPs change, which solves flattening's core maintenance problem - manual flattening gets you the immediate fix but leaves re-checking entirely on you.

Should I flatten my entire SPF record, or only the includes pushing me over the limit? Partial flattening - leaving low-lookup-cost includes as-is and flattening only the expensive ones - is often the better trade-off, since it limits how much of your record becomes a manual-maintenance liability.

What's the actual failure a receiving server shows when SPF hits permerror from a stale flattened record? It depends on the receiver, but the practical effect is the same as any other SPF permerror - evaluated as a failure for alignment purposes, regardless of whether the sending IP was legitimate.

MailPilot checks SPF validity continuously as part of its authentication monitoring, so if a flattened record goes stale after a provider's IP change, it surfaces as a failing SPF check against a specific mailbox rather than an unexplained dip in delivered mail weeks later.