SPF too many DNS lookups: the 10-lookup limit, how records exceed it, and how to get back under

Nobody exceeds the SPF lookup limit on purpose. A domain gets there by accumulation: Google Workspace at company founding, the marketing platform in year one, the support desk in year two, then billing, the CRM, a survey tool, each vendor's setup guide saying "just add this include to your SPF record." Every instruction was followed correctly. The SPF record that results is syntactically perfect and operationally broken, because SPF has a budget nobody's setup guide mentions: ten DNS lookups per evaluation, hard-capped by RFC 7208.

Cross the line and receivers return permerror, the result that means your record cannot be evaluated at all, for every message, at every receiver that enforces the limit. If a checker just told you "too many DNS lookups," this is the guide to what's being counted and the three ways back under budget. Paste your domain into our SPF checker first; it resolves the whole include tree, shows the running lookup count, and flags the limit breach explicitly, which turns the rest of this page from theory into a worksheet.

What counts against the ten

The limit exists because SPF evaluation makes receivers do DNS work on your behalf, and unbounded recursion would hand attackers a denial-of-service lever. So RFC 7208 counts every term that triggers a DNS query:

• include: — one lookup each, plus every counting term inside the included record, recursively. This is the compounder.
• a and mx — one each (mx may cost more in address resolution, with its own sub-limit).
• ptr — counts, and is deprecated anyway; remove on sight.
• exists: — one each.
• redirect= — one, plus the target record's terms.

Not counted: ip4: and ip6: blocks, the all term, and exp=. That asymmetry is the entire optimization space: IP literals are free, delegation is expensive.

The recursion is what defeats intuition. A record with four includes looks like four lookups, but if one vendor's include contains three nested includes of its own, you're at seven before counting your remaining terms. Two further consequences follow. Your count changes when vendors change their records, so a record that passed in March can permerror in June with no edit on your side. And the separate void-lookup rule (receivers may fail an evaluation after more than two queries returning no data) means dead includes hurt twice.

Confirming the diagnosis

Two symptoms distinguish the lookup limit from other SPF trouble. First, the failure is total but content-blind: your DMARC reports show spf as permerror across all receivers and all mail streams at once, while DKIM continues passing. Second, it can be intermittent, appearing and vanishing as included vendors restructure, which pure syntax errors never do. Check a delivered message's Authentication-Results header with the email header analyzer and run the record through the SPF checker; if the counted total lands at eleven or above, or hovers at nine to ten, proceed to surgery, because a record at the edge is a record that breaks on someone else's schedule.

Fix one: prune

Start with deletion, because most over-budget records carry dead weight. Audit every include against the list of services that still send mail for you. Common findings: the ESP you migrated away from two years ago, a trial tool that never launched, a vendor listed twice under old and new include hostnames, and ptr mechanisms that should not exist at all. Also check for mechanisms duplicating each other, an a or mx term whose addresses are already inside an include you carry. Pruning alone gets a surprising share of records back under ten, costs nothing, and reduces your exposure to vendors' internal changes.

Fix two: restructure by subdomain

The limit is per evaluated domain, and SPF is evaluated against the envelope sender domain, so mail streams split across subdomains each get their own ten-lookup budget. This is the architecturally clean fix, and most platforms push you toward it anyway with their custom return-path setup: marketing mail from em.example.com carrying only the ESP's include, transactional from mail.example.com carrying only that provider's, corporate mail on the root with only your mailbox provider. Each record stays small, an authentication problem in one stream stops bleeding into the others, and the practice matches the wider argument for separating streams made in our domain warm-up guide.

Fix three: flatten, with eyes open

Flattening replaces includes with the ip4:/ip6: blocks they currently resolve to, which cost zero lookups. It works, and it is the standard advice you'll meet elsewhere, so here is the honest caveat: a flattened record is a snapshot. Vendors add and rotate sending IPs without notice, and a stale snapshot silently turns their new servers into softfail events on your legitimate mail. Flatten only what you're prepared to re-verify on a schedule, or automate the regeneration; the SPF generator helps with clean rebuilds either way. Manual flattening of one stable, oversized include is reasonable; flattening your whole record by hand and never touching it again is a slow-motion outage.

Keeping the budget balanced

Whatever combination you use, finish the same way. Re-run the SPF checker and confirm the count sits at seven or fewer, leaving headroom for vendors' internal growth. Verify from the receiving side: a real message to a mailbox you control, headers read, spf=pass with alignment intact and dmarc=pass beside it. Then make the count a maintained number: re-check whenever a sending service is added or dropped, and quarterly regardless, a line item that belongs in your deliverability checklist next to the broader sweep of the email deliverability score. Under the mailbox providers' current rules, catalogued on our Gmail and Yahoo requirement pages, SPF is part of the price of admission for bulk sending, and a record over budget is paying that price in counterfeit.

Related guides

• SPF permerror — the error the lookup limit produces, with its other four causes
• SPF checker — recursive lookup counting and limit detection for any domain
• SPF generator — rebuild an over-budget record cleanly
• SPF softfail — the failure mode stale flattening creates
• SPF, DKIM and DMARC explained — where the lookup budget fits in the full stack
• Email authentication protocols — the protocol map one level up

About this guide

Written by InboxRatio Editorial. The lookup limit, counting rules and void-lookup provisions are drawn from RFC 7208 directly; restructuring approaches are practitioner convention and labeled as such, including the maintenance cost of flattening that vendor guides tend to omit. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on the SPF specification rather than our measurements; the testing protocol is documented in how we test and our source rules in sources.

Last updated

12 September 2026. Specification references reviewed quarterly.

Frequently asked questions

What is the SPF 10 DNS lookup limit? RFC 7208 caps each SPF evaluation at ten DNS-querying mechanisms: include, a, mx, ptr, exists and the redirect modifier all count, and includes count recursively through every nested record. Exceeding the cap returns permerror, meaning the record cannot be evaluated.

How do I check how many DNS lookups my SPF record uses? Use a checker that resolves the include tree recursively, such as our SPF checker; the top-level record alone tells you almost nothing, because most of the count usually hides inside vendors' nested includes.

What happens if my SPF record has too many lookups? Receivers that enforce the limit return permerror: no SPF verdict for any of your mail. SPF then contributes nothing to DMARC, and under the bulk-sender rules at major providers you are effectively sending without SPF until the record is restructured.

Do ip4 and ip6 mechanisms count against the limit? No. IP literals are evaluated without DNS queries, which is why flattening (replacing includes with their current IP blocks) reduces the count, at the cost of a record that goes stale as vendors rotate their sending IPs.

Is SPF flattening a good idea? As a maintained process, yes; as a one-time manual edit, rarely. Flattened records must be re-verified or regenerated on a schedule, or vendors' new IPs will start softfailing your legitimate mail. Prune dead includes and split streams across subdomains first.

Why did my SPF record break without any changes? The count is recursive, so a vendor restructuring its own SPF can push your total over ten from inside an include. Records sitting near the limit break on other people's schedules, which is the argument for keeping the count at seven or below.

The ten-lookup budget is the rare deliverability constraint with an exact number attached, which makes it the rare one you can be exactly sure you've fixed: run the SPF checker, count, restructure, count again.