How do you fix “SPF PermError: too many DNS lookups”?
Updated July 3, 2026
This error means evaluating your SPF record requires more than 10 DNS lookups (the hard limit in the SPF standard), so receiving servers give up and treat your SPF as permanently broken.
Why this happens
Every include:, redirect=, a, mx, ptr, and exists mechanism in your SPF record costs one DNS lookup, and includes count recursively. include:_spf.google.com alone is 4 lookups once its nested includes resolve.
The limit exists to stop attackers from using SPF to amplify DNS traffic. Receivers enforce it strictly: lookup number 11 doesn't get evaluated. The whole record returns permerror, and mail that should pass SPF doesn't.
It usually creeps up on you. Each new tool (CRM, helpdesk, newsletter, billing) says “just add include:ourservice.com to your SPF”, and one day the eleventh lookup breaks everything silently.
How to fix it
- 1
Count your actual lookups
Run your domain through our free SPF checker. It resolves every include recursively and shows a tree with the exact count. You need the true number, not a guess from eyeballing the record.
- 2
Delete includes for services you no longer use
Most over-limit records contain fossils: the marketing platform you left two years ago, the helpdesk you migrated off. Each removed include eliminates its entire subtree of lookups. Check your SPF tree against services you actually still send from.
- 3
Flatten stable includes into IP addresses
For services whose sending IPs rarely change, replace include:service.com with the ip4:/ip6: ranges it resolves to; IP mechanisms cost zero lookups. Caution: if the provider changes IPs, your record silently breaks, so only flatten providers that publish stable ranges, and re-check quarterly.
- 4
Move bulk senders to a subdomain
Newsletters and transactional mail can send from mail.yourdomain.com with its own SPF record and its own 10-lookup budget. This also isolates marketing-mail reputation from your day-to-day email.
- 5
Verify the fix
Re-run the SPF checker until the counter is at 10 or fewer, ideally 8 or fewer, so the next tool you adopt doesn't put you straight back over.
Verify the fix
Run the check that corresponds to this error. You'll see the same red/amber/green verdicts mailbox providers effectively apply.
Open the SPF checker with lookup counter →Preventing it next time
SPF breaks quietly: the record looks fine, mail keeps sending, and deliverability just degrades. DMARCPath re-checks your SPF lookup count continuously and alerts you before a new include pushes you over the limit, so you find out from us rather than from a customer asking why your invoice went to spam.
Frequently asked questions
- Why does my SPF record fail when it's under 255 characters?
- Length and lookups are different limits. The 255-character limit is about the TXT record string; the 10-lookup limit is about DNS queries during evaluation. A short record with five nested includes can still permerror.
- Do ip4 and ip6 mechanisms count toward the limit?
- No. ip4:, ip6:, and all cost zero DNS lookups. That's why flattening includes into IP ranges fixes the error.
- Is permerror the same as SPF fail?
- No. Fail means the record was evaluated and the sender wasn't authorized. Permerror means the record couldn't be evaluated at all, and under DMARC, permerror means SPF can't contribute to alignment, so DKIM has to carry your authentication alone.
Catch this before your customers do
DMARCPath watches your domain's authentication continuously and alerts you the day something breaks, not the week a customer mentions your emails stopped arriving. One domain free.
Start monitoring free →