SPF Flattening: Benefits, Risks, and When You Need It

If you've bumped up against the SPF 10 DNS lookup limit, you've probably come across the term "SPF flattening." It's one of the most common solutions people recommend — but it comes with trade-offs that aren't always obvious. This guide explains what flattening is, how it works, when it makes sense, and when you should try something simpler first. For a broader look at SPF configuration, see our complete SPF guide.

What is SPF Flattening?

SPF flattening is the process of replacing include statements in your SPF record with the actual IP addresses those includes resolve to. Instead of telling receiving servers "go look up Google's SPF record to find their IPs," you list Google's IPs directly in your own record.

Before flattening:

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

After flattening:

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:35.190.247.0/24 ip4:167.89.0.0/17 ip4:159.183.0.0/16 ~all

The ip4 entries don't require DNS lookups during SPF evaluation, so your lookup count drops dramatically. That's the core benefit.

Why Flattening Exists

The 10 DNS lookup limit is a hard cap defined in the SPF specification (RFC 7208 Section 4.6.4). Every include, a, mx, and redirect mechanism triggers a DNS lookup, and nested includes count too. A single include:_spf.google.com can use 3-4 lookups on its own because Google's SPF record references additional includes internally.

For businesses using three or more email services, it's easy to exceed 10 lookups. When that happens, SPF evaluation returns a PermError — a permanent failure that can cause emails to be rejected or flagged as spam.

Flattening was developed as a workaround: convert includes to direct IP addresses, which don't count as lookups.

How SPF Flattening Works

The process has three steps:

The result is a record that produces the same SPF evaluation results but uses zero (or very few) DNS lookups.

Benefits of SPF Flattening

Eliminates lookup limit concerns. With all IPs listed directly, you're no longer constrained by the 10-lookup limit. You can authorize as many email services as you need.

Faster SPF evaluation. Receiving servers don't need to chase include chains across multiple DNS queries. The IPs are right there in the record.

Avoids cascading failures. If a provider's DNS goes down temporarily, a normal SPF record would fail the lookup. A flattened record doesn't depend on external DNS queries.

Risks of SPF Flattening

Here's where the trade-offs come in — and they're significant.

IP addresses change

Email providers regularly add, remove, and rotate IP addresses. Google, Microsoft, SendGrid, and every other major provider update their infrastructure without notifying you. When they change IPs:

• Your flattened record still lists the old IPs
• New sending servers aren't authorized in your record
• Emails from those new servers fail SPF checks
• You may not notice until deliverability drops

Records can get very long

A fully flattened record can contain dozens of IP ranges. Some DNS providers have trouble with very long TXT records, and the record becomes harder to read and maintain.

You lose automatic updates

With include statements, providers manage their own IP lists. When SendGrid adds a new data center, they update their SPF record and your include:sendgrid.net automatically picks it up. With flattening, you lose that — and must manually track every provider's IP changes.

Manual Flattening vs. Automated Services

Manual flattening

You can flatten your SPF record yourself by resolving each include to its IP addresses and listing them directly. This costs nothing but requires regular maintenance — set a monthly reminder to re-check IPs and update your record. It works best when you have a simple setup with 1-2 providers that use stable IP ranges.

Automated flattening services

Several third-party services automate flattening by continuously monitoring provider IPs and updating your record when changes occur. They eliminate manual maintenance and catch IP changes within hours. The trade-off is ongoing cost and a dependency on the service — if it goes down, your SPF record may break.

When You Actually Need Flattening

Before jumping to flattening, consider whether simpler solutions work for your situation.

Try these first

When flattening makes sense

Flattening is the right choice when:

• You've already removed unused includes and consolidated where possible
• Subdomain splitting isn't practical for your organization
• You genuinely need five or more email services on one domain
• You're willing to invest in automated maintenance (or use a flattening service)

When flattening is overkill

You probably don't need flattening if:

• Your SPF record uses 7 or fewer lookups — you have headroom
• You have unused includes you haven't cleaned up yet
• You can move some email to subdomains
• You're only slightly over the limit (removing one service solves it)

A Practical Example

Say your SPF record uses 12 lookups across five services. Before flattening, ask: do you still use all five? If you migrated from Google Workspace to Microsoft 365 six months ago, removing Google's include drops you to about 8 lookups — problem solved. If you truly need all five, consider moving marketing email to a subdomain like mail.yourdomain.com. Flattening should be your last resort, not your first move.

Monitoring After Flattening

Whether you flatten manually or use a service, monitoring is essential. Check your SPF pass rates regularly through DMARC reports. A sudden drop in SPF pass rate likely means provider IPs have changed and your flattened record needs updating.

You should also verify that your DKIM (RFC 6376) is properly configured as a backup authentication method. If your flattened SPF record goes stale, DKIM alignment can still pass DMARC and keep your emails delivering.

References

• RFC 7208: Sender Policy Framework (SPF) — The current SPF specification
• RFC 7208 Section 4.6.4: DNS Lookup Limits — The 10 DNS lookup limit that flattening works around
• RFC 6376: DomainKeys Identified Mail (DKIM) — DKIM specification for backup authentication