Fixing "SPF PermError: Too Many DNS Lookups"

Your SPF record looks fine, every service you use is listed, and yet a checker reports PermError: too many DNS lookups, and messages start failing authentication. This is one of the most common SPF problems for growing businesses, because each new email tool adds another include until the record quietly crosses a hard limit. The fix for SPF too many DNS lookups is not complicated once you understand what is being counted.

Why the limit exists

Evaluating an SPF record can require the receiving server to make further DNS queries: to fetch an included record, to resolve a host name, or to look up MX records. To stop a single message from triggering a flood of queries, RFC 7208 caps the number of mechanisms and modifiers that cause DNS lookups at 10 per SPF evaluation. If evaluation would need more, the result is permerror.

A permerror is not a softfail. Under DMARC it counts as SPF failing, so if your mail is not also passing DKIM with alignment, it will fail DMARC and may be quarantined or rejected depending on your policy.

What counts toward the 10

The catch is nesting. An include costs one lookup itself, plus every lookup inside the included record, plus every lookup inside anything that includes. A single provider's include can cost three or four lookups on its own.

There is a second, lesser-known limit: no more than two "void lookups", meaning lookups that return no records or a non-existent domain. An include pointing to a domain that no longer publishes SPF can trigger it.

Step 1: Count your lookups

Use our SPF, DKIM and DMARC checker, which expands every include and shows the total. To do it by hand, fetch your record and then each included one, either with the DNS lookup tool or from a terminal:

dig example.com TXT +short | grep spf1
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com
 include:servers.mcsv.net include:sendgrid.net include:mail.zendesk.com
 mx a ~all"

dig _spf.google.com TXT +short
dig spf.protection.outlook.com TXT +short
...

Write the tree down. Count 1 for each include, a and mx in your record, then add the lookups found inside each included record, recursively. The total is what receivers will count.

Step 2: Remove what you do not need

This is the safest fix and is often enough on its own.

• Services you no longer use. Old newsletter tools, a previous mailbox provider kept "just in case", a trial of a CRM. Each costs lookups and authorises servers you no longer control.
• Redundant mx and a. If your MX records point at Google or Microsoft, mx duplicates the provider's include. If your website server does not send mail, a does nothing useful.
• Services that do not need to be in SPF. SPF checks the envelope sender (Return-Path). Many marketing and transactional platforms use their own Return-Path domain, or a subdomain of yours, and authenticate your domain through DKIM instead. Check their documentation; if mail passes DMARC through aligned DKIM and their bounce domain, including them in your root SPF adds nothing.

Step 3: Move senders to subdomains

SPF is evaluated for the domain in the envelope sender, so each subdomain has its own separate 10-lookup budget. Configure bulk or transactional platforms to use a sending subdomain, for example news.example.com or mail.example.com, with its own SPF record:

news.example.com.   TXT  "v=spf1 include:servers.mcsv.net -all"
example.com.        TXT  "v=spf1 include:_spf.google.com -all"

With relaxed DMARC alignment (the default), a subdomain envelope sender still aligns with a From address on the root domain. This approach also separates the reputation of your marketing mail from your everyday business mail, which is good practice in its own right.

Step 4: Replace includes with IP ranges where stable

If a sender gives you a fixed, documented set of IP addresses, for example your own office mail server or a dedicated IP at a transactional provider, list them with ip4: or ip6:, which cost nothing. Only do this when the addresses are genuinely fixed and under your control or contractually stable.

Step 5: Flattening, with caution

SPF flattening means resolving all includes into a long list of IP ranges and publishing that instead. It removes the lookups, but it freezes the providers' addresses at a moment in time. When Google, Microsoft or your email platform adds new sending IPs, your flattened record does not know, and legitimate mail starts failing without warning.

If you do flatten, use a service or script that re-resolves and updates the record automatically and frequently, and never flatten by hand once. For most small and medium businesses, steps 2 to 4 are a better first resort.

Verify the fix

1. Publish the new record, keeping exactly one SPF record per name.
2. Re-run the checker and confirm the total is 10 or fewer, ideally with some headroom for the next tool you adopt.
3. Send test messages from each service and confirm spf=pass, or at least dkim=pass with alignment, in the headers.
4. Watch your DMARC aggregate reports for a week for any source that started failing.

Key takeaways

• SPF allows at most 10 DNS-querying mechanisms, including those nested inside includes; exceeding it causes permerror.
• ip4 and ip6 are free; include, a, mx, exists and redirect are not.
• Remove unused services first, then move bulk senders to subdomains with their own SPF.
• Flatten only with automated updating, never as a one-off edit.