SPF Too Many DNS Lookups: Fix the 10-Lookup Permerror

SPF allows at most 10 DNS lookups per evaluation. Each include, a, mx, ptr, exists and redirect counts, including those nested inside other includes. Go over, and receivers return a permanent error (permerror), which means SPF does not pass. Fix it by removing unused includes, replacing lookups with ip4 ranges, or moving senders to DKIM.

Why the limit exists

SPF evaluation happens while a mail server waits to accept or reject a connection. RFC 7208 caps the number of DNS-querying terms to stop a record from forcing a receiver into an unbounded chain of queries, which would be a handy denial-of-service tool. The cap is in the standard, so it applies at every compliant receiver, and it counts lookups across the whole tree, not just your top-level record.

What counts and what does not

Term	Counts as a lookup?
include:	Yes, plus everything inside it
a / a:domain	Yes
mx	Yes (and each MX host may add address lookups in some evaluations, which RFC 7208 handles with its own limit)
redirect=	Yes
exists:	Yes
ptr	Yes, and discouraged by the standard
ip4: / ip6:	No
all	No

The trap is nesting. A single include:_spf.google.com looks like one lookup, but that record contains further includes. Each nested include also counts. Three or four large vendors can exhaust the limit before you reach your fifth tool.

How to know you are over

BusinessMCP’s SPF guide lists “SPF permerror” as a common failure and names two causes: duplicate SPF records and more than 10 lookups. To check, run your domain through a checker. BusinessMCP’s free email deliverability checker grades the SPF record and will surface errors for you to chase. You can also expand the record by hand: write down each include, open each in a DNS lookup tool, and count nested terms.

Key takeaway: the number to compare against 10 is the total of all nested lookups, not the number of terms you typed.

Step-by-step fix

1. Count. List every term and expand each include recursively until you have a full tree. Mark the total.
2. Delete dead senders. Old marketing tools, a CRM you migrated away from, an ex-vendor’s include. This alone fixes many records.
3. Check for a duplicate record. More than one v=spf1 TXT record at the same name is itself a permanent error. Merge them into one.
4. Replace a and mx with explicit IPs if the addresses are static and yours.
5. Move third-party senders to DKIM-only alignment. If a platform signs with DKIM on your domain, DMARC can pass without SPF alignment, so the platform may not need to be in your SPF record at all. Check your DMARC setup first, using the setup steps.
6. Use a subdomain for a heavy sender. Mail from mail.yourdomain.com evaluates the subdomain’s own SPF record, with its own 10-lookup budget.
7. Re-test after DNS has had time to propagate, which can take up to about an hour depending on TTL.

Flattening: useful but fragile

SPF flattening replaces include: with the actual IP ranges those includes resolve to. It cuts lookups to zero for those terms. The catch is that vendors change their sending ranges. A static flattened record goes out of date silently, and mail from the new range fails SPF. If you flatten:

• Use an automated flattening service or a script that republishes on change.
• Keep a calendar review as a backstop.
• Prefer a vendor’s published stable record over hand-copied IPs.
• Never flatten ranges for a sender you do not understand.

Because of that maintenance burden, trimming and subdomain separation are usually safer first moves.

Softfail versus hardfail is a separate question

Teams sometimes fix a permerror and then wonder whether to end the record with ~all or -all. The qualifier matters much less than correctness. BusinessMCP’s guide describes ~all as softfail and -all as the stricter hardfail. With DMARC enforcement in place, receivers lean on DMARC’s result, so ~all is a common and acceptable choice. Pick one, document it, and spend your effort on the sender inventory instead.

Typical record, before and after

Before (illustrative):

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

Six top-level includes, and nested terms push it well past 10. After an audit shows that only Google Workspace and one transactional provider still send mail, the record can shrink to two includes. The others either were dead or can rely on DKIM alignment. Your list will differ; the process matters, not these names.

What to do when authentication still fails

If SPF now passes but DMARC fails, the likely cause is alignment: SPF passed for a vendor’s bounce domain rather than your From domain. Fix with custom-domain DKIM. See the email deliverability test walkthrough for reading headers, and BusinessMCP’s SPF, DKIM and DMARC guide, which covers the “SPF passes but DMARC fails” case. For details on the exact evaluation rules, read RFC 7208 section 4.6.4 directly, and for provider-specific includes, rely on each provider’s documentation such as Google’s SPF page above.

A maintenance habit

Whenever you add a sending tool, update SPF and DKIM in the same change, re-test, and record the new lookup count. Once a quarter, remove includes for tools you no longer use. For a broader audit routine see how to check email deliverability.

A short audit template

Copy this into a note and fill it in for your domain. It turns a vague worry into a countable problem.

Sender	Mechanism in SPF	Approx. lookups incl. nested	Still in use?	Action
Mailbox suite	include	Check by expanding	Yes	Keep
Marketing platform	include	Check by expanding	Maybe	Confirm, or move to DKIM alignment
Old CRM	include	Check by expanding	No	Remove
Own web server	a	1	Yes	Replace with ip4 if static

Fill the lookup column by expanding each include in a DNS tool, then total it. If the total is 10 or less, you are within the standard. If it is over, remove rows in order of “no longer used”, then “can rely on DKIM”, then “can move to a subdomain”.

Related checks

Once the record is within limits, verify the result. Run the domain through the free BusinessMCP deliverability checker, then send a real message and read the headers for spf=pass. If you want a wider explanation of how SPF, DKIM and DMARC interact, BusinessMCP’s SPF, DKIM and DMARC guide covers the three together, including the cases where SPF passes but DMARC still fails. Bulk senders should also read the Google and Yahoo requirements, because both SPF and DKIM are required once you cross the threshold, which makes a broken SPF record more costly than it used to be.