SPF's 10-lookup limit, explained by someone who's hit it 100 times

There's a rule in RFC 7208 — the SPF specification — that breaks more domains than any other single thing in email authentication. It's section 4.6.4, and it says:

SPF implementations MUST limit the total number of DNS lookups to 10.

Read that again. Not the lookup for the SPF record itself. The total number of lookups caused by resolving the record. Every include:, every a, every mx, every exists:, every redirect= counts. If the count exceeds 10, the entire SPF check returns permerror — which most receiving servers treat as equivalent to "no SPF record at all."

This limit was written in 2006. It has not been raised. It is not going to be raised. And every year, thousands more domains quietly cross it and never notice, because the failure mode is invisible to the domain owner and merely "a bit more spam than usual" to the recipient.

How a sensible-looking SPF record goes over the limit

Here's an SPF record I audited recently for a mid-sized UK retailer. Names changed, structure real.

v=spf1 include:_spf.google.com include:spf.protection.outlook.com
       include:servers.mcsv.net include:spf.mandrillapp.com
       include:_spf.salesforce.com include:sendgrid.net
       include:_spf.intuit.com include:mailgun.org
       ~all

Eight includes. Looks reasonable. Someone has clearly added each ESP as the business adopted it — Mailchimp for newsletters, Salesforce for CRM, Intuit for accounting, etc.

Now let's count the actual lookups.

• _spf.google.com → 1 lookup, which itself contains 4 include: directives → 4 more lookups = 5 total
• spf.protection.outlook.com → 1 → contains 2 more includes → 3 total
• servers.mcsv.net → 1 lookup
• spf.mandrillapp.com → 1 lookup
• _spf.salesforce.com → 1 → contains 3 includes → 4 total
• sendgrid.net → 1 lookup
• _spf.intuit.com → 1 → contains 2 includes → 3 total
• mailgun.org → 1 lookup

Add it up: 5 + 3 + 1 + 1 + 4 + 1 + 3 + 1 = 19 lookups.

This record is almost twice over the limit. It has been broken for approximately two years, according to their DNS change history. Nobody noticed because:

1. Gmail and Outlook, when an SPF check errors, usually fall back to other signals (DKIM, historical reputation) before marking mail as spam.
2. The retailer's "why is our email going to spam?" complaints were treated as individual tickets, not correlated.
3. Nobody was reading the DMARC aggregate reports, which were screaming about this.

Why include is a minefield

The real trap is that include:_spf.google.com looks like one lookup but isn't. Google's own record contains four more includes. Each of those might contain more. The full tree can be deep — I've seen include: chains 14 levels deep in the wild, hitting the limit before even covering half the ESPs the company actually uses.

And the chains change without you knowing. Google can add a new include to their SPF record tomorrow and suddenly your previously-compliant record is broken. You didn't change anything. Your SPF broke anyway.

This is the real reason monitoring matters. SPF isn't a "set it and forget it" record. It's a dependency graph that other people control.

The standard advice is wrong

Every SPF guide on the internet tells you the same thing: "flatten your SPF record." Take the IPs from each include: target and inline them into a single record.

Please don't do this.

Flattening works once. Then one of your ESPs rotates their sending infrastructure — which they do, constantly, without notifying you — and half your mail starts failing SPF. You now have to remember to re-flatten every time any of your ESPs makes an infrastructure change, forever. In practice this means you check once when mail starts bouncing, fix it, and then forget until the next outage.

The only solutions that actually work long-term are:

1. Aggressively cull your SPF record. Remove every include: for a service you no longer use. This is the 80% fix that nobody does. Most over-limit records I've audited had at least two stale includes from ESPs the company stopped using three years ago.

2. Consolidate email senders. If you're sending transactional mail through three different ESPs for historical reasons, pick one and migrate. Every sender you cut saves you 1-5 lookups.

3. Use subdomains for separate senders. Your marketing platform sends from email.yourdomain.com, your transactional from notify.yourdomain.com, your corporate from yourdomain.com. Each subdomain has its own SPF record with its own lookup budget. This is the single most effective structural fix and almost nobody does it.

4. As a last resort, use an SPF-flattening service — but understand you are now paying someone £X/month to do a thing that will silently break when they stop paying attention, and you'll be the one explaining to the CEO why the quarterly newsletter went to spam.

How to count your own lookups

The hard way, in bash:

dig +short TXT yourdomain.com | grep "v=spf1"

Then manually recurse every include: and count. Takes about 20 minutes per domain if you're methodical, more if the chains are deep.

The easy way: run the domain through dmarcsentinel.com. The audit tool resolves the full include tree, counts every lookup, shows you exactly which include: is responsible for which lookups, and flags the specific stale entries you can safely cull.

It's free. It's one field. It takes ten seconds.

If you're over the limit, you're over the limit right now as you read this. SPF doesn't have a grace period.

The bit most guides leave out

SPF permerror from lookup overflow doesn't just break SPF. It breaks DMARC alignment for any message that would have passed via SPF. If your DKIM is also misconfigured — and statistically, it probably is for at least one of your ESPs — your DMARC pass rate drops to whatever percentage of your mail is correctly DKIM-signed and aligned. For most organisations, that's somewhere between 40% and 80%.

Which means 20-60% of your mail is failing DMARC, silently, because of an RFC limit written in 2006 that nobody on your team has ever heard of.

Fix the SPF. Then monitor it. Then do the same for all your clients, because if it's happening to you it's happening to them.

Jon Morby has run email and DNS infrastructure since the early 1990s. He built DMARC Sentinel after watching too many agencies discover their clients' email was going to spam the hard way.