How to count your SPF DNS lookups
Count your SPF DNS lookups by recursively expanding the record and tallying every include, a, mx, ptr, exists, and redirect term (plus the A/AAAA queries mx and a trigger). ip4, ip6, and all cost zero. Stay under 10.
Counting your SPF DNS lookups means recursively expanding your record and tallying every mechanism and modifier that triggers a DNS query during evaluation. Get the number right and you know exactly how much headroom you have before a receiver returns PermError. Get it wrong — or never check — and a single new vendor include: can silently push you past the cap and break authentication for every message you send. This guide shows you what counts, how to count it by hand, and how to verify the total automatically.
The counting rules come straight from RFC 7208, which caps SPF evaluation at 10 DNS-querying terms. If you need the full background on why that ceiling exists and what happens when you cross it, start with the pillar guide on SPF too many DNS lookups and the companion breakdown of the 10-lookup limit explained.
What counts as a DNS lookup in SPF?
Not every term in a v=spf1 record costs a lookup. The distinction is the single most misunderstood part of SPF, so commit it to memory.
These mechanisms and modifiers trigger a DNS lookup and count toward the 10-lookup limit:
include:— fetches the included domain’s SPF record (a TXT query), then evaluates it recursively against the same budgeta— resolves the target hostname’s A/AAAA recordsmx— fetches the MX record set, then resolves each returned mail exchanger to A/AAAAptr— performs reverse DNS lookups (deprecated by RFC 7208 and best removed entirely)exists— evaluates whether a constructed domain name exists via one DNS queryredirect=— hands evaluation to another domain’s entire SPF policy and counts as a lookup
These do NOT count — they consume zero lookups:
ip4:andip6:— static addresses, no DNS query neededall(whether~allor-all) — a match qualifier, not a lookupexp=— fetched only to build an explanation string after a failure; not part of the pass/fail decision and excluded from the count by most receivers
The critical nuance: include, mx, and a don’t cost a flat “one” each. Nested work multiplies. An include: can import more includes and a/mx mechanisms, and each mx expands to every mail exchanger’s A/AAAA records. That’s how records that look short on paper blow past 10 in practice.
How to count SPF lookups by hand with dig or nslookup
You can trace the entire evaluation from the command line. The goal is to reproduce what a receiving mail server does: fetch your record, expand every DNS-querying term recursively, and add up the queries. (For a deeper reference on the tooling itself, our guides on checking SPF with nslookup, PowerShell and dig and SPF verification with dig, nslookup and PowerShell go step by step.)
1. Fetch your top-level SPF record.
dig +short TXT example.comOn Windows, the equivalents are nslookup -type=TXT example.com or, in PowerShell, Resolve-DnsName -Type TXT example.com.
2. Identify every DNS-querying term in the string — count each include, a, mx, ptr, exists, and redirect.
3. Expand each include and redirect recursively. For every included domain, run another TXT query and keep counting:
dig +short TXT _spf.google.com
dig +short TXT spf.protection.outlook.com4. Enumerate the implied A/AAAA and MX queries. For an mx mechanism, fetch the MX set and then resolve each host:
dig +short MX example.com
dig +short A mail.example.com5. Add it all up, using worst-case logic. Assume no early match short-circuits the evaluation, because a receiver checking an IP that matches last has to walk the whole chain. Stop the moment your running tally reaches 10 — that’s where many receivers issue PermError.
A quick example of how fast this escalates: mx:example.com where the MX set returns four hosts costs 1 lookup for the MX RRset plus up to 8 A/AAAA lookups — 9 lookups from a single mechanism. Add two vendor includes on top and you’re already over. The full mechanism-by-mechanism math is laid out in what causes SPF validator lookup-limit issues.
Don’t forget void lookups
Separate from the 10-lookup cap, RFC 7208 also limits void lookups — DNS queries that return NXDOMAIN or NODATA — to two. A dead include: pointing at a domain that no longer publishes SPF, or a hostname that no longer resolves, burns void lookups and can trigger PermError on its own even when your main count is fine. When you count, note any query that comes back empty and treat two as your ceiling.
Why the manual count is easy to get wrong
Hand-counting works, but it’s fragile for three reasons. CNAME indirection adds hidden hops: if an a target is a CNAME, resolution needs an extra query you won’t see in the record text. Dual-stack resolution means many receivers query both A and AAAA for the same host, quietly doubling a/mx costs. And vendor drift makes any count a snapshot — providers rotate IPs and restructure their own includes on a median cadence of a few days, so a record that counted 9 last month can count 11 today without you touching a thing.
That last point is why counting once is never enough. You need to re-count on every SPF change and monitor for vendor changes you don’t control.
Count it automatically with an SPF Checker
The reliable way to count is to let a tool mirror receiver behavior for you. AutoSPF’s SPF Checker fetches your live record, expands every nested include, follows redirects, resolves MX and A/AAAA branches, detects CNAME hops, and returns the exact lookup total — plus a separate void-lookup count and a flag on the precise mechanism that pushes you over. You get the worst-case number a strict receiver like Microsoft 365 or Gmail would compute, not an optimistic estimate.
Counting is only half the job, though. Once you know the number, you have to keep it under 10 as vendors change. That’s where an automatic SPF flattening service earns its place: AutoSPF rescans your includes every 15 minutes, resolves them to exact IP addresses, de-duplicates overlapping ranges, and republishes — so your lookup count stays low without manual DNS edits. When counting reveals you’re over the limit, SPF flattening is the standard fix, and the sibling guides on how to reduce SPF lookups and the SPF 255-character limit cover what to do next. If your record is already failing, the fix SPF PermError walkthrough gets you back to green.
Frequently Asked Questions
Do ip4 and ip6 mechanisms count toward the 10-lookup limit?
No. ip4: and ip6: mechanisms are static addresses that require no DNS query, so they cost zero lookups. This is exactly why flattening works: replacing a lookup-heavy include: with the resolved ip4:/ip6: ranges it points to drops your count while preserving the same sender authorization.
Does an mx mechanism only count as one lookup?
No — it usually costs far more than one. An mx mechanism first queries the MX record set (one lookup), then resolves every returned mail exchanger hostname to its A and AAAA records. A domain with four MX hosts can consume up to nine lookups from that single mx term. If your outbound senders aren’t your inbound MX hosts, you often don’t need mx at all.
Do CNAMEs increase my SPF lookup count?
They can. If an a mechanism references a hostname that is actually a CNAME, the resolver must follow the CNAME to reach the A/AAAA records, adding a query that isn’t obvious from the record text. Tools that display the full resolution chain surface these hidden hops so you can replace the mechanism with a static ip4:/ip6: entry.
Why does an online checker show more lookups than my record passes with?
Checkers often report the worst-case count — expanding every path and counting both A and AAAA queries — while a receiver may short-circuit as soon as the connecting IP matches an early mechanism. Design for the worst case anyway: an IP that only matches your last term forces a full walk, so the worst-case number is the one that determines whether you’ll ever see a PermError.
How many lookups should I aim for?
Stay comfortably under the cap rather than right at it. Targeting 8 or fewer gives you headroom, because vendors add includes and rotate infrastructure without warning and a record sitting at exactly 10 can tip over the moment a provider changes their own SPF. Enforcing a budget of 8–9 in your review process prevents surprise breakage.
Does the exp= modifier count toward the limit?
Generally no. The exp= modifier is fetched only to construct a human-readable explanation string after an SPF failure, and it plays no part in the pass/fail decision. Most receivers exclude it from the 10-lookup tally, though a few diagnostic libraries may still resolve it.