SPF 10 DNS Lookup Limit: Why SPF Breaks and How to Fix It

If your domain's mail suddenly fails authentication, the SPF 10 DNS lookup limit is one of the first things to check. SPF (Sender Policy Framework) lets a receiver ask DNS which servers may send mail for your domain — but the standard caps how much DNS work that one check may do. Cross the cap and SPF stops returning a clean pass.

This limit trips up domains that pick up sending services over time: a CRM here, a help desk there, a marketing platform, each with its own include. This post explains exactly what counts toward the limit, what happens when you exceed it, and three ways to fix it — including where SPF flattening helps and where it quietly creates a new problem.

What the SPF 10 DNS lookup limit means#

SPF lives in a single DNS TXT record starting with v=spf1. When a receiver evaluates it, some mechanisms make their own DNS queries to resolve. RFC 7208 section 4.6.4 says implementations MUST limit the total number of those DNS-querying terms to 10 during a single evaluation, to avoid putting an unreasonable load on the DNS.

Six terms count toward that limit: the include, a, mx, ptr, and exists mechanisms, plus the redirect modifier. Three do not, because they need no DNS query at evaluation time: ip4, ip6, and all (the exp modifier is also exempt). So a record can list dozens of ip4 blocks and still make zero lookups.

The count is for the whole resolved tree, not the top-level record. An include can point to a record that itself contains more includes, and every one of those nested terms counts against the same limit of ten. When the total goes over ten, the standard says the evaluation MUST return permerror.

Common causes, and how to confirm each#

Almost every permerror-from-lookups case comes down to one of these. Confirm the cause before you change anything — the wrong fix can authorize an IP you did not mean to, or drop mail you still send.

Fix 1: Remove includes you no longer use#

This is the first fix to try because it is the safest and often enough on its own. Records accumulate includes for tools that were connected once and never removed.

1. 1

   List every term

   Pull your current TXT record and write out each include, a, mx and redirect term it contains.

2. 2

   Match each to a live service

   For every include, confirm you still send mail through that provider. Old CRMs, form tools and marketing platforms often linger in the record for years after you stop using them.

3. 3

   Delete the ones you don't use

   Remove those includes at your DNS host. Each one you drop frees up one or more of your ten lookups.

4. 4

   Re-check the count

   Run an SPF lookup counter again and confirm you are at or below ten before you stop.

Fix 2: Replace includes with published IP ranges#

Because ip4 and ip6 do not count toward the limit, swapping an include for the addresses it resolves to buys back lookups. It works best for services that publish a stable, documented IP range.

1. 1

   Find the provider's published IPs

   Check whether the sending service publishes its IP ranges, usually on a dedicated SPF or IP-range page. If it doesn't, keep the include and pick a different term to cut.

2. 2

   Swap the include for ip4 and ip6

   Replace the include with the exact ip4 and ip6 blocks it currently authorizes. Those mechanisms make no DNS query, so they never count against the ten.

3. 3

   Own the maintenance

   Note the trade-off: you now own that IP list. If the provider adds or rotates IPs, your record is stale until you update it, and real mail can start failing SPF.

4. 4

   Verify

   Re-run the checker and send a test message to confirm it still passes SPF from that service.

Fix 3: Flatten the record — carefully#

Flattening means resolving every include, a and mx down to the raw ip4 and ip6 addresses they authorize today, then publishing that flat list. The record then makes zero or very few DNS queries, so the ten-lookup limit stops being a problem.

It is the most powerful fix and the most dangerous, because it converts a lookup problem into a maintenance problem. Treat it as an ongoing process, not a one-time edit.

1. 1

   Resolve the full tree

   Expand every include, a and mx to the actual IP addresses they authorize right now.

2. 2

   Publish the flat list

   Replace the mechanisms with the resolved ip4 and ip6 blocks so the record makes little or no DNS work.

3. 3

   Automate the refresh

   The flat list is a snapshot. The day a provider changes its IPs, your record is wrong. Use a service or script that re-flattens on a schedule, not a manual paste you will forget.

4. 4

   Watch the record length

   Flattening can push the record past the 255-character-per-string DNS limit. Split it into multiple quoted strings and keep the whole response small.

How to tell which cause you have#

The fastest diagnosis is an SPF checker that expands your whole include tree and shows the running lookup total. Read it top to bottom and match the pattern:

• Total well over ten with many includes: you have stacked or nested includes. Start with Fix 1, then Fix 2 or Fix 3.
• Total close to ten and creeping up: a recently added service tipped you over. Remove or replace the newest include first.
• permerror but the count looks under ten: check for a second SPF record, a syntax typo, or more than two void lookups. Each of those causes permerror on its own, independent of the ten-lookup rule.
• A specific mx term fails: that mx may resolve to more than ten address records, which is its own permerror for that mechanism.

Preventing it from coming back#

SPF records drift. The record that passed last year quietly fails after you connect one more tool. A few habits keep you safely under the limit:

• Audit the record on a schedule — quarterly, or whenever you add or drop a sending service.
• Prefer ip4 and ip6 for services with stable IPs; reserve include for providers whose ranges you cannot pin down.
• Never publish two SPF records on one domain; merge them into a single v=spf1 record.
• Delete ptr entirely, and remove includes for tools you have stopped using.
• Watch DMARC aggregate reports so you see SPF results from real receivers, not only from a checker.

Fixing the SPF 10 DNS lookup limit is a DNS-and-sending-side job, and it is not something a mail client does for you. AI Emaily is not an ESP, a DMARC monitor, or an SPF flattening tool — to edit your record, use a dedicated SPF checker and your DNS host. Where a client matters is the other direction: AI Emaily sends through your existing Gmail, Outlook or IMAP mailbox rather than relaying through a separate service, so connecting it does not add an include to your SPF record or spend one of your ten lookups. On the receiving side, its spam and phishing protection reads the SPF, DKIM and DMARC results on the mail arriving to you. We build AI Emaily, and we would rather point you to the right tool for a DNS fix than pretend it is ours.