What Is SPF Flattening?

What is SPF?

SPF, or Sender Policy Framework, is an email authentication protocol designed to prevent email spoofing and improve email deliverability. It’s essentially a list of authorized senders for your domain.

An SPF record is a type of DNS record that lists all the authorized sources for your domain’s emails. It typically looks something like this:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

This record indicates that Google’s mail servers and Outlook are authorized to send emails for your domain.

That ~all at the end matters more than it looks. It’s the policy: ~all softfails anything not listed, -all hard-fails it, and ?all stays neutral. It isn’t decoration, and it isn’t optional.

What Is SPF Flattening?

SPF flattening is the process of replacing every include: mechanism in your SPF record with the actual IP addresses behind it.

The reason is a hard limit in the SPF specification. RFC 7208 allows a maximum of 10 DNS lookups when a receiver evaluates your record. Add a handful of email services and you hit it.

Flattening gets you under the limit by removing the lookups entirely. Raw IP addresses don’t require one.

Why the 10-Lookup Limit Forces the Question

Not every part of an SPF record costs a lookup, and knowing which ones do is most of the diagnosis.

Two things make this bite harder than the number suggests.

Lookups are recursive. If you include: a provider whose own record contains three more includes, you’ve spent four of your ten, not one. You can be over the limit with five entries in your record.

This is also why you have to measure your own record instead of counting entries. When we resolved the four providers in the example above (July 2026), every one of them had already flattened its own record to raw IP addresses:

include:_spf.google.com                   0 nested  =  1 lookup
include:spf.protection.outlook.com  0 nested  =  1 lookup
include:send.aweber.com                 0 nested  =  1 lookup
include:spf1.hubspotemail.net          0 nested  =  1 lookup
                                                            total  =  4 lookups

Four services, four lookups, comfortably under the limit. Large providers have an incentive to keep their own records shallow, so the common combinations often cost less than people assume.

The limit bites in two other situations: smaller or older services that still nest includes several levels deep, and domains that have simply accumulated a dozen entries over the years. Either way, resolve your record and count rather than guessing, because these values change without notice.

Going over doesn’t just drop the extra entries. RFC 7208 4.6.4 is explicit: “If this limit is exceeded, the implementation MUST return permerror.” A permerror is a permanent failure of the whole check, so receivers can treat mail that would otherwise have passed as unauthenticated. That means spam folders or outright rejection, and it applies to every message from the domain.

If you’re seeing “too many DNS lookups” in an SPF checker, permerror is what your recipients’ mail servers are seeing.

The spec adds a second, quieter limit: implementations “SHOULD limit void lookups to two.” A void lookup is one that returns nothing, so records pointing at includes that no longer exist can fail even when you’re under ten.

How SPF Flattening Works

Before we get into flattening, let’s consider a typical SPF record for a business using multiple email services:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:send.aweber.com include:spf1.hubspotemail.net ~all

This record uses several include mechanisms, each of which requires a DNS lookup to resolve. If any of these included domains have their own includes, you can quickly hit the limit.

The SPF Flattening Process

Flattening resolves those include statements down to the IP addresses they represent:

1. Check the record. Identify every include mechanism.
2. Resolve each one. Look up the SPF record each include points to.
3. Recurse. Repeat until no include statements remain, only IP addresses.
4. Remove duplicates. Providers often overlap.
5. Consolidate into ranges. Adjacent addresses collapse into CIDR blocks.

The result is a record with no lookups in it:

v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 ip4:203.0.113.0/24 ip4:192.0.2.126 ip4:198.51.100.54 ~all

Note that the ~all survives unchanged. Whatever else you alter, the qualifier stays.

Why SPF Flattening Is Risky

Flattening solves the lookup problem by taking on a maintenance problem. This is worth understanding before you commit, because the failure is delayed and silent.

Your providers change IPs without telling you. This is the big one. An include: is a pointer, so when Google or Microsoft adds a sending IP, your record follows automatically. A flattened record is a snapshot. The day a provider rotates an address you haven’t copied, legitimate mail from that service starts failing SPF, and nothing warns you.

You lose the map of what’s what. include:_spf.google.com tells the next administrator exactly what that entry is for. ip4:192.0.2.126 tells them nothing. A year on, nobody can safely remove anything, so entries accumulate.

It widens what you’ve authorized. Flattening a provider’s record often means importing large CIDR blocks covering shared infrastructure. dmarcian’s CTO Tim Draegen, a co-author of the DMARC specification, puts it bluntly: flattening means “most people are initiating SPF records that are authorizing a lot of the internet that isn’t actually doing authentication.” You’re vouching for address space you don’t control.

