In this guide · 7 sections
Short answer
SPF allows at most 10 DNS lookups per check. Every include, a, mx, ptr, exists and redirect counts, including nested ones; ip4 and ip6 do not. Fix it by removing services you no longer use, moving bulk senders to a subdomain, and replacing includes with IP ranges only where the vendor documents fixed IPs.
What 'SPF PermError: too many DNS lookups' means
SPF (Sender Policy Framework) is a TXT record listing the servers allowed to send email for your domain. The SPF standard, RFC 7208 section 4.6.4, says receivers must stop after 10 terms that need DNS lookups and return 'permerror'. It also recommends a limit of two 'void lookups', meaning lookups that return nothing, such as an include pointing to a domain that no longer exists.
Microsoft's SPF documentation puts the consequence plainly: more than 10 lookups and the message fails SPF with a permanent error, and some receivers reject it with errors such as 'The message required too many lookups'. Because receivers read the record left to right and stop at the first match, mail from services listed early may still pass at some receivers while others fail. That is why the problem often looks intermittent.
How the SPF 10-lookup limit is counted
Count every term that makes the receiver look something up in DNS, then follow each include and count what is inside it too.
| SPF term | Counts as a lookup? | Notes |
|---|---|---|
| include: | Yes, 1 each | Plus every lookup inside the included record |
| a | Yes | Often left over from old hosting set-ups |
| mx | Yes | Each MX host may also resolve to addresses (max 10 per mx term) |
| ptr | Yes | Deprecated; remove it |
| exists: | Yes | Used by some large senders |
| redirect= | Yes | Replaces the record with another domain's |
| ip4: / ip6: | No | Free, but you must keep the ranges current |
| all | No | Ends the record: ~all or -all |
Nesting is where most records go over. When we queried DNS in October 2026, Google's _spf.google.com and Microsoft's spf.protection.outlook.com contained only IP ranges, so each cost one lookup. Some other providers' includes contain several more includes, so a single line in your record can cost four or five lookups.
How to fix too many SPF lookups, step by step
Work through these in order. The first two fix most records without any risk.
Get the current record and a lookup count
Use any free SPF checker that shows the lookup tree, or query the TXT record yourself. Note each include and how many lookups it costs, including nested ones.
List every service that really sends as your domain
Check your DMARC reports if you have them, and ask: website forms, newsletter, helpdesk, invoicing, booking, CRM. Anything not on the list is a candidate for removal.
Remove dead and duplicate entries
Delete includes for services you have cancelled, old hosting providers, and a or mx terms that point to servers that do not send mail. Remove ptr completely.
Merge into one record
If you find two SPF TXT records on the same name, combine them. Microsoft notes that multiple SPF records cause a PermError on their own.
Move bulk senders to a subdomain
Send newsletters from news.yourdomain.com with its own SPF record. Microsoft recommends this for services you do not control, to protect your main domain's reputation and keep its lookup count down.
Replace includes with IPs only where documented
If a vendor publishes a fixed, documented list of sending IPs, you can use ip4 and ip6 instead of its include. Set a reminder to check the list.
Test, then watch DMARC reports
Recheck the lookup count, send test emails to Gmail and Outlook, read the Authentication-Results header, and watch the next week of DMARC reports for new failures.
SPF flattening: when it helps and what can go wrong
SPF flattening means replacing includes with the IP addresses they currently resolve to, so the record needs no lookups. It does get you under 10, but it swaps one problem for another.
Pros
- Brings almost any record under the 10-lookup limit
- Fewer DNS queries for receivers
- Useful as a short-term patch while you clean up
Cons
- Vendors change their IP ranges without telling you
- When they do, their mail starts failing SPF silently
- Long IP lists can exceed DNS size limits and need splitting
- Automatic flattening services add another dependency and cost
If you flatten, do it only for vendors that publish stable IP lists, and keep monitoring DMARC reports so you notice when a range changes. For large providers such as Google and Microsoft, keep the include; it already costs only one lookup.
Check your other email records while you are there
An SPF clean-up is a good moment to check the rest of your email authentication, since the same missing service often has no DKIM either.
Email authentication check
Our main guide to emails going to spam: SPF, DKIM and DMARC explains each record. If your mail is bouncing rather than landing in spam, our bounce-back errors guide helps decode the message.
Do it yourself or get help?
If you have DNS access and can identify every sending service, this is a 30-minute job: count, delete what is dead, merge duplicates, test. The risk is deleting an include that something still uses, such as invoice emails from your accounting system, which then quietly start going to spam.
If you would rather have it done and checked, our Emails Land in Spam fix (S$249) inventories every service sending as your domain, rebuilds SPF, DKIM and DMARC, and monitors DMARC for 14 days before moving to enforcement. For just the DNS change on a domain you already understand, Domain & DNS Setup (S$99) covers it.
Frequently asked questions
The SPF standard, RFC 7208, limits an SPF check to 10 terms that cause DNS lookups: include, a, mx, ptr, exists and the redirect modifier, counted across nested includes. If a check needs more, the receiving server must return a permanent error, and SPF fails for the message.
No. ip4 and ip6 entries, and the all mechanism, do not need DNS lookups, so they do not count. That is why replacing includes with IP ranges reduces the count. The trade-off is that you must update the ranges yourself if the provider changes them.
It depends on the receiver and your DMARC policy. Some receivers reject the message, others treat it as an SPF failure and rely on DKIM. If DKIM passes and aligns with your domain, DMARC can still pass. Mail from services without DKIM is most at risk of spam or rejection.
It works but needs maintenance. Flattening replaces includes with the IP addresses they point to today. If the vendor changes its sending IPs, mail from that vendor starts failing SPF without warning. Use it only for vendors with documented, stable IP ranges, and keep watching DMARC reports.
No. Only one SPF record is allowed per domain or subdomain, and two records cause a PermError. Instead, move some senders to a subdomain such as news.yourdomain.com, which can have its own SPF record with its own 10-lookup budget.