SPF Flattening: Pros and Cons

You've hit the SPF 10 DNS lookup limit. You've removed unused services, you've switched what you can to ip4, and you're still over. Someone suggests SPF flattening. Before you go down that path, you should understand exactly what it does, what it costs, and whether there's a better option. (If you haven't already, check your current lookup count first.)

What SPF Flattening Is

SPF flattening is the process of resolving all include mechanisms in your SPF record into their underlying IP addresses, replacing DNS-dependent mechanisms with explicit ip4 and ip6 entries.

Here's a before and after:

Before Flattening

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

This record uses approximately 7-8 DNS lookups when you count the nested includes inside Google's and Microsoft's SPF records.

After Flattening

v=spf1 ip4:209.85.128.0/17 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:167.89.0.0/17 ip4:13.107.18.10 ip4:52.100.0.0/14 -all

This record uses 0 DNS lookups. Every mechanism is a direct IP comparison.

The flattened record above is simplified for illustration. Real flattened records are often much longer and may require multiple DNS TXT record strings to fit.

How Flattening Works

Resolve each include to its SPF record

Look up the SPF record for each include domain. For example, _spf.google.com resolves to a record with more includes pointing to Google's netblock records.

Follow nested includes recursively

If the included SPF records contain their own include mechanisms, follow those too. Keep going until you reach records that contain only ip4 and ip6 mechanisms.

Collect all IP addresses

Gather every ip4 and ip6 entry from the entire tree of nested records.

Build a new record with only IP mechanisms

Replace all include, a, and mx mechanisms with the collected IP addresses.

Publish the flattened record

Update your domain's DNS TXT record with the flattened version.

The Benefits

Flattening solves the lookup limit problem completely. Here's what you gain:

Zero DNS lookups

A fully flattened record uses only ip4 and ip6 mechanisms, which don't count toward the 10-lookup limit. You can authorize any number of sending sources without worrying about the limit.

Faster SPF evaluation

IP comparisons are faster than DNS lookups. Receiving servers can evaluate your SPF record without making any additional DNS queries, which means faster authentication.

No dependency on third-party DNS

If Google's or Microsoft's DNS servers have a momentary issue, it won't cause temperror results for your SPF checks. All the information is already in your record.

Monitor your SPF record health

Track your SPF, DKIM, DMARC, and MX records daily. Get alerted when provider IP changes break your record.

Start Monitoring

The Risks

Flattening introduces serious operational risks. These aren't theoretical — they cause real email delivery failures.

Provider IPs Change Without Notice

Email service providers regularly add, remove, and rotate IP addresses. When Google adds a new IP block for Gmail sending infrastructure, they update their SPF record (_spf.google.com). If you're using include, your record automatically picks up the change. If you've flattened, it doesn't.

The result: Email sent from Google's new IPs fails your SPF check because those IPs aren't in your flattened record. Your legitimate email gets rejected or sent to spam.

Google, Microsoft, and other large providers change their IP ranges regularly — sometimes weekly. A flattened record that was valid on Monday can be incomplete by Friday.

Maintenance Burden

A flattened SPF record must be monitored and regenerated regularly. This means:

Running a flattening tool daily or weekly to detect IP changes
Automatically updating your DNS record when changes are detected
Monitoring for failures in case the automation breaks
Testing after every update to ensure the record is valid

If you flatten manually and check it once a month, you will miss IP changes and experience deliverability issues.

Record Length Issues

Flattened records can be very long. A single large provider might use dozens of IP ranges. Multiple providers can easily produce a record that exceeds DNS TXT record size limits.

DNS TXT records have a 255-character limit per string. You can use multiple strings concatenated together, but the total practical limit is around 450-500 characters. Flattened records with many providers can exceed this.

The workaround is to use SPF record splitting across subdomains with include mechanisms — but if you're adding includes back to solve the length problem, you're partially defeating the purpose of flattening.

Loss of Transparency

An SPF record with include:_spf.google.com include:sendgrid.net is self-documenting. Anyone looking at it knows you use Google Workspace and SendGrid.

A flattened record with 30 IP ranges tells you nothing about which services are authorized. Debugging deliverability issues becomes much harder when you can't tell which IPs belong to which provider.

Cascading Failure Risk

If your flattening automation stops working (server goes down, API changes, DNS update fails), your SPF record goes stale. You won't know it's broken until email starts failing — which could be days or weeks later.