Long records hit other limits. A single character-string in a DNS TXT record can’t exceed 255 octets, and RFC 7208 §3.4 advises keeping the whole DNS response under 450 octets so it fits in a UDP packet. Flattened records get long, and splitting them across strings is another place to make a mistake.

Manual flattening invites typos. A transposed digit or a dropped period in a long list of addresses produces a record that looks fine and silently fails.

None of this means flattening never has a place. It means it’s a maintenance commitment rather than a fix, and most senders have cheaper options.

What to Do Instead

Try these before flattening. In most cases, one of them is enough.

Audit what’s actually in there. The most common cause of a bloated record is services nobody uses anymore: a trial from two years ago, a newsletter tool you migrated off. Every removed include gives a lookup back, and this costs nothing but attention.

Check what’s really sending first. Your DMARC reports show which services send on your behalf. Prune against that data rather than guesswork, so you don’t remove something still in use.

Split sending across subdomains. This is dmarcian’s recommended approach and the most durable one. Each subdomain gets its own 10-lookup budget, so sending from a subdomain like news.example.com for marketing and mail.example.com for transactional gives you three separate budgets where you had one. It also keeps a reputation problem in one stream from affecting the others.

One caveat: a brand-new subdomain has no sending history, so plan to warm it up rather than moving your full volume across on day one.

Cut the number of providers. Four tools each needing an include is four to eight lookups. Consolidating overlapping services is often the simplest structural fix.

Consider a dynamic SPF service. Tools like AutoSPF and Valimail’s Instant SPF generate a record on demand instead of storing a static list, which sidesteps both the lookup limit and the staleness problem. You’re adding a dependency, so weigh that, but it addresses the actual issue rather than working around it.

Lock down domains that don’t send. For a parked or non-sending domain, v=spf1 -all is the whole record. No lookups, nothing to maintain.

If You Flatten Anyway, Do It Safely

Sometimes you’ve exhausted the alternatives and still need to get under the limit. If so, treat the flattened record as something you maintain rather than something you finish.

Keep the TTL short at first. A low TTL means a mistake propagates out quickly once you fix it. Raise it later, when you’re confident.

Watch your record length. Stay inside 255 octets per string and keep the whole response under 450 octets.

Document every block. Keep a comment somewhere outside DNS mapping each IP range back to the service it belongs to. This is what makes the record maintainable a year from now.

Re-flatten on a schedule. Put a recurring reminder in the calendar to re-resolve the provider records and diff them against what you have. Monthly is reasonable. Quarterly is the outside edge.

Flatten selectively. You don’t have to flatten everything. Flatten the stable providers and keep include: for the ones that change often. That gets you under the limit while leaving the volatile entries self-updating.

Monitor your DMARC reports for new SPF failures. A rise in SPF failures from one source is usually the first sign a provider has rotated addresses.

How to Check Your SPF Record

Before and after any change, verify the record rather than assuming.

Count your lookups. Any SPF checker reports the total, and remember that only the mechanisms in the left column of the table above count.

Look for permerror. This is the result to watch for. It means the check failed permanently, and exceeding 10 lookups is the most common cause.

Confirm you have exactly one SPF record. Two v=spf1 TXT records on the same domain is itself a permerror, and it’s a common accident after a migration.

Check the qualifier survived. Confirm your record still ends in the ~all or -all you intended.

Watch it over time, not just once. Google Postmaster Tools shows how Gmail is treating your authentication, which catches a decayed record before your recipients do.

Test from outside your network. Query the TXT record directly rather than trusting your DNS provider’s control panel, which sometimes displays what you typed rather than what resolves. dig TXT example.com or any public lookup tool will show what receivers see.

MXToolbox’s SPF tools will report your lookup count and flag errors, and your DMARC reports show what receivers actually saw.

A note on sequencing: check the record before you change anything, so you know your starting lookup count and have something to compare against. Flattening a record that was already failing for a different reason just adds a variable.

Common Questions About SPF Flattening

Taking Your Email Deliverability to the Next Level

A clean SPF record is one piece of authentication. Our guide to SPF, DKIM and DMARC covers how the three work together.

One structural point worth noting: the fewer services sending as your domain, the fewer lookups you need. Routing your transactional email through a single dedicated provider keeps your record to one include, which is a large part of why records get bloated in the first place.

Rachel Adnyana

Rachel has been writing about WordPress for a decade and building websites for much longer. Alongside web development, she's fascinated with the art and science of SEO and digital marketing.

See Full Bio