SPF PermError: Fixing the "Too Many DNS Lookups" Error

Your SPF record lists every service that sends mail for your domain, you checked it twice, and receiving servers still report spf=permerror. The record isn't wrong — it's too long, in a way that has nothing to do with character count.

What the limit actually is

The SPF standard (RFC 7208) says an evaluating mail server must stop after 10 DNS-querying mechanisms while checking one record. If your record needs more than that, the check ends in a permanent error instead of a pass or fail.

These mechanisms each cost at least one lookup:

• include:
• a
• mx
• ptr
• exists:
• redirect=

These cost nothing:

• ip4:
• ip6:
• all

The trap is nesting. An include: pulls in another SPF record, and that record's lookups count against your 10 as well. Three or four includes from large providers can quietly blow past the limit without you adding a single mechanism.

Two other rules cause the same error: a domain must publish only one SPF TXT record (two records is a permerror by itself), and a single text string inside a TXT record cannot exceed 255 characters.

Step 1: Confirm it really is a PermError

Don't fix what isn't broken. Look at the authentication result on a message that was actually delivered.

1. Send a message from your domain to a Gmail address you control.
2. Open it, click the three-dot menu, and choose Show original.
3. Look at the Authentication-Results header.

You're looking for something like:

Authentication-Results: mx.google.com;
       spf=permerror (google.com: ... exceeded the maximum number of DNS lookups)
       dkim=pass [email protected]
       dmarc=fail (p=NONE) header.from=example.com

If it says spf=pass or spf=fail, your record evaluated fine and your problem is somewhere else. permerror is the one this article fixes. In Roundcube on cPanel, you can see the same headers by opening the message and choosing the option to view the message source.

Step 2: Count your lookups by hand

Start by reading your own record:

dig +short TXT example.com

Say it returns this:

"v=spf1 a mx include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.protection.outlook.com ~all"

Count the top level first: a (1), mx (1, plus one more for each hostname your MX records point to), and four include: mechanisms (4). That's at least six before any nesting.

Now expand each include and count what's inside it:

dig +short TXT _spf.google.com
dig +short TXT sendgrid.net
dig +short TXT servers.mcsv.net
dig +short TXT spf.protection.outlook.com

Each result that contains its own include:, a, or mx adds more lookups. Keep expanding until you only see ip4:, ip6: and all. Add everything up.

Providers change these records without telling you, so a record that passed last year can fail today. That's why it's worth counting from live DNS rather than trusting a number you read somewhere. If you'd rather not do it by hand, any public SPF validator will show the same expansion tree — but run dig yourself afterwards to confirm what's actually published.

Step 3: Cut the record down

Work through these in order. The early options are safe; the later ones trade convenience for maintenance.

Remove senders you no longer use

The old newsletter tool, the CRM trial from 2023, the previous host's include. Each one is a free lookup back. If you're unsure whether a service still sends mail for you, check the service's own sending logs before deleting its include.

Delete ptr if it's there

The ptr mechanism is deprecated and slow, and receivers may ignore it. Remove it.

Replace a and mx with the actual IP

If your website and mail live on one server with a stable IPv4 address, a and mx can often be collapsed into one ip4: entry, which costs zero lookups. Find the address:

dig +short A mail.example.com

The trade-off is real: if your hosting IP ever changes — a server move, a migration, an IP reassignment — the hardcoded ip4: becomes wrong and your mail starts failing SPF. Only do this if you'll remember to update it, and put it on your checklist for any future migration.

Move bulk senders to a subdomain

This is the fix that scales. SPF is checked against the domain in the envelope sender (the Return-Path), not the From address you see in the mail client. Most newsletter and transactional-mail services let you set that envelope domain to a subdomain you control.

So instead of stuffing your newsletter provider's include into the main record, give the subdomain its own record:

news.example.com.    3600    IN    TXT    "v=spf1 include:servers.mcsv.net -all"

The subdomain gets its own fresh budget of 10 lookups, and your main domain's record stays short. Your provider's docs will tell you which CNAME or MX records it also needs for that subdomain — follow them exactly, because the envelope domain only changes if the provider is configured to use it.

Flattening: know what you're signing up for

"Flattening" means replacing includes with the IP addresses they currently resolve to. It works, and it drops you to zero lookups. It also means that every time a provider adds a sending IP, your record is silently out of date and some of your mail starts failing SPF. Only flatten if something automated keeps the record current, or if you genuinely re-check it on a schedule.

Step 4: Edit the record

If your domain uses your host's nameservers, edit it in cPanel:

1. Log in to cPanel and open Zone Editor under Domains.
2. Find your domain and click Manage.
3. Filter by TXT and locate the record starting with v=spf1.
4. Click Edit, replace the value, and click Save Record.

A tidied record might look like this:

v=spf1 ip4:203.0.113.25 include:_spf.google.com ~all

While you're there, confirm there is exactly one v=spf1 TXT record on the domain. Two of them is an automatic permerror no matter how short each one is.

If your nameservers point somewhere else — Cloudflare, your registrar, a DNS provider — the cPanel Zone Editor is not the live record. Edit it where the nameservers point. To check which is authoritative:

dig NS example.com

In recent cPanel versions there's also Email Deliverability under Email, which shows the SPF and DKIM status for domains that use the server's own mail. It's useful for spotting a missing DKIM key, but a hand-built SPF record with multiple includes still needs manual checking.

Step 5: Verify after the TTL expires

Wait out the record's TTL, then confirm what the world sees:

dig +short TXT example.com

Send another test message, open Show original, and look for spf=pass. Repeat the test from every service that sends on your behalf — the website contact form, the invoicing app, the newsletter tool — because each one takes a different path.

Don't let SPF carry everything

A PermError makes DMARC fail on the SPF side, which is why a broken record hurts even when your content is clean. DKIM is the safety net: if your messages carry a valid DKIM signature aligned with your From domain, DMARC can still pass while you sort SPF out. Set up DKIM for every sender that supports it, and only tighten DMARC to p=quarantine or p=reject once you've watched aggregate reports long enough to know what's sending for you.

If you're setting all this up on a new host, Gocelerus is cPanel hosting for Southeast Asia with servers in Singapore, so Zone Editor and Email Deliverability are where you'd expect them while you work through the records above.