The SPF 10-DNS-Lookup Limit — Why Your Email Authentication Silently Fails

SPF has a hard ceiling almost nobody remembers until it bites: evaluating a record may trigger at most 10 DNS lookups. Cross that limit and receivers return permerror — a permanent evaluation error that means your SPF effectively doesn't exist. No bounce lands in your inbox, no dashboard turns red; your mail just quietly loses one of its two authentication legs. And because every SaaS tool you onboard says "just add our include: to your SPF record," most growing companies drift over the limit without changing anything on purpose.

Here's why the SPF lookup limit exists, exactly what counts toward it, how to audit your own record, and the fixes that actually hold up.

Why the limit exists

SPF records are evaluated by the receiving server, live, on every inbound message. Each include: is a DNS query that server must make — and includes can nest, so a single record could fan out into dozens of queries. RFC 7208 caps the fan-out at 10 lookups precisely so that attackers can't turn the world's mail servers into a DNS denial-of-service cannon. The cap is not advisory: the RFC says exceeding it must produce permerror.

What counts toward the 10 (and what doesn't)

Mechanisms that count, each time they appear — including inside nested includes:

• include: — one lookup per include, plus whatever the included record spends
• a and mx — one each
• ptr — one (and it's deprecated; remove it on sight)
• exists: — one
• redirect= — one

Mechanisms that are free: ip4:, ip6:, and all. They're literal data — no DNS required. That asymmetry is the entire fix toolbox, as we'll see.

There's a second, lesser-known tripwire: at most 2 void lookups — queries that return no answer or NXDOMAIN — are allowed before permerror. A couple of stale includes pointing at dead hostnames can kill an otherwise-legal record.

How real records blow the budget

Here's a completely ordinary record for a company using Google Workspace, Microsoft 365 for one team, and two sending services:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com
       include:sendgrid.net include:mailgun.org a mx ~all

Looks like four includes plus two cheap mechanisms. Now expand it. As of writing, _spf.google.com contains three nested include: mechanisms of its own (_netblocks, _netblocks2, _netblocks3) — so Google alone costs 4 lookups. Add roughly 1–2 for Microsoft, 1 each for SendGrid and Mailgun, plus your a and mx:

Google        4
Microsoft     1–2
SendGrid      1
Mailgun       1
a             1
mx            1
              ─────
              9–10

You're at the cliff edge with a completely vanilla setup. The next "just add our include" email from a marketing tool pushes you over, and nothing announces it. (Third-party records change over time, so treat these counts as a snapshot — and recount after any provider migration.)

Why the failure is silent

Two reasons permerror hides so well. First, receivers don't notify senders — the error happens on their side, per message, and simply feeds into filtering. Second, DKIM usually masks it: if your mail also carries an aligned DKIM signature, DMARC still passes on the DKIM leg and delivery mostly continues. You're now standing on one leg. The day DKIM hiccups — a key rotation goes wrong, a provider config lapses — you have zero passing authentication, and if you've moved your DMARC policy to quarantine or reject, your own mail starts getting junked or refused.

permerror is also worse than a plain fail under DMARC: it can't be salvaged, and some receivers treat a domain with a permanently broken SPF record with extra suspicion.

How to count your lookups

Do it by hand once — it's genuinely instructive. Pull your record:

dig +short TXT yourdomain.com | grep spf1

Then recursively dig every include: and redirect= you find, tallying as you go with the rules above. You can run the same queries in the browser with the free DNS lookup tool — query TXT for your domain, then for each included hostname, and keep a running count. Remember: a, mx, ptr and exists in any level of the tree count too, not just includes.

Fixes that actually work

In order of preference:

1. Delete what's dead. Old includes for tools you cancelled two years ago are the most common finding — free lookups back, and it removes void-lookup risk.
2. Drop a and mx if redundant. If the hosts they resolve to are static, replace them with explicit ip4: mechanisms, which cost nothing.
3. Question whether each service needs to be in SPF at all. DMARC checks SPF against the envelope (Return-Path) domain. Many sending services use their own bounce domain, so their SPF pass can never align with your From domain anyway — for those, aligned DKIM is what earns the DMARC pass, and their include: in your record is dead weight. Check the provider's docs before cutting, but this one move often reclaims several lookups.
4. Split senders across subdomains. Send marketing from mail.yourdomain.com with its own SPF record and its own 10-lookup budget. This also isolates reputations — a good idea independently.
5. Flatten — as a last resort. See below.

Flattening: pros and cons

Flattening replaces include: mechanisms with the literal ip4:/ip6: blocks they currently resolve to. The pro is real: lookups drop to near zero. The cons are why it's last on the list:

• Providers change their IP ranges without telling you. The moment they do, your flattened record authorises the wrong servers, and legitimate mail starts failing SPF. Flattening is only safe when something re-resolves and republishes the record automatically — it converts a one-time fix into a piece of infrastructure you must run forever.
• The record gets huge. Long records need splitting across multiple TXT strings, and are painful to review by eye.
• You lose auditability. include:_spf.google.com documents intent; forty raw CIDR blocks don't.

If you can get under 10 with steps 1–4, do that instead.

Catch the drift before permerror does

An SPF record isn't broken by mistakes so much as by accumulation — every new tool adds an include, and the record that passed last quarter fails this one. CompleteStatus monitors your SPF, DKIM and DMARC records continuously and alerts you when a record changes or your email authentication weakens, alongside uptime, SSL, DNS and security-header monitoring in one dashboard.

Check your domain's email authentication now with the free DMARC / SPF / DKIM checker, then start monitoring free so the next silent change isn't silent. The free tier allows commercial use.