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

Your SPF record is published, every sending service is listed, and mail is still failing authentication with spf=permerror or a bounce that mentions "too many DNS lookups". This is the most common way a well-intentioned SPF record breaks, and it breaks completely: a PermError is treated by most receivers as if you had no SPF at all, and by a strict DMARC policy as a failure.

Here is what the limit is, how to count your lookups, and the three ways to get back under it.

The 10-lookup limit

The SPF specification (RFC 7208, section 4.6.4) says a receiver must stop evaluating a record after 10 DNS lookups and return a PermError. The limit exists to stop SPF being used to make receivers do unbounded DNS work. It is not configurable, and no major receiver ignores it.

Each of these mechanisms costs one lookup:

• include:, plus everything inside the included record, recursively
• a and a:domain
• mx and mx:domain
• ptr (deprecated, and slow as well as expensive)
• exists:
• redirect=

These cost nothing:

• ip4: and ip6:
• all

There is a second, lesser-known limit: no more than two "void" lookups, meaning includes or mechanisms that point at a name with no record. Two broken includes are enough to fail the whole record even if the total count is low.

Why the count is higher than it looks

The trap is that includes nest. A record like this looks like three lookups:

v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net -all

But _spf.google.com includes three further records, so Google alone costs four. Add a CRM, a helpdesk, a billing system and a second marketing tool, and a record with six includes can easily reach 14 or 15 lookups. Nothing warns you when you add the seventh include; the record simply stops working.

To get an exact count you have to fetch every included record and add them up, the way a receiver does. The free SPF checker does this and reports the total against the limit of 10, along with any include that points at a missing record.

Fix 1: remove what you do not use

Start here, because it is free. Most records that go over the limit contain services that were tried once and never removed, or two tools that do the same job. For each include, ask whether that service still sends mail as your domain. If you are not sure, check the service's own sending settings: many send from their own domain by default and only need SPF if you have set up custom-domain sending.

Also remove ptr if it is there. It is deprecated, counts as a lookup, and most receivers ignore it anyway. If you have a or mx and your web or mail server never actually sends outbound mail, remove those too.

Fix 2: flatten includes into IP addresses

Replace an include: with the ip4: and ip6: ranges it resolves to. IP mechanisms cost no lookups, so a record of nothing but IPs cannot go over the limit.

The catch is maintenance. Providers change their IP ranges, and when they do, your flattened record is wrong until you update it. Only flatten services whose ranges are stable and documented, such as your own servers, or use a tool that re-flattens automatically. Never flatten the big providers by hand; Google, Microsoft and the large ESPs change ranges without notice.

Also watch the record size. A TXT record over 255 characters has to be split into multiple strings, and the whole record should stay under about 450 characters to fit in a single UDP DNS reply. Long flattened records can hit this limit.

Fix 3: use subdomains for different senders

The cleanest long-term fix. Each sending service gets its own subdomain with its own SPF record: marketing mail from news.example.com, transactional mail from mail.example.com, your helpdesk from support.example.com. Each record has one or two includes and never approaches the limit.

This also isolates reputation: a problem with one stream does not drag down the others. The only cost is configuring each service to send from its subdomain, and setting the subdomain's DMARC alignment. Our guide to SPF, DKIM and DMARC covers how the three fit together.

Mistakes that produce PermError without the lookup limit

• Two SPF records. A domain must have exactly one TXT record starting with v=spf1. Two is a PermError. This usually happens when a second service's setup guide says "add this TXT record" and someone adds it instead of merging it.
• Two records pasted into one. A record that contains v=spf1 twice is invalid.
• Typos in mechanisms. includes:, ip: or a missing colon make the term unrecognised, which fails the record.
• An include pointing at a domain with no SPF record. This is a void lookup, and two of them fail the record.

The SPF checker flags each of these. Re-run it after every change, and once a quarter in any case: a provider adding an include to its own record can push you over the limit without you touching anything.

Why this matters for deliverability

With a PermError, SPF contributes nothing. If DKIM is also missing or unaligned, DMARC fails, and under a p=reject policy your own mail is rejected. Gmail and Yahoo require bulk senders to authenticate, so a broken SPF record is a direct route to the spam folder. If you suspect that is where your mail is going, the checklist in why cold emails land in spam starts with authentication for that reason.