SPF Too Many DNS Lookups: Fix the 10-Lookup Limit & PermError

What the 10-lookup limit is

RFC 7208, the SPF specification, caps the number of DNS queries a receiver will make while evaluating your SPF record at 10. The limit exists to stop SPF being used to amplify DNS attacks. If evaluating your record would need an eleventh lookup, the result is permerror (a permanent error), not pass.

A permerror is not a soft warning. Many receivers treat it the same as a failed SPF check, and DMARC counts it as SPF not passing. If your DKIM is also missing or unaligned for that message, DMARC fails outright.

Which mechanisms count — and which do not

• include: — counts 1, plus every lookup inside the included record. include:_spf.google.com alone costs several, because it contains its own includes.
• a and a:host — count 1 each.
• mx and mx:host — count 1 each. In addition, a receiver may look up at most 10 hostnames returned by that MX query; going beyond that is also a permerror.
• ptr — counts 1 and is formally discouraged by the RFC. Remove it; many receivers ignore or penalise it.
• exists: — counts 1.
• redirect= — counts 1, plus the lookups in the record it points to.
• ip4:, ip6: and all — do not count. They are literal values that need no DNS query.
• There is also a void-lookup limit: more than 2 lookups that return no records (NXDOMAIN or empty) causes a permerror too. Old includes for services you no longer use are a common source.

Count your lookups

Take a realistic record: v=spf1 mx a include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net -all. The mx and a cost 2. Each include costs at least 1 and usually more once nested includes are expanded. It is easy to reach 12 or 15 with four or five services.

Do not count by hand — the nested records change without notice. Use an SPF checker that expands every include and reports the total, and re-check whenever a vendor changes its record. Our free DNS checker shows your published SPF record so you can confirm what receivers actually see.

Fixes, safest first

• Remove what you no longer use. Old marketing tools, a previous mailbox provider, a helpdesk you cancelled — each stale include is wasted budget and may become a void lookup.
• Drop mx and a if those hosts do not actually send mail. Many domains have a in SPF only because a template included it; your web server may not send email at all.
• Remove ptr entirely.
• Move senders to subdomains. Marketing mail from news.yourdomain.com gets its own SPF record with its own 10-lookup budget. With relaxed DMARC alignment, news.yourdomain.com still aligns with yourdomain.com.
• Rely on DKIM for services that support custom DKIM signing. DMARC passes when either SPF or DKIM passes aligned, so some services do not need to be in your root SPF at all. Check each vendor’s documentation before removing them — some still need SPF for the Return-Path domain they control.
• Replace an include with ip4:/ip6: ranges only where you control the IPs, such as your own server.

Why SPF flattening is risky

Flattening means replacing include: mechanisms with the IP addresses they currently resolve to, so the record becomes mostly ip4: and ip6: entries that cost no lookups. It works on the day you do it. The problem is that large providers change their sending ranges regularly and without announcement. When they do, your flattened record is silently out of date, legitimate mail starts failing SPF, and nobody notices until DMARC reports or bounces arrive.

Automated flattening services that re-resolve and republish the record continuously reduce that risk, but add a dependency on another vendor controlling your DNS. Treat flattening as a last resort after removing unused senders and moving bulk mail to a subdomain.

Flattened records also get long. A single TXT string is limited to 255 characters, so long records must be split into several quoted strings in one record (receivers join them without spaces), and very large DNS responses can cause problems for some resolvers.

The other common permerror: two SPF records

A domain must have exactly one TXT record beginning with v=spf1. Adding a second one — usually when a new service’s instructions say "add this SPF record" — makes SPF return permerror for every message, even though each record is valid by itself. Merge them: keep one v=spf1 at the start, combine all the mechanisms, and end with a single -all or ~all.

For example, v=spf1 include:_spf.google.com ~all and v=spf1 include:mailgun.org ~all become v=spf1 include:_spf.google.com include:mailgun.org ~all. When you add a mail provider such as HavitoMail, its DNS wizard gives you the mechanism to merge into your existing record rather than a competing second record.