SPF Record Too Many Lookups: Causes and How to Fix It

An “SPF record too many lookups” error means evaluating your SPF record needed more than 10 DNS lookups, which the standard forbids and treats as a permanent error. The usual causes are stacked include: entries for marketing, support and billing tools. Fix it by removing unused senders, then consolidating, and only then flattening.

Why the limit exists

SPF, defined in RFC 7208, caps the number of DNS-querying terms to protect receiving servers from expensive or abusive records. BusinessMCP’s SPF, DKIM and DMARC guide states the practical rule: SPF allows a maximum of 10 DNS lookups per check, and exceeding it causes a permanent error. Two SPF records on one domain cause the same error.

The consequence is not cosmetic. A permerror means the receiver cannot evaluate SPF at all, so mail may fail authentication, and with a strict DMARC policy that can mean rejection if DKIM does not also pass.

What counts toward the 10

Term	Costs a lookup?
include:	Yes, plus any lookups inside the included record
a	Yes
mx	Yes, and the mailbox hostnames may add more
ptr	Yes (and discouraged by the standard)
exists:	Yes
redirect=	Yes
ip4: / ip6:	No
all	No

The trap is nesting. One include: for a large provider can itself contain several further includes, and every one counts. Your record may look like four entries and cost twelve lookups.

Key takeaway: count lookups recursively, not by the entries you can see. The visible length of the record says almost nothing about its cost.

How to audit your record

1. Fetch the TXT record that begins v=spf1 for the domain. Confirm there is exactly one.
2. List every include, a, mx, exists and redirect term.
3. For each include, fetch its record and repeat, adding up as you go.
4. Stop when you reach 10; note which terms push you over.
5. Mark each sender as active, retired or unknown.

You can do this by hand with dig TXT yourdomain.com and dig TXT _spf.provider.com, or with a checker. An API check such as BusinessMCP’s email authentication endpoint grades SPF with fixes for failures, which is a quick way to detect a permerror across many domains. We cover that approach in the DMARC checker API article. Exactly how any given tool counts nested lookups is something to test on a record you understand before trusting it.

Fix order that minimises risk

1. Remove dead senders. Most records accumulate tools nobody uses. Ask each team which platforms send as your domain; delete retired ones. This often fixes the problem alone.

2. Move third parties to subdomains. Send marketing mail from news.yourdomain.com with its own SPF record, leaving the root domain’s record lean. Each subdomain gets its own 10-lookup budget. Make sure DKIM and DMARC alignment still work for the new From address.

3. Prefer DKIM-signed senders. Where a platform signs with your domain via DKIM, DMARC can pass on DKIM alone, and its SPF include may be unnecessary. Confirm in that provider’s documentation before removing anything.

4. Replace a and mx with ip4 where addresses are stable. If your own server sends mail from a fixed address, a literal ip4: saves lookups. Do not do this for providers whose addresses change.

5. Flatten only as a last resort. Flattening replaces includes with literal IP ranges. It works until the provider changes its ranges, and then mail silently starts failing. If you flatten, use a service or script that refreshes automatically and alerts on drift.

Mistakes to avoid

• Publishing a second SPF record “to add one more sender” instead of editing the first.
• Switching to -all (hardfail) before confirming every legitimate sender is listed. ~all softfail is common while you verify, per the guide.
• Forgetting the 255-character limit on a single DNS string; long records must be split into quoted segments within one TXT record.
• Editing DNS without noting the old value so you can roll back.

Verify after you change it

DNS changes usually take effect within an hour, depending on TTL, per BusinessMCP’s guide. Then:

1. Re-fetch the record and recount lookups.
2. Send test messages from every platform and inspect the Authentication-Results header.
3. Watch DMARC aggregate reports for new failures over the next 2 to 4 weeks.
4. Add the domain to a recurring check so a future include does not quietly break it; see bulk domain audits.

If you are earlier in the journey, start with automating SPF, DKIM and DMARC checks. Provider ranges, limits and the RFC itself are the authority; confirm details there before editing production DNS.

Worked example: counting a real-looking record

Suppose a domain publishes v=spf1 include:_spf.google.com include:mailer-one.example include:crm-tool.example include:support-desk.example mx a ~all. The visible terms are six. But each include may expand: say the mail platform’s record contains three further includes, the CRM’s contains one, and the support desk’s contains two. Then the count is the four top-level includes, plus 3, plus 1, plus 2, plus mx, plus a, which is 12. The record exceeds the limit although it looks short.

Component	Lookups
Four top-level includes	4
Nested includes inside them	6
mx	1
a	1
Total	12

The numbers in this example are illustrative, not measurements of any real provider, and real providers change their records over time, which is why a count that was fine last year can quietly cross the line when a vendor adds an include.

Detecting the problem across many domains

Hand counting does not scale. An automated email authentication check, such as the one in BusinessMCP’s website checks API, is a practical way to find which domains in a portfolio have SPF problems at all, after which you dig into only those. Run it monthly: new includes arrive whenever someone signs up for a tool, and nobody tells the DNS owner.

Alternatives to flattening

• Subdomain delegation. Give each sending platform its own subdomain and record, as described above.
• Provider-managed records. Some providers offer a hosted SPF record you include once, and they maintain the contents. This moves the lookup cost into their record, so it still counts, but updates are not your job.
• DKIM-first strategy. If DMARC passes on DKIM alignment, SPF becomes secondary, and you can prune it. Confirm with test messages before removing anything.

A pre-change checklist

1. Export the current DNS zone as a backup.
2. Record the current lookup count and the list of senders.
3. Make one change at a time.
4. Wait for TTL, then test.
5. Keep the rollback value handy for at least a week.

Changes to SPF affect real mail. When in doubt, ask your email provider’s support, and rely on RFC 7208 and the providers’ documentation rather than a blog post, including this one.