Finding the void lookups

After this lesson you can

Locate every void lookup in a record tree and say which term produced it.

Assumes you have read Counting, with the working shown.

There are two limits in RFC 7208 §4.6.4, and the second one is the reason a record with six lookups can be permanently broken while everyone stares at the ten-lookup count and finds nothing wrong.

What counts as void

A void lookup is a DNS query made during evaluation that returns NXDOMAIN or NOERROR with no answer. More than two and the evaluation is a permerror.

Two is the whole budget

Not two per include. Two for the entire evaluation, across every nested record. It is a much tighter budget than the ten, and it is spent by things that look inert.

Where they come from

A decommissioned include target. The vendor is gone and the name no longer resolves. This is the common case, and note the record was not edited when it broke.
An a: or mx on a name with no records of that type — NOERROR with an empty answer still counts.
A hostname that was renamed. a:mail.old.example after a migration.
An exists: that legitimately misses — and this one is not a fault. A per-IP scheme returns NXDOMAIN for every unauthorised address by design, which is one void lookup spent on the normal path.

Finding them

Walk the tree from the budget audit and resolve every name, noting which return nothing:

# every include target in the tree
for t in spf.protection.outlook.com _spf.example-vendor.net mail.old.example; do
  printf '%-40s ' "$t"
  out=$(dig +short TXT "$t" | grep -c spf1)
  if [ "$out" = "0" ]; then echo 'VOID — no SPF record'; else echo ok; fi
done

# and every a:/mx: name
dig +short A mail.old.example   # empty answer is still a void lookup

The interaction that makes this hard to spot

A domain can sit at six lookups — comfortable — and three void ones, which is a permerror. Someone diagnosing it counts to ten, finds six, concludes the record is fine, and goes looking at DKIM. The count is a necessary check, not a sufficient one; always run both.

Fixing

Delete the terms that resolve to nothing. There is no subtlety: a mechanism pointing at a name that does not exist cannot authorise anything, so removing it changes no result and recovers both budgets at once.

The reason it is worth a lesson is that nothing surfaces it. The record looks well-formed, the vendor is long forgotten, and the only symptom is a permerror that a lookup count does not explain.

Knowledge check

A record has six lookup-costing terms. Two include targets no longer resolve. Receivers report permerror. A colleague has counted the lookups, found six, and says the record is fine. Who is right?

The receivers. Six is under the ten-lookup limit, but two dead includes breach the separate two-void-lookup limit in the same section.
The colleague. Six lookups cannot produce a permerror, so the cause is elsewhere.
Neither — dead includes are skipped, so the count is really four.
The colleague, unless the dead targets are also over their own lookup budgets.

Correct — The receivers. Six is under the ten-lookup limit, but two dead includes breach the separate two-void-lookup limit in the same section. RFC 7208 §4.6.4 sets two independent budgets. The dead targets produce void lookups — and an include whose target has no SPF record is independently a permerror under §5.2, so either route reaches the same hard failure. Counting to ten is necessary and not sufficient.

Not this — The colleague. Six lookups cannot produce a permerror, so the cause is elsewhere. This is exactly the reasoning the void-lookup limit defeats, and why records sit broken while people look at DKIM.

Not this — Neither — dead includes are skipped, so the count is really four. They are not skipped. An include whose target has no SPF record is a permerror in its own right, quite apart from the void budget.

Not this — The colleague, unless the dead targets are also over their own lookup budgets. A target that does not resolve has no record and therefore no budget of its own. The failure is the absence, not anything inside it.

Last reviewed 2026-09-15

Finding the void lookups

What counts as void

Where they come from

Finding them

Fixing

Try it on a real domain

Go deeper