SPF PermError “Too Many DNS Lookups”: What It Means and How to Fix It

If an SPF checker or a bounce message has told you SPF PermError: too many DNS lookups, your SPF record has quietly stopped working. Mailbox providers aren’t partly checking it. As far as they’re concerned, it’s broken, and that can drag down DMARC and your inbox placement with it.

The good news is that it’s one of the most fixable problems in email authentication. Here’s what’s going on and how to sort it.

What “too many DNS lookups” means

Your SPF record lists the services allowed to send email as your domain. To check it, the receiving server has to look up each entry in DNS. To stop SPF checks being abused or slowing mail down, the SPF standard (RFC 7208) caps these lookups at 10 per check.

Go over 10 and the result is a PermError (“permanent error”). The receiver stops evaluating and treats your SPF as failed. That means:

• SPF can’t help your emails pass DMARC, so you’re relying entirely on DKIM.
• Any sender that isn’t signing with DKIM for your domain will fail DMARC. Under Microsoft’s rules for Outlook and Hotmail, that can mean 550 5.7.515 rejections.
• Once you move DMARC to quarantine or reject, those emails go to spam or bounce.

What counts towards the limit

Not everything in an SPF record costs a lookup:

• Each counts as one lookup: include:, a, mx, ptr, exists: and the redirect= modifier.
• Free (no lookup): ip4:, ip6: and all.

The catch is nested lookups. When you add include: for a provider, you also take on every lookup inside their SPF record. One include can cost you three or four lookups on its own.

There’s also a lesser-known second limit: no more than two “void” lookups. These are lookups that return nothing, typically an include: pointing at a service that has since shut down or changed its address. Go over two and you get a PermError too.

How UK businesses end up over the limit

It rarely happens all at once. A typical record grows over a few years: Microsoft 365 or Google Workspace, then a newsletter platform, then a CRM, a helpdesk, accounting software that emails invoices, a booking system, the website’s contact form, and a platform someone trialled in 2022 and never removed. Each one asked you to “add our include to your SPF record”, and nobody added up the total.

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:mail.crm-example.com include:sendgrid.net include:helpdesk-example.com a mx ~all

A record like this can easily need 12 to 15 lookups once the nested includes are counted.

How to fix it

1. Count your lookups

Run your domain through an SPF lookup counter that expands every nested include, so you can see which entries cost the most. Write the list down: you’ll need it for the next steps.

2. Remove anything you no longer use

This is the quickest win. Ask “do we still use this?” of every include. Old marketing platforms, a previous email host after a migration, and abandoned trials are all common.

3. Check whether each platform actually needs to be in your SPF

SPF checks the Return-Path (bounce) domain, not the From address people see. Many marketing and transactional platforms use their own bounce domain unless you set up a custom one. In that case your include: does nothing for SPF at all. Those emails pass DMARC through DKIM signed with your domain instead. Check each platform’s domain authentication settings before removing anything, but this often frees up several lookups.

4. Swap a and mx for fixed IP addresses

If your web server or mail server has a fixed IP address, list it with ip4: (free) instead of a or mx (one lookup each). Only do this for IPs you control and that won’t change without you knowing.

5. Remove ptr

The SPF standard says ptr should not be used. It’s slow, unreliable and costs a lookup. If it’s in your record, it can almost always go.

6. Move some senders to a subdomain

Send marketing from news.yourdomain.co.uk or invoices from billing.yourdomain.co.uk, each with its own SPF record. Every subdomain gets its own 10-lookup allowance, and it keeps the reputation of your marketing mail separate from your day-to-day business email.

7. Be careful with “SPF flattening”

Flattening replaces includes with the IP addresses behind them, which brings the count right down. The risk is that providers change their IPs without telling you, and a flattened record silently goes out of date. If you flatten, use a service that keeps the record updated automatically rather than doing it by hand once.

After you’ve made the change

• Make sure you still have exactly one SPF record. Two v=spf1 records is a separate PermError.
• Re-count the lookups: you want 10 or fewer, ideally with a couple spare for the next tool you adopt.
• Send test emails from each platform and check the headers show spf=pass or an aligned dkim=pass.
• Watch your DMARC reports for a week or two to catch any sender you missed.