SPF "Too Many DNS Lookups": How to Fix the 10-Lookup Limit

If a checker tells you "SPF permerror: too many DNS lookups", your SPF record is evaluating to more than ten DNS queries, and receivers are allowed to treat the whole record as invalid. That means none of your senders are authorised by SPF, even though each one looks correct on its own.

It is one of the most common SPF faults, and it usually appears slowly: each new tool you connect adds an include:, and one day you cross the limit.

What counts toward the limit

The SPF specification (RFC 7208) allows at most 10 DNS-querying terms during evaluation. These count:

• include:
• a
• mx
• ptr (do not use it; it is deprecated)
• exists:
• redirect=

These do not count: ip4:, ip6: and all. They need no lookup because the answer is already in the record.

The catch is that lookups are counted recursively. If you write include:_spf.bigvendor.com and that record contains four more include: terms, you have spent five lookups, not one. An mx term costs one lookup for the MX records, and the standard limits the mail server names it then resolves.

There is a second, quieter limit too: no more than two "void" lookups, meaning lookups that return nothing. A typo in an include: domain can trip it.

Step 1: Count what you have

Take your record and walk it by hand, or paste it into an SPF checker that shows the lookup count (see checking SPF, DKIM and DMARC). For a record like this:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:servers.mcsv.net a mx ~all

You can already see six top-level lookups, and each include: probably expands further. This record is likely over the limit.

Step 2: Remove what you do not use

Before any clever trick, delete dead weight. In most old records a good share of the entries belong to services nobody uses any more: a retired newsletter tool, a trial helpdesk, a previous host. Confirm by checking your DMARC aggregate reports (see reading DMARC reports) to see which sources actually send mail as you.

Also drop a and mx unless you really send from the web server or mail server named by those records. They are often added by habit.

Step 3: Replace includes with IP addresses

If a service publishes stable IP ranges, you can list them directly with ip4: and ip6:, which cost no lookups. The risk is that providers change their addresses. You must keep your copy up to date, or mail starts failing silently. Only do this for senders whose ranges you control, such as your own servers.

Step 4: Move senders to subdomains

A neat structural fix is to give each major sender its own subdomain, each with its own short SPF record:

• yourdomain.com for your mailboxes
• app.yourdomain.com for transactional mail from your product
• news.yourdomain.com for newsletters

Each subdomain has its own ten-lookup budget, and a problem with one stream cannot damage the others. It also separates reputations, which is good practice anyway. DMARC alignment is relaxed by default, so subdomains still align with the parent domain.

Step 5: Use "flattening" with care

SPF flattening tools resolve all your includes into plain IP lists automatically and republish them. This keeps you under the limit, but it only works if the tool keeps refreshing the record, and long flattened records can outgrow what a single DNS answer carries comfortably. Treat flattening as a last resort and monitor it.

Quick reference

Prevent it from coming back

Keep a short list of every service that sends as your domain and why. When you add a tool, count lookups before you publish. And if you only send application mail, you can often keep an SPF record tiny.

How Mailions keeps it simple

Mailions shows the exact SPF record for each domain and checks it against live DNS, and the setup guide explains how to merge it with an existing record rather than create a second one. For sending-only domains you keep your current inbox provider and add just what is needed. If you are close to the limit, put your application mail on a dedicated subdomain.