SPF too many DNS lookups (PermError): how to fix it

By Akash Sengar · 6 October 2026 · 7 min read

What the error means

An SPF record tells receiving mail servers which hosts may send email for your domain. To evaluate it, the receiver may have to make further DNS queries, for example to read the SPF record of a service you include. RFC 7208, section 4.6.4, caps this: an SPF check must not need more than 10 DNS-querying terms. If it does, the result is permerror.

Many receivers treat permerror as a fail, and DMARC treats it as SPF not passing. If DKIM is aligned, mail may still be delivered, but you have lost the safety net. If DKIM is missing, delivery suffers.

What counts towards the limit

These mechanisms and modifiers each count as one lookup, wherever they appear, including inside included records:

• include: one, plus everything inside the included record.
• a and mx: one each. For mx, the RFC also limits the MX hosts looked up to 10.
• ptr: one, and RFC 7208 says it should not be used at all because it is slow and unreliable.
• exists: one.
• redirect= one.

These do not count: ip4:, ip6:, all, and the initial query for your own SPF record.

The void lookup limit

The same section adds a second limit: no more than two void lookups, meaning DNS queries that return no records or "domain does not exist". A void lookup usually comes from an include of a service you stopped using, whose SPF record has since been deleted, or a typo in a domain name. Exceeding two also produces permerror. Old includes are worth removing even if you are under 10.

How to count your lookups

Our email security check follows every include and redirect and shows the total. To count by hand, write out the tree:

1. Look up your domain's TXT record and find the one beginning v=spf1. There must be exactly one.
2. Count each include, a, mx, ptr, exists and redirect.
3. For each include, look up that domain's SPF record and repeat. Large providers often nest two or three levels deep.
4. Add the totals. If the same include appears in two branches, it counts each time it is evaluated.

How to fix it

1. Remove senders you no longer use

Most SPF records grow and never shrink. Ask each team which tools still send email as the domain and remove the rest. Remove a and mx unless your web server or inbound mail servers genuinely send outbound mail; with Microsoft 365, Google Workspace or Zoho Mail they usually do not.

2. Use DKIM-only for services that support it

DMARC needs SPF or DKIM to pass and align, not both. Many marketing and helpdesk platforms send with their own bounce (envelope) domain, so your SPF include does not help DMARC alignment anyway. If the service signs with DKIM for your domain, you can often remove its SPF include safely. Check the service's own documentation first.

3. Move senders to subdomains

Each subdomain has its own SPF record and its own 10-lookup budget. Send newsletters from news.example.com and support mail from help.example.com, each with only the include it needs. This also separates reputation, so a campaign problem does not affect invoices from the main domain.

4. Replace includes with IP ranges only when they are yours

If a server you control sends mail from fixed addresses, list them with ip4: or ip6:, which cost no lookups.

A worked clean-up

Take a typical growing company. Its record includes Microsoft 365, Google Workspace (left over from before a migration), a newsletter tool, a helpdesk, a CRM, a payroll provider, plus a and mx. Expanded, it needs well over 10 lookups and returns permerror.

1. Remove what no longer sends. The Google include stays from a migration two years ago; nobody sends from Google any more. Removed.
2. Remove a and mx. The website does not send mail, and inbound mail is handled by Microsoft 365, which is already included. Both removed.
3. Move the newsletter tool to a subdomain. It now sends from news.example.com with DKIM for that subdomain and its own one-include SPF record.
4. Use DKIM for the helpdesk. The helpdesk signs with DKIM for the main domain and uses its own bounce domain, so its SPF include did nothing for DMARC. After checking its documentation, the include is removed.
5. Recount. Microsoft 365, CRM and payroll remain, comfortably under 10, and every remaining sender passes DMARC through aligned DKIM, SPF or both.

Before changing a live record, lower its DNS TTL, make one change at a time and watch DMARC aggregate reports for a few days to confirm nothing legitimate started failing.

Why naive SPF flattening breaks

"Flattening" means replacing includes with the IP addresses they currently resolve to, so the record needs fewer lookups. Done once by hand, it works until the provider changes its IP ranges, which large providers do without notice. Then your record silently stops authorising some of their servers and mail fails SPF.

Flattening also tends to produce very long records. A single DNS TXT string is limited to 255 characters, so long records have to be split across multiple strings correctly, and very large DNS responses can be truncated.

If you must flatten, use a service that re-resolves the includes on a schedule and updates your record automatically, and keep the number of flattened providers small. In most cases, removing old senders, using DKIM and moving senders to subdomains solves the problem without flattening.

Domains that never send email

Parked domains, old brand domains and domains used only for websites should state that nothing sends for them:

This costs no lookups and stops attackers using those domains for spoofing. Our DMARC guide covers the rest of the rollout.

Checklist

• Exactly one v=spf1 record per domain.
• Total lookups 10 or fewer, void lookups two or fewer, checked after every change.
• No ptr; no a or mx unless needed.
• Every sending service has DKIM for your domain.
• Bulk and support tools on their own subdomains.
• Ends in ~all or -all; never +all.