SPF Too Many DNS Lookups: How to Find the Limit and Fix It

If your domain returns "too many DNS lookups," your SPF record is asking receiving mail servers to do more work than the standard allows. The result is a `permerror`, and most receivers treat a `permerror` the same way they treat an outright SPF failure. Your record is not partially working. For SPF purposes, it is not working at all.

The limit is 10 DNS lookups per evaluation, defined in RFC 7208 section 4.6.4. There is a second, less known limit of 2 void lookups, meaning queries that return no record. Exceed either one and evaluation stops with an error.

Here is the part most people miss: you can sit at 14 lookups for months without noticing. If your main platform signs mail with DKIM, DMARC still passes on the DKIM side, so your everyday email keeps landing. The failure shows up later, on the one system that does not sign, usually invoices, appointment reminders, or contact form notifications. That is why this error tends to surface as "only some of our email goes to spam."

Why SPF records cross the limit

Almost nobody writes a record with 11 lookups in it. Records grow one vendor at a time. Your mail platform, then a CRM, then an invoicing tool, then a scheduler, then a newsletter service, each one handing you an `include` line to paste in.

The trap is that `include` statements are recursive. Each one points at another domain's SPF record, and that record has includes of its own. A record with four visible entries can easily cost twelve lookups.

``` v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.hubspot.com include:spf.protection.outlook.com ~all ```

Four includes. Well over the limit once the nesting is counted.

What counts toward the 10

Every mechanism that requires a DNS query counts: `include`, `a`, `mx`, `ptr`, `exists`, and `redirect`. `ip4` and `ip6` cost nothing, which is the key to most fixes below.

Two details worth knowing:

An `mx` mechanism costs one lookup, but the MX records it returns are themselves capped at 10. Most domains do not need `mx` in SPF at all, because it authorizes the servers that receive your mail rather than the ones that send it.
`ptr` is deprecated and should be removed on sight. It is slow, unreliable, and receivers may ignore it.

Void lookups are separate. If an include points at a domain that no longer publishes an SPF record, which happens constantly with discontinued vendors, two of those will fail your record on their own, well before you reach 10.

Count before you change anything

Typical costs for common senders, based on what we see across domains running the health check:

| Sending service | Include | Approximate lookups | |---|---|---| | Google Workspace | `_spf.google.com` | 4 | | Microsoft 365 | `spf.protection.outlook.com` | 1 to 2 | | Mailchimp | `servers.mcsv.net` | 1 | | SendGrid | `sendgrid.net` | 1 to 2 | | HubSpot | `_spf.hubspot.com` | 2 to 3 | | Salesforce | `_spf.salesforce.com` | 2 | | Zendesk | `mail.zendesk.com` | 1 to 2 | | Constant Contact | `spf.constantcontact.com` | 1 |

These change without warning when a provider restructures its infrastructure, which is exactly why a record that passed last year can fail today with no action on your part. Check yours live rather than trusting a table, including this one.

The fix, in order of how long it lasts

Work top to bottom and stop when you are under the limit. The options at the top hold up over time. The ones at the bottom need maintenance.

1. Inventory what actually sends mail as your domain. Not what receives it, and not what you signed up for and forgot. Walk your billing statements: every SaaS subscription that emails a customer on your behalf is a sender. Appointment reminders, invoices, e-signature requests, support replies, form notifications.

2. Delete includes for services you no longer use. This alone solves it for most small businesses. A marketing platform you left two years ago is still costing you lookups, and if the vendor pulled its SPF record, it is costing you a void lookup too.

3. Move high-volume streams to a subdomain. Point bulk and transactional mail at something like `mail.yourdomain.com` or `send.yourdomain.com` and give that subdomain its own SPF record with its own 10-lookup budget. Your employee mail stays clean on the main domain. This is the most durable fix available, and the one large senders use. It only works if the platform is configured to use the subdomain as the envelope sender, sometimes called the return-path or bounce domain, so confirm that in the vendor's settings rather than assuming.

4. Ask vendors for a cheaper authorization method. Some publish a stable set of IP ranges you can add as `ip4` entries at zero lookup cost. Some offer a dedicated include that skips a layer of nesting. It is worth one support ticket before you resort to flattening.

5. Flatten, only with a process behind it. Covered below.

Flattening is a maintenance commitment, not a fix

SPF flattening means replacing `include` statements with the raw IP addresses inside them. It works, and it drops your lookup count to zero for those entries. It also means that the moment your provider adds a sending IP, mail from that IP loses authorization and starts failing SPF, with no warning and no error on your end.

Flattening is reasonable if you have automated tooling that refreshes the list when the source record changes. It is a bad idea as a one-time copy and paste, which is how it is usually done. If you are choosing between flattening manually and moving a mail stream to a subdomain, take the subdomain.

Four mistakes that make this worse

Publishing a second SPF TXT record. A domain gets one. Two produces a permanent error, and you have now broken SPF completely instead of partially.
Removing includes at random to get under 10. Every one you cut is a sender that will start failing. Confirm it is dead first.
Switching to `+all` to stop the errors. This authorizes the entire internet to send as your domain and will do more damage than the original problem.
Assuming DMARC is fine because mail is delivering. If SPF permerrors and one platform is not DKIM signing, that platform's mail is unauthenticated. Under a `p=reject` policy it gets rejected outright.

Check your record

You do not have to check this by hand. Run the free email health check and the Report Card will show your current lookup total, expand the nesting so you can see which include is expensive, and flag void lookups from dead vendors. If the fix needs DNS changes you would rather not make yourself, Matano IT can implement them.