The SPF 10-lookup limit: why your SPF record is failing and how to fix it

SPF has a hard rule: a record may require at most 10 DNS lookups to evaluate. Cross that line and the record becomes a permerror, and Gmail, Microsoft and others treat a permerror as a failed SPF check, which quietly pushes your mail toward the spam folder. Here is how to count your lookups and fix the problem.

What counts as a lookup

Not every part of an SPF record costs a lookup. Only mechanisms that require the mail server to query DNS count. Per RFC 7208, these cost one lookup each:

• include: pulls in another domain's SPF record (and every lookup inside that record counts too).
• a / a: resolves an A record.
• mx / mx: resolves MX records.
• ptr / ptr: resolves a PTR record (deprecated. Avoid it).
• exists: runs an existence DNS query.

These cost nothing: ip4:, ip6:, all, redirect (when it short-circuits), exp, and the -/~/? qualifiers. The classic mistake is stacking five or six include: directives for every ESP you have ever used, each of which drags in its own lookups.

Why the limit exists

The 10-lookup cap is a DNS abuse and DoS protection. Without it, a malicious or careless SPF record could force every receiving mail server on the internet to perform unbounded DNS queries for a single message. The limit keeps SPF evaluation fast and bounded. It is not optional. Receiving servers enforce it.

How to count your lookups

Start at your domain's SPF record and walk it left to right:

1. Count each include:, a, mx, ptr and exists: in your record.
2. For each include:, open the included record and count its lookups too. Includes are nested, so a single include can hide 5+ lookups.
3. Add them up. If the total exceeds 10, your record is a permerror.

A typical failing record looks like this:

v=spf1 include:esp-one.com include:esp-two.com
include:esp-three.com include:esp-four.com
include:marketing.com include:crm.com
a mx -all

That is 6 top-level includes plus every lookup nested inside each of them, almost certainly over 10.

How to fix it

The goal is to get your total under 10 while keeping every legitimate sender authorized.

• Remove dead includes. Any ESP you no longer use is a lookup you do not need. This alone often fixes the problem.
• Flatten where you can. Replace an include: of a record that only contains a few ip4: entries with those ip4: entries directly. ip4: costs zero lookups.
• Consolidate to one umbrella include. Many providers (and your own domain) can expose a single SPF record that covers all your sending. Point one include: at it instead of several.
• Drop ptr and mx if you do not need them. ptr is deprecated and mx is rarely required for modern sending. Each is a lookup you can often delete.
• Keep exactly one all at the end. Two all mechanisms is a separate syntax error that also breaks the record.

After you change the record, re-check it. SPF changes propagate over DNS (often 5–30 minutes, sometimes up to 48h at the TTL), so verify with a fresh lookup, not a cached one.

Want this checked automatically every day? Inboxproof Pro monitors your domain around the clock and alerts you the moment a record breaks or an IP gets listed. See pricing →

Related: SPF not working · SPF vs DKIM vs DMARC · SMTP error codes · Email bounce codes