The SPF 10-lookup limit, explained

Your SPF record lists every service allowed to send mail as your domain — Google Workspace, your cold-email tool, your CRM. But there is a hard ceiling: SPF checkers may only perform 10 DNS lookups while evaluating your record. Hit number eleven and SPF breaks with a permerror, and nothing warns you until mail starts failing.

What is the 10-lookup limit?

SPF works by checking DNS records in the middle of mail delivery, so the standard (RFC 7208, section 4.6.4) puts a cap on how many DNS queries a check may trigger: 10. Anything in your record that causes a DNS lookup — an include, an mx, a redirect — counts towards that budget, and so do the lookups inside the records those terms point to. If the count passes 10, evaluation stops immediately and the result is permerror (permanent error).

A permerror is not a neutral shrug — most receiving servers treat it as an SPF failure. If your DMARC policy is p=reject and DKIM is not passing as a backstop, that message can be rejected outright or sent to spam. In other words, an overstuffed SPF record quietly breaks deliverability.

Which SPF terms actually count towards the limit?

Only terms that cause a DNS query count. Each one counts as a single term, even if it triggers several DNS queries behind the scenes:

• Count: include, a, mx, ptr, exists, and the redirect= modifier.
• Do not count: ip4, ip6, and all — these are looked up nowhere, so they cost you nothing.

This distinction is the key to every fix later in this guide: swapping DNS-querying terms for plain ip4/ip6 ranges is what "flattening" means.

How do I count the lookups in my record?

Take a record like this one — completely typical for a business using three or four sending services:

Your record shows three include terms, so you might think you are at 3 of 10. The trap is that includes nest: every term inside the included record also counts. Google's _spf.google.com, for example, contains several sub-includes of its own (its netblock lists), and Microsoft's record has nested terms too. In practice, one include of a big provider can cost you four or five lookups, not one.

1. List your own terms. Count the include, a, mx, ptr, exists, and redirect= terms in your record.
2. Look up each provider's record. Query each included hostname's TXT record (or ask the provider) and count its DNS-querying terms.
3. Add them up recursively. Your three includes plus everything nested inside them is your real total. Stay well under 10 — implementations differ slightly, so treat 8 as your working maximum.

If that sounds like tedious work, it is — which is why you should paste your record into the free SPF audit tool instead. It counts the lookups for you, including the nested ones.

What happens when you go over the limit?

The signature symptom is intermittent SPF failures that don't match any single sending IP. Mail passes one day and fails the next, or delivery gets worse right after you added a new service — the classic moment is connecting a second CRM, ticketing tool, or cold-email sender on top of an already full record. Because the failure is a permerror rather than a bad IP, you won't find the problem by checking allowlists; you have to count lookups.

With a p=none DMARC policy you'll mainly see it in your aggregate reports. With p=reject, it costs you real messages — unless DKIM is aligned and passing as the other authentication path. This is why rolling DMARC to enforcement before auditing your SPF budget is risky; see the DMARC rollout guide for the safe sequence.

How do I fix a record that is over the limit?

1. Flatten the record. Replace include terms with the provider's actual IP ranges as ip4/ip6 terms. Since those cause zero DNS lookups, they cost nothing. The trade-off: providers change their IP ranges without telling you, so a flattened record can go stale and start failing legitimate mail. Either re-flatten on a schedule or use a flattening service that watches for changes and updates your record.
2. Remove dead senders. Audit every include and drop services you no longer use — old ticketing tools, marketing platforms you trialled once, the CRM you replaced last year. Most bloated records have at least one.
3. Move services to a subdomain. Each domain gets its own budget of 10, so send newsletters from news.yourdomain.com and transactional mail from mail.yourdomain.com instead of stacking everything on the root domain. This is the cleanest long-term fix for organisations running several platforms.
4. Consolidate where you can. If two services send through the same infrastructure, you may need only one of them in your record.

After any change, re-run the SPF audit tool to confirm you're under the limit — and re-check whenever you add a new sending service. For a refresher on what each part of a record does, see SPF records explained: syntax, lookups & the 10-lookup limit.

Check your own record

Paste your SPF value into the free SPF audit tool to see your lookup count, the nested includes eating your budget, and exactly which term to flatten or remove first.