Mail Sorcery

SPF Flattening Explained: The Trade-Off Nobody Warns You About

Before You Continue

If SPF itself still feels a bit fuzzy, start here:

./demystifying-spf.md

For context on the underlying problem, read ./spf-dns-lookup-limit.md first. Then continue with this guide.

SPF flattening solves one problem. It may also create another. Congratulations, you are now maintaining someone else’s IP ranges.

What SPF Flattening Actually Is

SPF flattening means replacing include mechanisms with the actual resolved IP addresses behind them.

Instead of:

v=spf1 include:mail.marketingplatform.com -all

A flattened record might look like:

v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 ip4:203.0.113.12 -all

The include mechanism costs a DNS lookup. The ip4 mechanism does not. By resolving includes down to their raw IP addresses ahead of time and hardcoding them into the SPF record, you eliminate those lookups entirely.

Why People Flatten SPF Records

The main motivation is almost always the same: getting under the 10 DNS lookup limit covered in ./spf-dns-lookup-limit.md. When a domain has accumulated enough legitimate senders that even a clean, well-maintained SPF record exceeds the lookup limit, flattening becomes an appealing shortcut. Instead of removing systems that are genuinely still in use, you convert their includes into static IP addresses and reclaim the lookup budget.

The Risk: You’re Now Tracking Someone Else’s Infrastructure

Here’s the catch. When you use include:mail.marketingplatform.com, that vendor can change their sending IP addresses whenever they like, and your SPF record updates automatically the next time it’s evaluated, because you’re referencing their DNS record, not a fixed value.

Once you flatten that include into static IP addresses, you’ve frozen a snapshot in time. If the vendor changes or expands their sending infrastructure, and they will, eventually, your flattened SPF record no longer reflects reality. Their legitimate mail starts failing SPF checks, silently, until someone notices deliverability dropping and has to go digging.

The Maintenance Burden Is Real

Flattening isn’t a “set and forget” fix. It shifts ongoing maintenance from “manage which systems are in my SPF record” to “manually track IP address changes across every vendor I’ve flattened.” That’s a worse job, not a better one, unless you have tooling in place to monitor and automatically re-flatten on a schedule.

Some SPF flattening happens through third-party services that handle this monitoring for you, automatically re-resolving and republishing the flattened record when vendor IPs change. If you’re going to flatten manually, be honest with yourself about whether you’ll actually keep it updated six months from now.

When Flattening Makes Sense

You’ve already removed every genuinely unused sender and you’re still over the lookup limit
The remaining includes are for stable, well-established providers unlikely to change IP ranges often
You have monitoring or automation in place to detect and react to vendor IP changes
You understand this is an ongoing commitment, not a one-time fix

When To Avoid It

You haven’t done basic SPF cleanup yet (see ./how-to-fix-spf.md) — flattening a messy record just freezes the mess
The senders involved use dynamic or frequently changing IP ranges, such as many cloud-based marketing or transactional mail platforms
You have no process to monitor for changes, meaning the flattened record will slowly drift out of sync with reality
A smaller, achievable fix exists, like simply removing a deprecated system from the record

Janitor Tip 🧹

Flattening should generally be your last resort, not your first move. Clean up unused senders first. You might find you never needed to flatten anything at all.

Suggested Image

A visual metaphor of a 3D globe or cloud shape being pressed flat under a heavy weight labeled “10 lookup limit,” with small IP address tags scattering out from underneath, some of them already looking slightly outdated or crossed out.