SPF flattening: how DMARCTrust's SPF Optimizer keeps your email flowing

You add Google Workspace. Then SendGrid for transactional email. Then HubSpot for marketing. Then Zendesk for support tickets. Then a cold outreach tool. Before you know it, your SPF record has 12 include: mechanisms, and you just broke email authentication for your entire domain.

This is the 10 DNS lookup limit, defined in RFC 7208. It is not a soft limit. It is not a warning. When a receiving mail server evaluates your SPF record and the total number of DNS lookups exceeds 10, it returns a PermError. That PermError means SPF fails for every message your domain sends, regardless of whether the sending server is legitimate.

We have seen this problem hit organizations of every size. It is the most common cause of SPF failures we encounter, and it is getting worse as companies adopt more SaaS tools that each require their own SPF include.

Why the limit exists and why it hurts

The 10-lookup limit is a security measure. Without it, an attacker could construct an SPF record that forces receiving servers to perform thousands of recursive DNS queries per inbound email, turning SPF evaluation into a denial-of-service vector.

The problem is that 10 lookups is not many. Each include:, a:, mx:, ptr:, and redirect: mechanism triggers at least one DNS lookup. And includes are recursive: include:_spf.google.com itself contains more includes, and those includes contain more includes. A single Google Workspace include can consume 3-4 lookups from your budget.

A typical mid-size company’s SPF record looks like this:

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

That looks clean. Six includes. But when you count the recursive lookups, you are already at 12-15 DNS queries. The result: PermError. Every email fails SPF. Your DMARC reports light up with failures. Your deliverability tanks.

The manual fix and why it does not scale

The traditional approach to solving this is manual SPF flattening. You look up each include, find the IP addresses it resolves to, and replace the include with those IPs directly in your SPF record.

Instead of include:sendgrid.net, you list the individual IP ranges:

v=spf1 ip4:167.89.0.0/17 ip4:208.117.48.0/20 ...

This works. The IP mechanisms (ip4: and ip6:) do not count toward the 10-lookup limit. You just eliminated a lookup.

But there are two problems.

First, IP addresses change. Email providers add new sending infrastructure, retire old ranges, and redistribute traffic. SendGrid, for example, has changed their IP ranges multiple times. When they do, your flattened record becomes stale, and legitimate email starts failing.

Second, it is tedious. A single include can resolve to dozens of IP ranges spread across multiple nested SPF records. Doing this by hand for six or seven includes is an afternoon of work. Doing it again every time a provider updates their infrastructure is unsustainable.

What SPF flattening actually does

SPF flattening (also called SPF optimization or SPF record compression) automates the manual process. Instead of you looking up IP addresses and pasting them into DNS, a flattening service does it continuously:

1. It reads your SPF record and identifies the include: mechanisms
2. It resolves each include recursively down to the final IP addresses
3. It publishes those IPs in a hosted SPF record on its own infrastructure
4. You point your domain’s SPF to that hosted record with a single include
5. The service monitors for IP changes and updates the hosted record automatically

Your SPF record goes from 12+ lookups to 1. Your SPF budget is no longer a concern. And when Google adds a new IP range to _spf.google.com, the flattening service detects it and updates your record without you lifting a finger.

DMARCTrust SPF Optimizer: flattening built into your DMARC platform

Most SPF flattening tools are standalone products. You pay for a DMARC monitoring platform, then you pay separately for an SPF flattener, then you manage two different dashboards that do not talk to each other.

We built the SPF Optimizer directly into DMARCTrust Pro because SPF management and DMARC monitoring are two sides of the same coin. Your DMARC reports tell you when SPF is failing. Your SPF Optimizer prevents those failures. Having them in one platform means you can see the problem and fix it in the same place.

What it actually does, in detail:

Real-time DNS lookup tracking. When you open the SPF Optimizer for a domain, you see your current DNS lookup count and how close you are to the limit. No guessing, no running third-party tools.

