Jorge LewisSPF too many DNS lookups is the error a receiving server returns when evaluating your SPF record would take more than 10 DNS queries. The result is a PermError: the receiver abandons the record, SPF can no longer pass, and under DMARC that leg of authentication counts as a fail. Cold email senders hit this cap faster than anyone, because every sending platform, warmup service, and CRM wants its own include in the same record. This guide covers exactly how the limit works, how to count what your record actually costs, the audit, remove, swap, flatten fix order, and why the real fix for outbound is a minimal record on a dedicated sending domain.
We untangle this constantly. Our parent agency, Referral Program Pros, has run more than 4,000 outbound campaigns and booked over 7,000 meetings, and overloaded SPF records on shared company domains are one of the recurring silent killers behind campaigns that look fine and land nowhere. It is part of why GTM Bud can carry a reply-rate guarantee of 5 percent positive replies on LinkedIn or 1.5 percent on email, with a full refund if we miss it: we verify that authentication actually evaluates before a single message goes out.
What does SPF too many DNS lookups mean?
SPF too many DNS lookups is the error a receiving mail server reports when evaluating your SPF record would require more than 10 DNS queries. The cap comes from RFC 7208, section 4.6.4, which requires SPF implementations to limit lookup-triggering terms to 10 per check and to return a PermError the moment the limit is exceeded. A PermError is not a soft warning. The receiver abandons the record, your domain is treated as if its SPF policy could not be read at all, and the SPF half of DMARC counts as a fail. Unless the message also carries a DKIM signature that passes with alignment, the whole message fails DMARC. The budget is cumulative and recursive: every include spends one lookup itself and then inherits every lookup inside the record it points to, which is why a tidy-looking record with four includes can quietly cost 11.
The same section of RFC 7208 adds a second, lesser-known cap: implementations should allow no more than two void lookups, meaning queries that return no record at all. Two dead includes pointing at abandoned vendor domains can produce a PermError even when your total count is under 10.
Which SPF mechanisms cost a DNS lookup?
Six terms count toward the limit and four cost nothing, and RFC 7208 section 4.6.4 draws the line precisely. Everything that has to be resolved spends from the budget. Everything that carries literal data does not.
| Term | Costs a lookup? | Notes |
|---|---|---|
include | Yes | Plus every counted term inside the record it references |
a | Yes | One per use, even when it points at your own domain |
mx | Yes | One per use; resolving the listed MX hosts has its own cap of 10 |
ptr | Yes | Counts, and RFC 7208 discourages using it at all |
exists | Yes | One per use |
redirect | Yes | A modifier rather than a mechanism, but it counts the same |
ip4 | No | Literal address range, nothing to resolve |
ip6 | No | Literal address range, nothing to resolve |
all | No | No DNS query at evaluation time |
exp | No | Its lookup happens after evaluation, so the RFC exempts it |
The practical read of this table: a record built from ip4 and ip6 ranges plus ~all costs zero lookups no matter how long it gets, while every include is spending from a shared budget you cannot see by reading the record.
The rule that catches everyone: the limit is counted recursively across the whole evaluation, not per record. An
includewhose target contains three more includes costs four lookups, and nothing in your own DNS panel shows it.
Why do cold email senders hit the cap faster than anyone?
Cold email senders hit the SPF lookup limit faster than any other group because outbound stacks tools onto a domain that is already full. A typical company domain carries its workspace provider, a marketing platform, a CRM, a help desk, and a billing system before anyone thinks about cold email, and each vendor’s setup guide says the same thing: add our include. None of them mentions that all of those includes draw from one shared budget of 10 lookups, counted recursively, per RFC 7208. Then outbound arrives with a sending platform and sometimes a warmup service, each wanting an include of its own. The result is predictable: the record works for years, the eleventh lookup lands with the newest tool, and every receiver on the internet starts returning PermError on the same day the new platform goes live.
Here is the part that makes it dangerous: nothing visibly breaks. The record still looks valid in your DNS panel, your mail still sends, and the failure only shows up as dropping deliverability. Our guide to SPF, DKIM, DMARC setup for cold email covers the full publish order and the one-record rule; this piece is only about the budget inside that one record.
How to count what your SPF record actually costs
Count it recursively, by hand once, so you understand what the checkers are reporting. Pull your record with dig txt example.com +short, then query every include target you find and repeat until you hit records with no further includes, tallying every counted term from the table above. Free checkers from EasyDMARC, PowerDMARC, and MXToolbox automate the recursion and report the total.
Here is a worked audit of a record we see on company domains constantly:
v=spf1 include:_spf.google.com include:spf.example-crm.com include:mail.example-helpdesk.com a mx ip4:203.0.113.25 ~all| Term | Own lookup | Nested lookups | Running total |
|---|---|---|---|
include:_spf.google.com | 1 | 3 | 4 |
include:spf.example-crm.com | 1 | 1 | 6 |
include:mail.example-helpdesk.com | 1 | 0 | 7 |
a | 1 | 0 | 8 |
mx | 1 | 0 | 9 |
ip4:203.0.113.25 | 0 | 0 | 9 |
~all | 0 | 0 | 9 |
Google Workspace alone costs 4, because _spf.google.com resolves through three nested netblock includes, which you can confirm yourself with dig txt _spf.google.com +short. This example record sits at 9 of 10 with outbound nowhere in sight. Add one sending platform whose include nests a single further record and the evaluation needs 11 lookups. PermError, everywhere, at once.
Fix it in this order: audit, remove, swap, flatten
The fix order matters because the cheap steps usually solve it and the expensive step creates a maintenance obligation.
1. Remove dead includes first
Every tool the company stopped paying for probably left an include behind. Delete every include for a service that no longer sends mail as your domain, and delete anything pointing at a domain that no longer publishes SPF, since those are also burning your void-lookup allowance of two. In our experience across client domains at Referral Program Pros, dead includes are the single most common finding in an SPF audit, and removing them often ends the problem on its own.
2. Swap stable vendors for direct IP ranges
Where a vendor publishes a small, documented, stable set of sending addresses, replace its include with ip4 or ip6 entries, which cost nothing. This only makes sense for vendors whose ranges genuinely do not move. Leave the Google and Microsoft includes alone: both rotate sending addresses, and a hand-copied snapshot of their ranges starts failing silently the first time they change.
3. Flatten last, and know the trade-off
SPF flattening is the practice of replacing every lookup-costing mechanism with the IP addresses it currently resolves to, collapsing the whole evaluation to zero lookups. It works, and it is the standard last resort. The trade-off is staleness: EasyDMARC’s fix guide recommends flattening only as a final option because the flattened copy falls out of sync when vendors change IPs, at which point their mail fails SPF with no error on your side. Dmarcly’s flattening explainer describes the dynamic alternative, where a service re-resolves the ranges automatically and serves the result through a single managed include. That fixes staleness by adding a vendor dependency.
One thing you must never do: end the record with +all to make the error disappear. That authorizes the entire internet to send as your domain, which is strictly worse than having no SPF record.
The real fix for outbound: a minimal record on a dedicated sending domain
The durable fix for cold email is not a cleverly flattened record on your company domain. It is a dedicated sending domain whose SPF record authorizes exactly one mail source. A record like v=spf1 include:_spf.google.com ~all costs 4 of the 10 allowed lookups, never grows, and never needs flattening, because the sending domain exists for outbound and nothing else: no CRM, no help desk, no billing tool will ever ask for an include on it. This is the separation logic from our guide to secondary domains for cold email applied to authentication: the record stays minimal because the domain’s job stays singular. Across more than 4,000 campaigns at Referral Program Pros, dedicated sending domains with minimal records are the one configuration we have never had to debug for lookup overruns, while every PermError we have untangled lived on a shared company domain.
How many of those domains you need, and how many inboxes go on each, is its own sizing question covered in our guide to how many domains and inboxes for cold email. GTM Bud provisions dedicated sending domains with exactly this kind of minimal record as part of onboarding its cold email automation tool, so the lookup budget is a solved problem before the first campaign launches.
How do you verify the PermError is actually gone?
Recount first, then test in production. Run your corrected record through a recursive checker and confirm the total is under 10 with zero void lookups. Then send a test message from the sending mailbox to a Gmail address you control, open Show original, and confirm the SPF line reads PASS with your domain, the check described step by step in our authentication setup guide.
Finally, watch your DMARC aggregate reports for a week. A PermError that only occurs at certain receivers, or only on mail routed through a particular vendor, shows up there and nowhere else. If reading those XML reports is new territory, our walkthrough on how to read DMARC reports covers finding SPF results per source IP. The record is fixed when every legitimate source shows SPF pass and the PermError rows disappear.
Frequently asked questions about the SPF lookup limit
Does DKIM or DMARC have a DNS lookup limit like SPF?
No. The ten-lookup cap in RFC 7208 applies only to SPF evaluation. A DKIM check resolves one TXT record per selector, and a DMARC check resolves one TXT record at the _dmarc subdomain, plus one more at the organizational domain for subdomain mail. Neither protocol chains includes the way SPF does, so neither accumulates lookups. That is one reason a passing, aligned DKIM signature is the best insurance against an SPF PermError.
Do ip4 and ip6 entries count toward the SPF lookup limit?
No. RFC 7208 section 4.6.4 exempts ip4, ip6, and all because they carry literal data and trigger no DNS query at evaluation time. You can list dozens of ranges without spending a single lookup. The ceiling for a heavily flattened record becomes size instead, since each string in a DNS TXT record is limited to 255 characters.
How do I check how many DNS lookups my SPF record uses?
Query your record with dig txt example.com +short, then query every include target it references and repeat until you reach records with no further includes, counting every include, a, mx, ptr, exists, and redirect along the way. Free SPF checkers from EasyDMARC, PowerDMARC, and MXToolbox do the recursion for you. Recount after every vendor change, because providers can add nested includes inside their own records without telling you.
Is SPF flattening safe long-term?
Only with maintenance. Flattening copies a vendor’s current IP ranges into your record, and EasyDMARC recommends it as a last resort because the copy falls out of sync the moment the vendor changes addresses, at which point their mail fails SPF silently. Dynamic flattening services re-resolve ranges automatically, trading stale IPs for a vendor dependency. For outbound, the better answer is a minimal record on a dedicated domain that never needs flattening, which is the setup GTM Bud provisions with its cold email automation tool.
What is a void lookup and why did I get a PermError under 10 lookups?
A void lookup is a DNS query during SPF evaluation that returns no usable answer, either NXDOMAIN or an empty result. RFC 7208 section 4.6.4 says implementations should cap void lookups at two, with PermError beyond that. Two dead includes pointing at domains that no longer publish SPF can therefore break your record even when the total count sits safely under 10. Dead includes are the first thing to delete in any audit.
Can I fix the lookup error by adding a second SPF record?
No. RFC 7208 allows exactly one SPF record per domain, and publishing a second one makes receivers return PermError for a different reason: multiple records are themselves an evaluation error. Every source must be merged into the single record, which is exactly why shared company domains run out of lookups and why the clean escape is a dedicated sending domain.
Keep the record under 10 and go book meetings
The SPF too many DNS lookups error is a budget problem, and budgets are fixed by spending less, not by clever accounting. Count your record recursively, delete the dead includes, swap stable vendors to ip4 ranges, flatten only what is left, and verify with a recount, a Gmail test, and a week of DMARC reports. Better still, take cold email off the crowded company domain entirely and run it on dedicated sending domains whose records never grow past one include.
Or skip the DNS archaeology altogether. GTM Bud sets up authenticated sending infrastructure with minimal, lookup-safe records as part of onboarding, backed by the same guarantee our agency work earned: 5 percent positive replies on LinkedIn, 1.5 percent on email, or a full refund. If you want the whole motion handled, from domains and records to copy and sending, start with our done-for-you outbound service and let the record stay someone else’s problem.