SPF Flattening: The Dangerous Cure for the 10-Lookup Limit

You get the ticket: 'Emails from our new marketing platform are going to spam.' You check the vendor's setup guide, copy the required SPF snippet into your DNS record, and tell the marketing team it'll propagate in an hour. The next day, the ticket is reopened. The problem is worse. Now a DMARC-aware receiver is rejecting the mail outright.

A quick check with a validator tool reveals the dreaded verdict: `permerror`. The reason is as simple as it is infuriating: too many DNS lookups. Your SPF record, which looked perfectly fine, has crossed an invisible line defined over a decade ago.

This is the moment security engineers are tempted by a quick fix called SPF flattening. It works, until it doesn't. And when it fails, it fails silently, taking legitimate email down with it.

The Invisible Wall: SPF's 10-Lookup Limit

The rule is spelled out clearly in RFC 7208, section 4.6.4: 'SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check.' This isn't an arbitrary number. It’s a defense mechanism. Without it, a single incoming email could trigger a cascade of DNS queries from the receiving mail server, creating a vector for DNS amplification attacks. An attacker could craft an email with a malicious SPF record, send it to millions of servers, and point the resulting DNS lookups at a victim, overwhelming them with traffic.

The mechanisms that count towards this limit are `include`, `a`, `mx`, `ptr`, and `exists`. The `ip4`, `ip6`, and `all` mechanisms don't require a lookup and are exempt. The real trouble starts with nested `include` statements. Your company's SPF record might only have three `include`s, but what if each of those vendors includes two or three more in their own records? The lookups multiply quickly.

v=spf1 include:_spf.google.com include:mail.zendesk.com include:_spf.salesforce.com -all — A common-looking SPF record that can easily exceed 10 lookups.

Consider the example above. `_spf.google.com` contains three `include`s of its own. `_spf.salesforce.com` contains a whopping six `include`s, plus an `exists` mechanism. Just those two vendors burn through your entire lookup budget before you even get to Zendesk. The result is a `permerror` during the SPF evaluation. For a receiving server enforcing DMARC, a `permerror` is treated as a `fail`. This isn't a soft-fail; it's a hard failure that can lead to rejection.

Flattening: The Brute-Force Solution

SPF flattening is a process that promises to solve the 10-lookup problem. Instead of relying on a chain of DNS queries, a 'flattener' service or script does the work ahead of time. It recursively queries every `include`, `a`, and `mx` mechanism in your SPF record, collecting all the final IP addresses (IPv4 and IPv6) they point to.

How it Works

The process takes a record like `include:sendgrid.net` and resolves it. It sees that SendGrid's record contains IP ranges like `ip4:198.37.144.0/20` and `ip4:167.89.0.0/17`. The flattener grabs these raw IP addresses and injects them directly into your primary SPF record. The `include:sendgrid.net` statement is removed.

When this is done for all mechanisms, you're left with a single, long TXT record composed almost entirely of `ip4` and `ip6` mechanisms. When a mail server receives an email from you, it fetches this one record. The check becomes instantaneous. 'Is the connecting IP in this list? Yes? Pass. No? Fail.' No further DNS lookups are required. The `permerror` is gone.

The Immediate Payoff

The appeal is undeniable. Flattening transforms a failing SPF configuration into a passing one without forcing a difficult conversation with your marketing department about culling vendors. It feels like a clean, technical solution to a messy, human problem. It gets the ticket closed. But this immediate relief masks a significant, long-term risk.

The Cure Is a Ticking Time Bomb

The problem with replacing a dynamic DNS pointer (`include`) with a static list of IPs is that the underlying infrastructure is anything but static. The IPs you hardcode into your record today may not be the ones your vendor uses tomorrow.

The Staleness Problem

Cloud service providers and email sending platforms change their sending IPs. They do this for load balancing, regional expansion, incident response, and regular network hygiene. They don't send you a memo. The contract is the DNS record; by using `include`, you are agreeing to trust their DNS as the single source of truth. When you flatten, you break that contract.

When your vendor adds a new IP range for their sending MTAs, your flattened record becomes stale. New, legitimate emails sent from those new IPs will now fail SPF authentication. Because you 'fixed' the `permerror`, you might not even be monitoring it. The failures just happen, silently impacting deliverability. The marketing team just sees campaign engagement drop. Sales wonders why quotes aren't being received. This is a far more insidious problem than a noisy `permerror`.

Colliding with DNS Limits

There's another, more immediate problem: DNS record character limits. A single string in a TXT record cannot exceed 255 characters. While most DNS providers allow you to concatenate multiple strings to form a longer logical record, the total length of an SPF record after all strings are combined can't exceed 450 characters of actual mechanism data. Flattening all your providers can easily generate a list of IPs that blows past this limit, trading one type of `permerror` for another.

Smarter Alternatives to Brute Force

Before resorting to flattening, there are more stable and strategic ways to manage your SPF record. The goal shouldn't be to cram everything into one record, but to manage complexity intelligently.

Subdomain Delegation: The Cleanest Approach

This is the gold standard. Instead of having all your third-party services send from your primary domain (`yourcompany.com`), assign them to specific subdomains. Your transactional emails come from `updates@mail.yourcompany.com`. Marketing sends from `deals@promo.yourcompany.com`. Support tickets come from `help@support.yourcompany.com`.

Each of these subdomains gets its own SPF record, and with it, a fresh 10-lookup limit. The SPF record for `promo.yourcompany.com` can contain the specific `include`s for your marketing vendor, while your primary domain's SPF record remains clean, reserved for corporate mail flow like Google Workspace or Microsoft 365. This isolates vendors from each other and dramatically simplifies management.

Relying on DKIM for DMARC Alignment

Remember, DMARC (RFC 7489) offers two paths to a `pass`: SPF alignment or DKIM alignment. As long as *one* of them passes and aligns, the message is considered authentic. Many of the scenarios that break SPF, like forwarding from a mailing list, leave DKIM signatures intact. A forwarded calendar invite from a vendor might fail SPF because the forwarder's IP isn't in your record, but the DKIM signature created by the original sending platform should still validate.

DKIM (RFC 6376) signs the message body and select headers. This signature is generally more resilient to the modifications made by intermediate mail servers (MTAs) than SPF's IP-based check. For organizations struggling with SPF complexity, doubling down on ensuring every sending service has DKIM enabled and aligned is often a more durable strategy than trying to perfect a brittle SPF record. If DKIM is working, an occasional SPF `softfail` or `fail` from a forwarder is deprioritized.

In more complex forwarding chains, the Authenticated Received Chain (ARC), defined in RFC 8617, helps preserve these initial authentication results. An ARC-aware receiver can look at the `ARC-Seal` and `ARC-Authentication-Results` headers to see that the message *was* authenticated upstream, even if SPF is broken by the final hop.

The takeaway

SPF flattening is a tool of last resort, a tactical patch for a strategic problem. While automated flattening services can mitigate the risk of stale IPs, they still treat the symptom, not the disease. The disease is complexity. Your goal should be to reduce the number of services sending mail as your top-level domain in the first place.

Audit your `include`s. Ask which services can be moved to a subdomain. Verify that every single sending platform has DKIM signing enabled. Don't just flatten the mess; clean it up. Your deliverability, security posture, and future self will thank you. Digging into the raw headers and DMARC aggregate reports with a tool like MailSleuth.AI can show you exactly which senders are failing SPF and which are passing with DKIM, giving you the data you need to prioritize your cleanup.