What Is SPF Flattening and Do You Need It?

The Problem: SPF's 10-Lookup Limit

SPF flattening is a technique that resolves include: mechanisms in your SPF record to their underlying IP addresses, eliminating DNS lookups that count toward the protocol's hard limit. This guide explains how SPF flattening works, why manual flattening is dangerous, and when automated flattening through a service like mxio's Managed SPF is the right solution.

SPF (Sender Policy Framework) lets you publish a DNS record declaring which servers are authorized to send email for your domain. When a receiving server gets an email from your domain, it queries your SPF record and evaluates the mechanisms to determine whether the sending IP is authorized.

The catch: RFC 7208 limits SPF evaluation to 10 DNS lookups. Mechanisms that trigger lookups include include:, a:, mx:, redirect=, and exists:. Mechanisms that do not trigger lookups include ip4: and ip6: (direct IP comparisons).

The 10-lookup limit is total, not per-record. If your SPF record includes _spf.google.com, and Google's record itself contains 3 nested includes, that is 4 lookups consumed (1 for your include + 3 for Google's internal lookups). A typical Google Workspace include costs 3-4 lookups. Microsoft 365 costs 2-3. Add a marketing platform, a transactional email service, and a CRM, and you are over the limit.

When the limit is exceeded, receiving servers return a PermError, which means your SPF record is invalid. See Fix SPF PermError: Too Many DNS Lookups for the full impact.

What SPF Flattening Is

SPF flattening is the process of replacing include: mechanisms (which cost DNS lookups) with ip4: and ip6: mechanisms (which do not). Instead of telling receiving servers "look up this other domain's SPF record and follow its chain of includes," you tell them "here are the specific IP addresses that are authorized."

Before Flattening

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net ~all

This record uses 8-11 DNS lookups (each include plus their nested includes) and can exceed the 10-lookup limit depending on how many nested includes each provider's record contains, producing a PermError.

After Flattening

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:35.190.247.0/24 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:108.177.8.0/21 ip4:173.194.0.0/16 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:167.89.0.0/17 ~all

This record uses 0 DNS lookups (all mechanisms are direct IP comparisons). It is well within the limit. The trade-off: it is longer, harder to read, and the IP addresses will go stale.

How SPF Flattening Works: Step by Step

The flattening process follows this algorithm:

1. Parse the original SPF record — Extract all mechanisms (include:, a:, mx:, ip4:, ip6:, etc.)
2. Resolve each include recursively — For every include: mechanism, fetch the target SPF record, then recursively resolve any includes within that record
3. Collect all terminal IP addresses — At the bottom of the resolution chain, you end up with concrete ip4: and ip6: ranges
4. Deduplicate — Remove overlapping or identical IP ranges
5. Build the flattened record — Construct a new SPF record using only ip4: and ip6: mechanisms plus the all qualifier

The result is a record that authorizes exactly the same IP addresses as the original but without any DNS lookups.

Why Manual SPF Flattening Is Dangerous

You could, in theory, resolve all your includes right now, write down the IP addresses, and publish a flattened SPF record manually. Some guides on the internet suggest exactly this. Do not do it.

Provider IPs Change Without Notice

Email service providers regularly add, remove, and rotate IP addresses. Google publishes IP ranges through _spf.google.com specifically so that changes propagate automatically. Microsoft, SendGrid, Mailchimp, and every other major provider do the same. When you flatten manually, you freeze a snapshot of their IP ranges at a point in time.

When a provider adds new sending IPs (which happens routinely — Google and Microsoft rotate IPs multiple times per year), those IPs will not be in your manually flattened record. Email sent from the new IPs will fail SPF. You will not know until customers or partners report missing emails, or until you notice DMARC failure reports days later.

Stale Records Fail Silently

The failure mode is particularly insidious: your SPF record is technically valid (no syntax errors, no PermError), so automated monitoring that only checks "is the SPF record valid?" will not catch the problem. The record validates fine. It simply does not include the right IPs anymore. Email from the missing IPs silently fails SPF, and if DKIM also fails for any reason, DMARC fails too. mxio's domain health monitoring detects this class of failure by tracking the actual IPs your providers publish, not just record syntax.

The Update Burden Is Unsustainable

Manually checking whether Google, Microsoft, SendGrid, Mailchimp, and your other providers have changed their IP ranges — and updating your DNS accordingly — is a recurring operational burden. Miss one rotation and authentication breaks. This is not a task that should depend on human memory.

Automated SPF Flattening with Managed SPF

Automated flattening services solve the maintenance problem by:

1. Polling provider SPF records on a schedule — Checking every hour or more frequently for IP range changes
2. Rebuilding the flattened record automatically — When a change is detected, the service resolves all includes and regenerates the IP list
3. Updating DNS via API — The new record is published to your DNS automatically, typically via Cloudflare or other API-managed DNS
4. Alerting on changes — You're notified when IP ranges change so you have visibility without manual effort

