SPF flattening: what to do when you hit the 10-lookup limit

What is the SPF 10-lookup limit?

The SPF 10-lookup limit is a hard cap, written into the SPF specification, on how many DNS lookups a receiving mail server will perform while evaluating your SPF record. The number is exactly 10. If checking your record would require an 11th lookup, the evaluation stops and returns a permanent error, and your mail can be rejected or filtered to spam.

The part that catches people out is that the limit counts more than the entries you can see in your record. Every include statement can pull in other include statements, and each one counts toward the 10. A record that looks like four entries can quietly consume all ten lookups through nesting. That is why domains sending through several email services hit the ceiling without realizing they were close.

The rest of this post covers why the cap exists, how to tell if you are over it, and what to do about it (including when SPF flattening is the right fix and when it is a trap).

Why the SPF 10 lookup limit exists

SPF (Sender Policy Framework) lets you publish a DNS TXT record listing every server authorized to send mail on behalf of your domain. Receiving mail servers query that record to verify a message actually came from a source you approved.

There is a catch. RFC 7208, Section 4.6.4 caps the number of DNS-querying mechanisms in a single SPF evaluation at 10. The mechanisms that count toward this limit are include, a, mx, ptr, exists, and redirect. Plain ip4 and ip6 entries do not trigger DNS lookups, so they cost nothing.

The cap exists to prevent SPF evaluation from becoming a denial-of-service vector. Without it, a single inbound message could trigger dozens or hundreds of recursive DNS queries on the receiving server. Ten is the ceiling.

What happens when you exceed it

When a receiving server hits lookup number 11, it stops evaluating and returns a permerror result. That is not the same as a soft fail or neutral. It is a hard, permanent error. The SPF check is broken, not just inconclusive.

What follows depends on the receiver's policy:

• Gmail treats permerror as a failed SPF check. Combined with strict DMARC, this means rejection. Google's Email Sender Guidelines are explicit about requiring valid SPF.
• Microsoft 365 behaves similarly, folding the failure into its composite authentication score.
• Smaller providers vary, but most default to treating a broken SPF record as suspicious.

The practical result: some percentage of your outbound mail stops arriving. Worse, SPF failures are silent. Senders rarely see bounces. Messages just vanish into spam folders or get dropped entirely.

How SPF lookups add up fast

A typical SaaS company sending through multiple services can burn through 10 lookups before anyone notices. Here is a realistic example:

| Service | Mechanism added | Lookups consumed | |------------------|------------------------------|------------------| | Google Workspace | include:_spf.google.com | 3 (nested) | | Mailchimp | include:servers.mcsv.net | 1 | | HubSpot | include:spf.hubspot.com | 2 (nested) | | Salesforce | include:_spf.salesforce.com| 2 (nested) | | Zendesk | include:mail.zendesk.com | 1 | | Custom MX | mx | 1 |

Total: 10. Add one more service, like a transactional email provider, and you are over the limit. The nested lookups are the real problem. Each include can itself contain more include statements, and every one of those counts toward your budget.

What SPF flattening actually does

SPF flattening replaces include mechanisms (and their nested children) with the raw ip4 and ip6 addresses those includes eventually resolve to. Since IP entries do not consume lookups, a flattened record can authorize dozens of sending sources while staying under the SPF 10 lookup limit.

A simplified before-and-after:

Before flattening (4 lookups consumed):

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

After flattening (0 lookups consumed):

v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:205.201.128.0/20 ... ~all

The flattened version produces the same authorization result but burns zero lookup slots.

The risks of flattening

Flattening is not a set-and-forget fix. It introduces maintenance burden and fragility.

IP ranges change. Google, Microsoft, Mailchimp, and other providers rotate and expand their sending infrastructure regularly. When they add new IP ranges, your flattened record becomes stale. Mail sent from the new IPs will fail SPF checks because those addresses are missing from your record. You will not get a warning when this happens.

Records get long. A single DNS TXT record is limited to 255 bytes per string and 512 bytes total in a standard UDP response. Flattened records with many IP ranges can exceed these limits, requiring you to split across multiple strings or use additional include references, which reintroduces lookups.

Debugging gets harder. When a deliverability issue surfaces, comparing a wall of IP addresses against provider documentation is far more tedious than reading a clean list of include statements.

Safer alternatives to try first

Before you flatten, see if you can reduce your lookup count through simpler methods.

Audit your current record. List every include in your SPF record and ask: is this service still sending mail for this domain? Old trial accounts, decommissioned CRMs, and retired marketing tools leave behind orphaned include statements. Removing even one or two can bring you back under the limit. You can trace the full lookup chain with a DNS lookup tool to see exactly what each include resolves to.

Move services to subdomains. Transactional email (order confirmations, password resets) can run on a subdomain like mail.example.com or notify.example.com. Each subdomain gets its own SPF record with its own 10-lookup budget. This is the cleanest long-term solution because it also isolates sender reputation. A spam complaint against your marketing sends will not drag down your transactional domain.

Consolidate providers. If you are using three different services that all send marketing email, consider routing them through a single relay. Fewer providers means fewer include entries.

Use ip4/ip6 for static infrastructure. If you run your own mail server on a fixed IP, there is no reason to use an a or mx mechanism for it. Replace those with direct IP entries and save a lookup or two.

When flattening is the right call

Sometimes you genuinely need all 12 or 15 services sending from a single domain, and subdomains are not an option due to brand requirements, compliance, or legacy systems. In those cases, flattening is the correct solution, but only with automation.

Manual flattening is a mistake. You will forget to update the record when a provider changes IPs, and deliverability will break at the worst possible time.

Automated flattening services monitor the IP ranges behind your include statements and update your DNS record when they change. Most work by having you point your SPF record at a CNAME or dedicated include that they manage. This keeps the record current without manual intervention.

If you go this route, set up monitoring to catch any drift. Check your SPF record weekly against what it should resolve to, and alert on mismatches.

How to check your current lookup count

You can count lookups manually by tracing every include, a, mx, redirect, exists, and ptr mechanism in your record and its children. Or you can use a tool to do it in seconds.

The AcuityScan SPF Record Generator parses your existing record, counts total DNS lookups, and flags when you are at or over the limit. For a broader view of your domain's email authentication posture, including DKIM alignment and DMARC policy, run a full scan at acuityscan.com. The email module validates SPF syntax, checks DMARC enforcement, and scans against 77 verified active email blacklists.

TL;DR

• The SPF 10 lookup limit is defined in RFC 7208 and enforced by major receivers including Gmail and Microsoft.
• Exceeding the limit causes a permerror, which breaks SPF authentication entirely.
• SPF flattening replaces include mechanisms with raw IP addresses to reduce lookup count.
• Flattening introduces maintenance risk: provider IP ranges change, and stale records cause silent delivery failures.
• Before flattening, try removing unused includes, moving services to subdomains, or consolidating providers.
• If you must flatten, automate it and monitor for drift.