How to Fix the SPF "Too Many DNS Lookups" PermError

If your mail is bouncing or getting flagged and a checker says your SPF record has "too many DNS lookups," your record has crossed a hard limit written into the SPF standard itself. This guide covers how to fix SPF too many DNS lookups, from the one-minute diagnosis to the four durable fixes: replacing includes with IP ranges, moving senders onto subdomains, consolidating vendors, and controlled flattening.

The error is common, specific, and fixable without guesswork. The trap is that the limit has nothing to do with how long your record looks. It counts hidden DNS lookups buried inside the services you already trust, so a record with only four or five includes can quietly blow past the cap.

What the SPF 'too many DNS lookups' error actually means#

SPF (Sender Policy Framework) lets a receiving server check whether the server sending your mail is authorized to. To do that, the receiver reads your SPF TXT record and follows every include, a, and mx term it points to — each of which is a live DNS query. RFC 7208, the SPF standard, caps how much of that work a receiver has to do.

The exact rule is in RFC 7208 §4.6.4: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS." Cross the tenth DNS-querying term and the standard requires the receiver to return a PermError — a permanent error meaning your SPF record is broken, not merely that one message failed a check.

That matters because a PermError is treated as an SPF failure. On its own it may only weaken your standing, but paired with a DMARC policy of p=reject it can get messages rejected outright, and receivers like Gmail and Outlook.com bounce or divert affected mail. So the practical symptom is unreliable delivery from a record that looks perfectly fine at a glance.

What counts toward the SPF 10-lookup limit (does ip4 count?)#

The limit counts DNS-querying terms, not characters and not includes alone. Per RFC 7208 §4.6.4, the terms that cause a DNS query are the include, a, mx, ptr, and exists mechanisms, plus the redirect modifier. Each one the receiver evaluates spends one of your ten.

The terms that never query DNS do not count. The RFC is explicit that "the all, ip4, and ip6 mechanisms, and the exp modifier" do not cause DNS queries. So no — an ip4: or ip6: entry does not count toward the limit, no matter how many addresses or CIDR ranges you list. That single fact is the basis of half the fixes below.

Common causes of the SPF lookup error#

Almost every case traces to one of a few patterns. The table below maps each cause to a fast way to confirm it and the fix that follows, so you can go straight to the one you have.

Fix 1: Replace includes with ip4 and ip6 addresses#

The most direct fix uses the rule from the counting table: ip4 and ip6 entries are free. If a vendor publishes a stable, documented list of sending IPs, you can swap their include for those addresses and reclaim the lookups the include cost you.

Only do this for senders whose IPs actually stay put. If a vendor rotates addresses, a frozen list silently stops authorizing real mail — which is why Microsoft warns against pinning dynamic senders like Microsoft 365 (include:spf.protection.outlook.com) and says to keep those as an include.

1. 1

   Expand the include

   Look up the vendor's own SPF record or documentation and note every ip4 and ip6 range it authorizes.

2. 2

   Add the IPs to your record

   Replace include:vendor.example with the ip4: and ip6: values you found, keeping your -all at the end.

3. 3

   Remove the include

   Delete the include line so you are not paying the lookup cost for both the include and the IPs.

4. 4

   Retest

   Re-run an SPF checker and confirm the total lookup count dropped and the record still validates.

Fix 2: Move email services onto subdomains#

Every domain and subdomain gets its own separate 10-lookup budget. Moving a sending service onto a subdomain gives it a clean record of its own instead of crowding your main domain's. Microsoft recommends exactly this for services you do not directly control, such as bulk mailers.

1. 1

   Pick a subdomain

   Choose something descriptive, such as marketing.example.com for a bulk-email service or news.example.com for a newsletter tool.

2. 2

   Point the service at it

   Configure that service to send using the subdomain as its envelope-from domain.

3. 3

   Give the subdomain its own SPF record

   Create a separate SPF TXT record on the subdomain containing only that service's include and a -all.

4. 4

   Remove it from the root record

   Delete that service's include from your main domain's record. Remember: the root record does not cover subdomains, so each one needs its own.

Fix 3: Consolidate the services that send as you#

Often the cheapest fix is to send from fewer places. Every distinct sending service is at least one include, and that count creeps upward as tools get added over the years and never removed. Cutting the list back is free and permanent.

• Audit: list every service that sends mail as your domain and match each one to an include in your record.
• Cut: remove any service you have stopped using, along with its include.
• Merge: where two tools do the same job, standardize on one and drop the other's include.
• Route transactional and marketing mail through as few providers as you reasonably can.

Fix 4: Flatten your SPF record — carefully#

Flattening replaces includes with the IP addresses they currently resolve to, collapsing many DNS lookups into free ip4 and ip6 entries. It works, and it is the last resort when subdomains and consolidation still leave you over the line. The catch is that it trades a maintenance-free record for one whose upkeep you now own.

Treat it as a deliberate maintenance commitment, not a one-time edit. Weigh the trade-offs of flattening before you reach for it, because a stale flattened record fails silently — mail keeps sending, but from IPs your record no longer lists.

How to tell which cause you have#

Diagnosis takes about a minute with the right tool. Run your domain through an SPF checker that reports the total lookup count and expands the include tree, then follow the branch that matches what it shows.

If the total is 11 or higher, you are over the limit — note which includes contribute the most lookups. If one include expands into several nested ones, that vendor is your best candidate for an ip4 swap or flattening. If you see includes for services you no longer recognize, they are stale, so delete those first: it is the fix that costs nothing and risks nothing.

Preventing it from coming back#

The lookup count creeps up over time, so treat your SPF record as something you maintain, not something you set once and forget. A little discipline keeps you clear of the ceiling for good.

• Keep a budget in mind: aim to stay at or below seven lookups so you have headroom for the next vendor.
• Add an include only when you add a real sending service, and remove it the day you stop using that service.
• Prefer subdomains for anything you do not directly control, so the main domain stays lean.
• Recheck the lookup count after any change to your mail stack, and on a recurring calendar reminder.

Does your mail client add to the SPF budget?#

Notice that the count climbs because each new sending service bolts another include onto your record. A mail client you read and reply in is not one of those services. AI Emaily sends through the Gmail, Outlook, or IMAP account you connect, using that provider's own authenticated infrastructure — so it never adds an include or a DNS lookup to your SPF budget, and it will not fix your DNS for you either; the four fixes above and your DNS host handle that. We build AI Emaily, and it triages and drafts on the mailbox you already send from, not a new sending domain you would have to authorize.

If you want that on the inbox you already run, AI Emaily offers a 7-day free trial on its paid plans — and the fix to your SPF record stays exactly the same either way.