SPF PermError: Too Many DNS Lookups — How to Count and Fix It

Receivers stop evaluating an SPF record after 10 DNS lookups. One more and the result is PermError, which most receivers treat the same as an SPF fail. The record still looks fine in your DNS panel, so this error often goes unnoticed until mail starts landing in spam. The fix is counting, not guessing: once you know where the lookups go, getting back under 10 usually takes one or two edits.

Quick answer

Count every include:, a, MX (Mail Exchanger — where incoming email is delivered), exists, redirect and ptr in your record, including the ones nested inside each include. If the total is above 10, remove senders you no longer use first, then drop includes for tools that do not need them, and only flatten to IP addresses as a last resort. Never split the record in two: two SPF records is a PermError of its own.

What counts toward the 10, and what is free

• include: costs 1, plus every lookup inside the record it points to. Nested includes are where most records blow the limit.
• a and MX (Mail Exchanger — where incoming email is delivered) cost 1 each. The a: and mx: forms that name another domain cost the same.
• exists: and redirect= cost 1 each.
• ptr costs 1 and is deprecated. Delete it; nothing legitimate needs it.
• ip4:, ip6: and all cost nothing. They are plain values, not lookups.
• Separately, more than 2 lookups that return no record at all (so-called void lookups) also cause a PermError. The usual culprit is an include for a service that has since shut down or renamed its SPF host.

How to count your record by hand

1. Look up your current record: run nslookup -type=txt yourdomain.com (Windows) or dig TXT yourdomain.com +short (macOS, Linux) and find the line that starts with v=spf1.
2. Score each term using the list above. Write the number next to it.
3. For each include:, look up that host's TXT records (short text lines in DNS used for email security) the same way and score what is inside it. Repeat for any includes inside that one.
4. Add everything up. Online SPF checkers do the same walk and show the total, which is a good way to confirm your count.

For scale: OquMail's part of the record, v=spf1 MX (Mail Exchanger — where incoming email is delivered) a:mail.oqumail.com ~all, costs 2 lookups (mx and a), leaving 8 for everything else. Google Workspace's include on its own typically costs 4, because it pulls in three more includes behind it. Two or three marketing and helpdesk tools on top of that and you are at the limit.

How to get back under 10, in this order

1. Remove senders you no longer use. After switching email providers, the old provider's include is very often still there. The same goes for a newsletter tool you cancelled or a website plugin you replaced.
2. Check whether each tool needs an include at all. SPF is checked against the envelope sender (the Return-Path), not the From address you see. Many newsletter and transactional services send with their own bounce domain, so SPF is evaluated against their domain and your include does nothing except use up lookups. Their documentation says which applies. For those tools, enabling DKIM signing with your own domain is what makes DMARC pass.
3. Drop duplicate terms. If your MX already points to mail.oqumail.com, then mx and a:mail.oqumail.com authorise the same server, so you can remove mx and save a lookup. Keep a:mail.oqumail.com: it is the part OquMail checks for when it verifies your domain.
4. Move a heavy sender to a subdomain. If a marketing tool supports a custom bounce domain such as news.yourdomain.com, its SPF lives on that subdomain and stops counting against your root record.
5. Flatten only as a last resort. Replacing an include with the ip4: ranges it currently returns gets the count down, but the record silently goes stale when the provider changes its IP addresses. If you do it, do it only for providers whose ranges rarely change, and set a reminder to re-check.

What not to do

• Do not publish a second SPF record to hold the overflow. Receivers that find two v=spf1 records return PermError regardless of what is in them.
• Do not switch ~all to +all to make the error go away. +all authorises every server on the internet to send as you.
• Do not use a long chain of redirect= to dodge the limit. redirect= lookups count like any other.

Confirm it is fixed

Run your domain through an SPF checker and confirm the lookup count is 10 or fewer with no void lookups. Then send a message to a Gmail address, open it, choose Show original, and look for spf=pass. Our guide to reading the authentication results in email headers explains the rest of that output. DNS changes usually apply within minutes; allow up to an hour for the TTL on the old record to expire.

Common questions

Does PermError mean my mail bounces?

Usually not on its own. Most receivers treat it as an SPF fail, and the outcome then depends on DMARC. If the message also carries a DKIM signature that passes and aligns with your From domain, DMARC still passes. That is why DKIM on every sending tool matters: it carries you while SPF is broken.

I did not change anything. Why did it break?

Because the lookups inside each include belong to the vendor. When a provider adds a nested include to its own SPF record, your total goes up without you touching your DNS. This is the main reason to leave a few lookups spare instead of sitting at exactly 10.

Does ~all or -all affect the limit?

No. The all mechanism costs nothing either way. It only decides how receivers should treat servers that are not on your list.