SPF 10 DNS Lookup Limit: Avoid PermError | ArawaMail

Direct answer: SPF evaluation is capped at 10 DNS-querying terms (RFC 7208 §4.6.4). Exceeding that returns a permanent error (permerror). DMARC treats SPF permerror as a fail for that identifier. Fix it by counting lookups first, deleting unused vendor includes second, moving leftover senders onto authenticated subdomains third, and flattening only stable ranges as a last, maintained step. Never publish two v=spf1 TXT records at the same name.

What permerror actually means

SPF results include pass, fail, softfail, neutral, temperror, and permerror. Temperror is a temporary DNS or processing problem; retry may succeed. Permerror is permanent for that evaluation—most commonly caused by too many DNS lookups or by multiple SPF records at the same name. Receivers and DMARC processors treat permerror as a hard failure for the SPF identifier, so alignment fails even if the sending IP would have matched.

A passing SPF check never guarantees inbox placement. It only confirms the sending host is authorized for the domain used in the MAIL FROM / Return-Path path.

Which mechanisms count toward the 10

Terms that trigger DNS queries (and therefore count):

• include
• a
• mx
• ptr (discouraged; avoid)
• exists
• redirect

Nested includes consume the same budget. Terms that do not count directly: ip4, ip6, all, exp. There is also a void-lookup limit in the RFC (commonly treated as 2); do not confuse “too many lookups” with “too many dead names.”

Why mail broke after you added one more ESP

Teams routinely append includes during migrations—Google Workspace, Microsoft 365, Mailchimp, HubSpot, SES, a CRM—without removing the ones they no longer use. Each include can expand into several nested lookups. Crossing 10 produces permerror on every evaluation that hits the bloated record.

A second, equally common cause: publishing two separate v=spf1 TXT records at the apex (or at the same subdomain). That is also a permerror. Verification tokens can coexist as separate TXT records; they must not be merged into the SPF string and you must never add a second SPF record “for the new vendor.”

Cleanup order that actually works

1. Count first. Use a live SPF walker or the tools on ArawaMail free email tools to expand the current record and list every DNS-querying term.
2. Delete unused vendors. If people-mail has left Workspace or the old ESP is no longer sending, remove its include.
3. Move leftover senders onto authenticated subdomains. Marketing, transactional, and mailbox traffic on separate subdomains each carry their own SPF/DKIM/DMARC. This keeps the apex record lean and isolates reputation.
4. Flatten only what is stable. Flattening replaces an include with today’s ip4/ip6 ranges. It breaks when the vendor rotates IPs. Prefer managed flattening or a scheduled review over a one-time paste. Do not flatten large, frequently changing ranges (e.g., Google) just to “save lookups.”

Example: bloated vs cleaned

Bloated (typical after a partial migration):

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mailchimp.com include:hubspot.com include:amazonses.com ~all

Each include expands. The total often exceeds 10 nested lookups.

Cleaned (apex for current mailbox + transactional vendor only; marketing moved):

v=spf1 include:_spf.example-mail-provider.com ~all

Plus a separate SPF on news.example.com for the marketing platform. Use the exact SPF record your current provider publishes; ArawaMail writes the required MAIL FROM SPF (and related records) when you enable sending on a Cloudflare domain—do not invent a second apex SPF for it.

How ArawaMail interacts with your existing SPF

Enabling sending on a domain publishes DKIM CNAMEs plus custom MAIL FROM MX and SPF records via Cloudflare. ArawaMail does not remove other vendor includes you already have. Adding ArawaMail on top of an already-bloated apex record is exactly how teams hit the limit during a Workspace or SES migration. Prefer a single coherent apex SPF for the current primary senders and authenticated subdomains for everything else. The custom MAIL FROM / bounce subdomain is the alignment path; it must not become a second apex SPF record.

Methodology note

Lookup costs for large providers change. Walk the live include tree on the day you edit the record rather than relying on a cached count. The 10-query ceiling itself is stable under RFC 7208. For the broader authentication stack see SPF, DKIM, and DMARC explained and How to read a DMARC report. Related practical guides: Why emails go to spam, Verify a domain in Amazon SES, and Move business email off Google Workspace.

FAQ

What is the difference between SPF permerror, temperror, and fail?
Fail means the sending host is not authorized. Temperror is temporary (retry may succeed). Permerror is permanent for that evaluation—most often too many DNS lookups or multiple SPF records.

Can I have two SPF records, one for Google and one for ArawaMail?
No. Multiple v=spf1 TXT records at the same name produce permerror. Consolidate into one record.

Should I flatten, split subdomains, or delete vendors first?
Delete unused includes first, then split remaining senders onto subdomains, then flatten only stable ranges if still needed.

Does a passing SPF lookup guarantee inbox placement?
No. It only confirms authorization for the Return-Path domain.