Smart include detection. Not every include can be safely flattened. Mechanisms that use macros (%{d}, %{i}) resolve differently depending on the sending context and must stay as-is. The SPF Optimizer identifies these automatically and keeps them in your record while flattening everything else.

Editable configuration. You choose which includes to flatten and which to keep. Some organizations prefer to keep certain includes for organizational clarity or because those providers explicitly recommend against flattening. You are in control.

Automatic IP resolution and publishing. Once you activate the optimizer, it resolves your selected includes into IP addresses and hosts them at a unique subdomain on our infrastructure. Your SPF record points to one include, and we manage everything behind it.

Hourly monitoring with anti-recursion protection. The optimizer runs on a regular schedule, checking for IP changes across all your included providers. If SendGrid adds a new IP range, we detect it and update your hosted record. Configurable recursion depth limits prevent runaway resolution chains.

Preserved mechanisms. Non-include mechanisms from your original SPF record (like a, mx, or direct IP entries) stay exactly as they are. Nothing gets lost.

A real scenario

Let’s say you run example.com with this SPF record:

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

You run our domain checker and it shows 14 DNS lookups. You are over the limit. Your DMARC reports confirm: SPF is failing across the board.

You open the SPF Optimizer in your DMARCTrust dashboard. It parses your record, identifies the five includes, and shows that all of them are flattenable (no macros). You click “Enable SPF Optimizer”. Within minutes, the system resolves all five includes into their constituent IP ranges and hosts them at example-com.spf.dmarctrust.com.

Your new SPF record:

v=spf1 include:example-com.spf.dmarctrust.com a mx ~all

Three DNS lookups (include:, a, mx). Well within the limit. And when any of those five providers change their IP ranges, the optimizer detects it and updates the hosted record automatically.

When you should not flatten

SPF flattening is not always the right answer. If your domain only uses two or three email services and you are comfortably under 10 lookups, there is no reason to flatten. The extra layer of indirection adds complexity without benefit.

Similarly, if you are using SPF macros for advanced routing scenarios, flattening those includes would break the context-dependent resolution they rely on. The SPF Optimizer detects this and flags those includes as non-flattenable, but it is worth understanding why.

And if your SPF record uses the redirect= mechanism, flattening is incompatible. The redirect= mechanism overrides the entire SPF evaluation chain, so there is nothing to flatten. You need to restructure your SPF setup first.

For domains that have outgrown the 10-lookup limit, flattening is the practical answer. The alternative is manually tracking IP changes across half a dozen email providers, which means stale records and authentication failures sooner or later.

How it compares to other approaches

Some vendors recommend against SPF flattening entirely, suggesting that organizations should instead adopt “SPF best practices” like reducing the number of email services or segmenting senders across subdomains.

That advice is sound in theory. In practice, most organizations cannot easily reduce their email service count. Marketing uses one platform, sales uses another, support uses a third, and the IT team has its own. Subdomain segmentation works but introduces its own complexity around DMARC alignment and organizational overhead.

SPF flattening is the pragmatic middle ground. It solves the DNS lookup limit problem today, for your current infrastructure, without requiring you to reorganize your entire email architecture.

Getting started

The SPF Optimizer is available to all DMARCTrust Pro subscribers. Open your domain in the dashboard, click the SPF Optimizer icon, and you will see your current lookup count, the includes that can be optimized, and a preview of what your record will look like after flattening.

If you are on the Starter plan, the SPF Optimizer page shows your current lookup status with a before/after preview so you can see exactly what you would gain from upgrading.

Not sure if your domain has a lookup problem? Run it through our free domain checker. It shows your total DNS lookup count along with full DMARC, SPF, DKIM, and BIMI analysis.

For a deeper understanding of why SPF failures happen and how to troubleshoot them, see our SPF failure troubleshooting guide. For SPF fundamentals, our SPF overview covers the protocol’s strengths and limitations. For a neutral, in-depth look at when flattening makes sense and when it does not, see our SPF record flattening guide.