The CNAME-Based Approach

The most common automated flattening architecture uses a CNAME or include that you point your SPF record at:

v=spf1 include:_spf.flatteningservice.com ~all

The flattening service manages the record at _spf.flatteningservice.com, keeping it updated with all the resolved IPs from your original includes. This uses just 1 DNS lookup (the single include), and the service ensures the underlying IPs are always current.

An even cleaner approach uses a direct include that the flattening service manages under your own domain via API-managed DNS:

v=spf1 include:_spf.yourdomain.com ~all

The service manages the _spf.yourdomain.com record, which contains the flattened IPs. Your root SPF record stays simple and uses only 1 lookup.

The TXT Record Size Limit

SPF records live in DNS TXT records, and DNS has size constraints:

• A single TXT string: 255 bytes maximum
• Multiple strings are concatenated by the receiver, but total record size has practical limits

A heavily flattened record with many ip4: and ip6: ranges can easily exceed 255 bytes in a single string. DNS handles this by splitting the value across multiple quoted strings within one TXT record:

yourdomain.com  TXT  ("v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16"
    " ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20"
    " ip4:66.249.80.0/20 ip4:72.14.192.0/18 ~all")

Receiving servers concatenate the strings before evaluation. This is standard behavior defined in RFC 7208.

However, extremely large records can cause UDP truncation, forcing a TCP fallback that some resolvers may not handle gracefully. While EDNS0 extends the practical UDP limit beyond the original 512 bytes, keeping individual TXT records conservatively sized avoids edge cases with older resolvers. Automated flattening services handle this by splitting the flattened IPs across multiple TXT records under different subdomains, chained together with includes:

yourdomain.com      TXT  "v=spf1 include:_spf1.yourdomain.com include:_spf2.yourdomain.com ~all"
_spf1.yourdomain.com  TXT  "v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ... ~all"
_spf2.yourdomain.com  TXT  "v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ... ~all"

This uses 2 lookups but keeps each individual record within safe size limits.

Who Needs SPF Flattening?

You likely need flattening if:

• Your SPF record exceeds the 10-lookup limit (use the mxio SPF Checker to check)
• You use 4 or more third-party services that send email as your domain
• You're running Google Workspace + Microsoft 365 (hybrid migration or coexistence) plus any other sender
• You cannot remove any existing includes because every service is actively sending

You should consider Managed SPF even if flattening isn't urgent if:

• You're tired of fielding "add this to your SPF" requests from every new vendor
• The person who configured your SPF has left your organization and nobody fully understands the record
• You manage SPF across multiple domains and want a single place to control them
• You need an audit trail for compliance reviews (SOC 2, ISO 27001, or internal security policy)
• You want visibility into your lookup budget at all times, not just when you remember to check

You probably do not need flattening if:

• Your SPF record uses fewer than 7-8 lookups (leaving margin for provider changes)
• You use only 1-2 sending services (e.g., just Google Workspace and one ESP)
• Your domain does not send email (publish v=spf1 -all and you are done)
• You can reduce lookups by removing unused includes first

SPF Flattening Cost-Benefit Analysis

The recommendation is straightforward: if you are over or near the 10-lookup limit and cannot reduce includes by removing unused services, use an automated flattening service. Manual flattening creates a maintenance liability that will eventually cause authentication failures.

mxio's Managed SPF goes beyond automated flattening. Configure your email services once, then manage senders from your dashboard — toggle services on and off, see your live lookup budget, view full change history with before-and-after diffs, and roll back instantly if something goes wrong. When providers like Google or Microsoft change their IP ranges, your record updates automatically. You delegate SPF operations to mxio and stop thinking about it.

Getting Started with SPF Flattening

1. Audit your current SPF — Use the mxio SPF Checker to see your lookup count and which includes you are using
2. Remove unused includes — Before flattening, check if any includes are for services you no longer use
3. Evaluate whether you need flattening — If you are at 8+ lookups with no room to trim, flattening is the right solution
4. Choose automated over manual — The operational risk of manual flattening outweighs the cost of a service. mxio's Managed SPF handles the entire process automatically.
5. Verify after setup — Use the mxio SPF Checker again to confirm your flattened record is valid and within limits

If you're unsure what your SPF checker results mean, use mxio's AI-powered explanations to get a plain-English breakdown of your record's health, lookup budget, and any issues that need attention.

Related Articles

• Fix SPF PermError: Too Many DNS Lookups — Understanding and fixing the 10-lookup limit
• Multiple SPF Records on One Domain — Another common SPF misconfiguration
• SPF ~all vs -all: Softfail vs Hardfail — Choosing the right enforcement qualifier
• Emails Going to Spam — How SPF issues affect deliverability
• Complete Email Authentication Guide — How SPF, DKIM, and DMARC work together
• Managed Email Authentication — How mxio automates authentication management
• DMARC Deployment Guide — Phased rollout from p=none to p=reject