SPF Too Many DNS Lookups: Fix the PermError

What the error means

SPF too many DNS lookups means a receiver tried to evaluate your SPF record and hit the protocol limit before it could get a clean pass or fail.

Under RFC 7208, SPF evaluation is limited to 10 DNS-querying terms. The usual terms that spend this budget are include, a, mx, ptr, exists, and redirect. Plain ip4, ip6, and all do not spend lookups. When the evaluator needs more than 10, the SPF result is a permanent error, usually shown as permerror.

That matters because Gmail, Outlook, and other mailbox providers use authentication as a major trust signal. They do not route mail to spam because of SPF alone, and they do not publish exact filtering formulas. But a domain with SPF PermError is harder to trust, and unauthenticated or misconfigured mail is more likely to be rejected, rate limited, or placed in spam. Google sender guidelines require SPF or DKIM for all senders and SPF, DKIM, and DMARC for bulk senders. Microsoft sender guidance also points senders toward SPF, DKIM, and DMARC to improve deliverability.

Fix the SPF record without breaking mail

The safe fix is not to paste in another include. It is to inventory every sender, remove dead sources, and publish one smaller SPF record.

• Find the single SPF TXT record at the domain used in your envelope sender or return-path. A domain must not publish multiple SPF records.
• Count DNS-querying mechanisms only: include, a, mx, ptr, exists, and redirect. Then check the includes they point to, because nested includes count too.
• Remove services that no longer send mail for the domain. Old CRMs, help desks, marketing tools, and trial accounts are common causes.
• Replace a or mx mechanisms with explicit ip4 or ip6 ranges only when the sending IPs are stable and owned or assigned to you.
• Avoid ptr. It is slow, fragile, and explicitly discouraged in SPF practice.
• Move high-volume third-party mail to a subdomain such as mail.example.com or news.example.com. Each sending subdomain can have its own SPF record, DKIM selector, DMARC policy, and reputation.
• Use SPF flattening only when you can monitor it. Flattening replaces includes with IP ranges, but vendor IPs change, so stale flattened records can silently block real mail.
• End with ~all while you are validating. Move to -all only after SPF and DKIM pass consistently and DMARC reports show every legitimate sender is covered.

For example, this is often too broad: v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net ~all. The right fix is not universal. If Google Workspace is your employee mail, SendGrid is transactional, and Mailchimp sends newsletters, keep those. If Microsoft 365 or Zendesk no longer sends for the domain, remove them. If both Google and Microsoft are in active use, leave both and move marketing to a subdomain if the total lookup count is still too high.

You can check the live record with the free InboxRadar domain scorecard. It reads SPF, DKIM, DMARC, and MX from DNS and points at the highest-impact failure first.

Check DKIM, DMARC, MX, and blocklists next

Fixing the SPF lookup limit removes the PermError, but deliverability also depends on whether your whole domain identity is coherent.

DKIM, defined in RFC 6376, signs messages with a private key and lets receivers fetch the public key from DNS. Each signing service usually has its own selector, such as google._domainkey or a vendor-specific selector. Turn DKIM on in Google Workspace, Microsoft 365, and every ESP that sends as your domain. SPF can fail after forwarding, but aligned DKIM can still let DMARC pass.

DMARC, defined in RFC 7489, checks whether passing SPF or DKIM aligns with the visible From domain. Start with p=none and a rua reporting address so you can see who is sending. Then move to p=quarantine or p=reject only after legitimate mail passes. DMARC enforcement with broken SPF or missing DKIM can block your own mail.

MX records do not authorize senders, but they matter for receiving mail and for domain trust checks. Make sure your MX records point to the provider that handles inbound mail and that abandoned providers are removed. Also check major blocklists if spam placement continues after authentication passes. A listing is usually a symptom of compromised accounts, bad lists, high complaint rates, or poor sending hygiene, not a substitute for fixing SPF, DKIM, and DMARC.

A practical recovery plan

Treat the PermError as a configuration incident. The fastest path is a short inventory, one DNS edit, then monitoring.

• Export or list every system that sends mail as the domain: employee mail, transactional app, CRM, help desk, invoicing, calendar, newsletter, and cold email tools.
• Decide which systems must send from the root domain and which should move to a subdomain.
• Publish one SPF record under 10 lookups. Keep only current providers and stable IP mechanisms.
• Verify DKIM signatures for each active provider. If a provider gives two selectors, publish both.
• Publish or review DMARC at _dmarc.example.com. Use p=none plus rua=mailto:... while auditing, then enforce when reports are clean.
• Send test mail to Gmail and Outlook accounts and inspect the message headers for SPF, DKIM, and DMARC results.
• Monitor the domain after the fix. DNS drift is common when a new sender is added during a launch or sales campaign.

If you want the broader checklist, see the related InboxRadar guides at all guides.