SPF Lookup Counter
RFC 7208 caps SPF evaluation at 10 DNS lookups. Once you cross that line, receivers return a permerror and SPF stops protecting your domain.
This tool counts every lookup your SPF record consumes — including the ones hidden inside your include: chains.
Want the full breakdown (mechanism analysis, include tree, warnings)? Use the full SPF Checker.
How we count lookups
We follow exactly what RFC 7208 §4.6.4 mandates a receiving mail server to do, so the number you see is the number that breaks your delivery.
Mechanisms that consume a lookup
include:— and any lookup inside the resolved recordredirect=— replaces evaluation entirelya/a:domainmx/mx:domainexists:ptr(deprecated — remove it)
Mechanisms that don't
ip4:/ip6:— literal addressesall— final policy, no DNS work- The
v=spf1prefix itself
Flattening an include into raw ip4:/ip6: values trades DNS lookups for record length — useful when you're close to the limit, but needs maintenance.
Why the limit exists, and what blowing it costs you
The 10-lookup cap is there because SPF evaluation happens during the SMTP handshake. Every receiver has to do the lookups before deciding whether to accept your mail. Without a cap, a malicious or sloppy SPF record could force the receiver to do thousands of DNS queries per inbound message.
When your record exceeds the limit, the receiver doesn't just ignore the extra lookups — RFC 7208 instructs it to return permerror, which most large providers (Google Workspace, Microsoft 365) treat the same as having no SPF record at all. DMARC checks that depend on SPF alignment will fail. Your deliverability tanks. There is no warning email — your mail just starts landing in spam.
The frustrating part: most domains don't blow the limit through one big record. They drift over it. A new SaaS vendor adds an include:. Three months later that vendor adds their include. Six months later you're at 11 lookups and your campaigns stop working. That's the gap monitoring fills.
SPF Lookup Counter — FAQ
Why does SPF have a 10 lookup limit?
RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups to bound the work a receiving server has to do and prevent denial of service via deeply nested include chains.
Which SPF mechanisms count as DNS lookups?
include:, a:, a (bare), mx:, mx (bare), redirect=, exists:, and ptr each consume one lookup. ip4:, ip6: and the all mechanism do not consume any.
Do includes inside includes count?
Yes — the limit is cumulative across the entire evaluation tree. An include: that resolves to a record with three include: mechanisms inside adds 4 lookups (one for the parent include plus its children).
What happens when I exceed the limit?
Receivers return a permerror result, which most large providers (Google, Microsoft) treat the same as 'no SPF' — your domain loses SPF protection until you fix the record.
How do I reduce my SPF lookup count?
Remove unused vendor includes, consolidate when possible, or flatten high-lookup includes into raw ip4:/ip6: ranges. Flattening needs ongoing maintenance — DNSMonit alerts you when a flattened record drifts.
Get alerted before you hit 11 lookups
Most SPF outages start as a quiet drift. DNSMonit re-counts your lookups every hour and emails you the moment any change pushes you toward the limit — before deliverability breaks.