SPF Too Many DNS Lookups: What PermError Means and How to Fix It
SPF has a hard limit of 10 DNS lookups. Go over it and your SPF record doesn't just degrade — it fails outright with a PermError, and receiving mail servers treat the result as if you had no SPF record at all. Worse, nothing in your DNS panel will warn you. The record looks valid, publishes fine, and quietly stops working.
This is one of the most common email authentication faults in production, and it usually appears gradually: every new SaaS tool that sends email on your behalf adds another include:, and one day you cross the line.
Where the limit comes from
RFC 7208 section 4.6.4 caps the number of DNS-querying mechanisms a receiving server must evaluate at 10. The limit exists to prevent SPF from being used as a denial-of-service amplifier — without it, a maliciously crafted record could force receiving servers into hundreds of DNS queries per message.
The mechanisms that count against your budget are:
include:— and everything the included record itself looks upaandmxptr— deprecated, remove it if you have itexists:andredirect=
What does not count: ip4: and ip6:. Those are literal addresses, so no DNS query is needed. This matters for the fixes below.
Why counting by eye doesn't work
The trap is that includes nest. Your record might contain only four include: statements, but each one resolves to another SPF record that has includes of its own — and those count too.
Microsoft 365 is a common example. include:spf.protection.outlook.com looks like one lookup, but resolves to a record with further includes of its own. Salesforce, Zendesk and several marketing platforms nest two or three levels deep. Providers also change this over time without notice — Google's _spf.google.com used to expand into three _netblocks includes and now publishes flat IP ranges, which quietly gave every Google Workspace domain three lookups back.
This is why a record that reads as five or six includes can quietly be at eleven.
How to tell if you're over
You can walk the tree manually with dig TXT yourdomain.com, then repeat for every include you find, and every include inside those. For a record of any size this is tedious and easy to get wrong.
Our SPF analyser does the recursion for you: it resolves every nested include, gives you a total against the limit of 10, and identifies which service each include belongs to so you can see what's costing you.
The other signal is your DMARC aggregate reports. If SPF is returning PermError, reports from receiving servers will show it — which is one of several reasons to have an rua= address configured before you need it.
Fix 1: Remove senders you no longer use
Start here, because it's free and carries no downside. SPF records accumulate includes for tools that were trialled once and abandoned, or platforms replaced two years ago. Each one is still costing you a lookup.
Go through every include and confirm it corresponds to a service actively sending mail as your domain today. Your DMARC aggregate reports are the authority on this — they list every source sending on your behalf. If a platform hasn't appeared in reports for months, remove it.
This alone often brings a record back under the limit.
Fix 2: Move marketing mail to a subdomain
Your SPF budget is per-domain. Sending marketing and transactional mail from a subdomain gives that subdomain its own separate budget of 10.
So if example.com handles your corporate mail through Microsoft 365 or Google Workspace, you can send campaigns from mail.example.com or news.example.com with its own SPF record containing only the includes those tools need.
This is the approach large senders use, and it has a second benefit: a deliverability problem caused by a marketing campaign no longer damages the sending reputation of your corporate domain.
Note that your DMARC policy applies to subdomains by default, or you can set sp= explicitly to control subdomain behaviour separately.
Fix 3: SPF flattening — and why to be careful
Flattening means resolving your includes yourself and replacing them with the literal ip4: ranges they point to. Since IP mechanisms don't count against the limit, this can take a record from 12 lookups to zero.
The problem is that you've now hardcoded infrastructure you don't control. When Google, Microsoft, or SendGrid add or retire an IP range — which they do without notice, because the whole point of the include is that they can — your record is silently wrong. Mail from the new ranges fails SPF, and you won't know until something bounces.
If you flatten, treat it as a maintained system, not a one-off edit: it needs automated re-flattening on a schedule and monitoring for drift. Several vendors sell exactly this as a service. If you aren't going to maintain it, fix 1 and fix 2 are safer.
One more consideration: SPF records are also subject to a 255-character-per-string limit and a practical 512-byte DNS response limit. Flattening a large provider can push you into needing multiple concatenated strings, which introduces its own failure modes.
What happens if you do nothing
A PermError means receiving servers cannot evaluate your SPF record, so SPF neither passes nor fails — it simply returns no useful result. For DMARC purposes that means SPF authentication doesn't happen, and you're relying entirely on DKIM for alignment.
If DKIM is configured correctly, mail may still be delivered — DMARC passes if either SPF or DKIM aligns. But you've lost a layer, and if DKIM breaks (a rotated key, a misconfigured selector, a new sender that isn't signing) you have nothing left and your mail starts being rejected, particularly if you're at p=reject.
Being over the lookup limit is a latent fault. It doesn't necessarily break things today, but it removes your margin.
Check your record
The SPF analyser resolves your full include tree, counts every lookup, names the service behind each include, and flags common faults — multiple SPF records, deprecated ptr mechanisms, and permissive +all policies. Free, no sign-up.