When Flattening Makes Sense

Despite the risks, flattening is sometimes the right choice:

Scenario	Flattening Recommended?	Why
5+ providers, can't use subdomains	Yes, with automation	No other way to stay under 10 lookups
2-3 providers, approaching limit	No	Use ip4 for known IPs or subdomains instead
Large enterprise with dedicated IP team	Maybe	Can maintain automation, but subdomains are cleaner
Small team, no DevOps capacity	No	Maintenance burden will cause failures
Providers with stable, dedicated IPs	Partial	Flatten only the stable providers, keep includes for dynamic ones

The golden rule: only flatten if you can automate the entire lifecycle — detection, regeneration, DNS update, and monitoring.

How to Flatten Safely

If you decide to flatten, follow these practices to minimize risk:

Use automated flattening tools

Don't flatten manually. Use a tool or script that resolves your includes automatically and generates the flattened record. Run it on a schedule (daily at minimum).

Monitor for IP changes

Set up alerts that notify you when the resolved IPs change. This tells you when a provider has updated their infrastructure.

Automatically update DNS

Use your DNS provider's API to automatically publish updated records when changes are detected. Manual DNS updates are too slow and error-prone.

Keep a record of what each IP represents

Maintain documentation that maps IP ranges to providers. When something breaks, you need to know which IP belongs to which service.

Test after every update

After each regeneration, verify the new record is syntactically valid, under the character limit, and produces the expected SPF results.

Have a rollback plan

Keep the previous working record ready. If a new flattened record causes issues, you need to revert within minutes, not hours.

Alternatives to Flattening

Before committing to flattening, consider these alternatives that solve the lookup problem without the maintenance burden:

Use Subdomains

This is the cleanest solution. Move different email streams to different subdomains:

# Main domain - corporate email only
example.com: v=spf1 include:_spf.google.com -all

# Transactional subdomain
mail.example.com: v=spf1 include:sendgrid.net -all

# Marketing subdomain
marketing.example.com: v=spf1 include:spf.mandrillapp.com -all

# Support subdomain
support.example.com: v=spf1 include:mail.zendesk.com -all

Each subdomain gets its own 10-lookup budget. No flattening needed. The downside: you need to configure each service to use the subdomain as the sending address.

Reduce Provider Count

Do you really need five different email services? Could you consolidate marketing and transactional email through one provider? Every provider you eliminate is several lookups saved.

Replace Includes with IPs for Stable Services

If a service provides dedicated IPs that rarely change (common with enterprise plans), replace the include with ip4 mechanisms. This is partial flattening without the full automation burden:

# Instead of include:stable-provider.com (2 lookups)
ip4:198.51.100.10 ip4:198.51.100.11 (0 lookups)

Only do this for services where you have a direct relationship and will be notified of IP changes.

Use the `redirect` Modifier

If you manage multiple domains with the same SPF policy, redirect lets you maintain one record instead of many. This doesn't reduce lookups per domain, but it simplifies management:

v=spf1 redirect=_spf.example.com

Start with subdomains

For most organizations, moving services to subdomains is the best solution. It's cleaner than flattening, requires no automation, and each subdomain's SPF record is self-contained and easy to understand.

Partial Flattening

You don't have to flatten everything. A pragmatic approach is to flatten only the providers with stable IP infrastructure while keeping include for providers that change frequently:

# Google stays as include (IPs change often)
# SendGrid flattened (you have dedicated IPs)
v=spf1 include:_spf.google.com ip4:167.89.123.45 ip4:167.89.123.46 -all

This reduces lookups while keeping the most dynamic providers as includes that update automatically.

The Bottom Line

SPF flattening is a legitimate technique, but it's a trade-off, not a free lunch. You're trading DNS lookup overhead for ongoing maintenance complexity. For small teams, the maintenance burden usually outweighs the benefit. For large organizations with DevOps automation, it can be the right tool.

Before flattening, ask yourself:

Can I use subdomains instead?
Can I reduce my number of email providers?
Can I replace specific includes with ip4 for stable services?
Do I have the automation infrastructure to maintain a flattened record?

If the answer to questions 1-3 is no and the answer to question 4 is yes, then flattening makes sense. Otherwise, explore the alternatives first. Whichever approach you choose, make sure DKIM and DMARC are also configured to complete your email authentication setup.

Monitor Your New SPF Record

You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.

Never miss an SPF issue

Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.