Counting your SPF lookups (and why you might be at 11)

The 10-lookup rule, in one sentence

RFC 7208 §4.6.4 says: if evaluating an SPF record requires more than 10 DNS lookups, the evaluation must return permerror. Most mailbox providers treat permerror as a SPF fail. Your domain is now unauthenticated as far as they're concerned — even though you have a long, careful SPF record published.

The kicker: the limit applies across the whole evaluation, including every record you reach via include: or redirect=. So your record might have only one mechanism, but if that one mechanism eventually pulls in 11 lookups underneath, you're already over.

What counts, and what doesn't

These mechanisms cause one DNS lookup each, every time SPF evaluates them:

• include:other.com — the most common cause of bloat
• a or a:host.example
• mx or mx:host.example
• exists:%{i}._spf.example.com — common in macros
• ptr — also deprecated; don't use it
• redirect=other.com — counts the same as include

These mechanisms do not cause DNS lookups:

• ip4:198.51.100.0/24
• ip6:2001:db8::/32
• all (the catch-all qualifier)

Translation: the more your SPF leans on hostname-based mechanisms (especially include:), the more lookups it consumes. The more it leans on raw IP ranges, the cheaper it is.

Why orgs blow past the limit so easily

Each include: can recursively pull in more includes. If you publish:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

That looks like 2 mechanisms, but each of those targets has its own SPF record with more includes inside. _spf.google.com alone resolves to four sub-includes the last time we checked — so a record with three top-level includes can easily resolve to 9 or 10 lookups before you've even noticed.

Add a few common SaaS senders — Mailchimp, SendGrid, Mailgun, Zendesk, your e-commerce platform, your help-desk vendor — and you're at 12 or 13 lookups without trying. Mailbox providers return permerror, your SPF silently breaks, and you don't know unless you're reading DMARC reports closely.

How to come back under 10

1. Know exactly where you stand

Run our SPF tester. It walks every include: recursively, counts lookups against the 10-cap, and shows you the resolved tree — so you can see which include is costing you the most. Most of the time the answer is "Mailchimp's chain" or "the legacy ESP we forgot about."

2. Remove vendors you don't actually use

The cheapest fix. Audit your record for ESPs you tried once and never canceled — old marketing platforms, deprecated transactional services, vendors you migrated away from but never cleaned up. Each one you remove cuts at least 1 lookup, often more.

3. Flatten an include chain

For ESPs whose IP ranges are stable, you can replace include:_spf.example.com with the literal ip4: / ip6: ranges that theirSPF resolves to. This trades 1 lookup (cheap to maintain) for 0 lookups (cheaper to evaluate). The downside: if the ESP changes their IPs and you don't notice, your mail starts failing. Reasonable trade for stable-IP ESPs; bad trade for ESPs that rotate aggressively.

There are services that automate flattening (with monitoring + auto-update). If you're at 11+ and have to add another sender, this is often the fastest path back under.

4. Move some senders to a subdomain

Marketing sends from mail.acme.com, transactional from acme.com. Each subdomain has its own independent SPF record with its own 10-lookup budget. This is also generally good architecture — your transactional mail (password resets, receipts) shouldn't share a deliverability reputation with your marketing blasts.

5. Be ruthless about new vendor adds

Once you're under 10, every new vendor is a budget decision. Don't add a new ESP to SPF without first measuring the lookup cost of their include — and making room by removing or flattening another.

Common myths

"My SPF works because mail keeps getting through."

Mail keeps getting through because some mailbox providers don't strictly enforce permerror, or because your sender's DKIM signature is also passing and DMARC accepts that as alignment. Both are fragile. When the next mailbox-provider update lands or your DKIM signing rotates, your "working" SPF is the first thing that breaks.

"I'll just use ?all instead of -all so it's never strict."

That doesn't help. ?all means "neutral" — receivers don't act on the result either way. It also doesn't count against the 10-lookup limit. The lookup budget breaks evaluation independent of your final qualifier. Use -all once your SPF list is real, and use ~all only while you're still cataloguing senders.

"This is a SPF problem, not a DMARC problem."

It's a DMARC problem. DMARC requires either SPF or DKIM to pass and align. If SPF returns permerror, you've lost one of your two possible alignment paths. If DKIM also fails (or doesn't align), DMARC fails too — and at p=quarantine or p=reject, that's mail going to spam or bouncing.

Related

• SPF tester — paste a domain, see your live lookup count.
• DMARC alignment, in plain English — why SPF passing isn't enough on its own.
• What is DMARC? — the 5-minute primer.