SPF Lookup Limit — How the Ten DNS Queries Are Counted

Why the limit exists

Every receiving server that evaluates SPF has to issue DNS queries to do so. Without a ceiling that would be abusable: a record pointing at a record pointing at ten more turns every inbound message into an avalanche of queries against someone else's nameservers. RFC 7208 therefore draws the line at ten lookups — not per record, but for the entire evaluation including all nested chains.

This is where SPF most often falls over in practice. A record like v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all looks like three lookups. In fact each include counts its own call plus everything inside the record it fetches — for Google that is currently four more. Counting only your own line is routinely off by a factor of three.

What AnalyzeMy.Email checks

• Recursive total — every include: and redirect= is actually resolved and the fetched record evaluated further, with loop protection and a depth cap.
• What counts and what doesn't — a, mx, ptr, exists, include and redirect cost one lookup each. ip4:, ip6:, all and exp= cost nothing.
• Void lookups — queries returning NXDOMAIN or an empty answer. RFC 7208 §4.6.4 allows only two; the third is a permerror even when the overall count is far below ten.
• The mx sublimit — if the MX lookup returns more than ten records, that is a permerror too.
• The ptr sublimit — beyond ten PTR records the remainder is simply ignored, with no error raised.
• Unresolvable includes — an include pointing at a domain with no SPF record is reported separately.

The report presents this as a breakdown: which mechanism contributed how many lookups, plus a progress bar against the limit and a separate marker for void lookups.

Why the number alone isn't enough

A permerror is considerably worse than a fail. With fail the receiver knows the sender is not authorized — the statement is valid, merely negative. With permerror evaluation was aborted: there is no result at all. For DMARC that means SPF drops out entirely as evidence; the message then passes only if DKIM verifies and is aligned.

What makes this treacherous is that the number is not stable. It depends on what sits inside other people's records, and those change without warning. A record at nine today is at eleven tomorrow because a provider extended their own include. Running just under the limit is not working SPF — it is a time bomb.

What you can do

• Leave headroom: seven or eight lookups is the sensible ceiling, not ten.
• Remove unused includes — the most common and by far the least risky win. Services trialled once two years ago are still in there surprisingly often.
• Split by subdomain: send newsletters from mail.example.com with its own SPF record. Every domain has its own budget.
• Be careful with flattening: replacing includes with the underlying ip4: blocks lowers the count immediately — but commits you to tracking your provider's IP ranges forever. When they change them, your sending breaks.