SPF exceeds the void DNS lookup limit

Evaluating ‹domain› produced ‹void lookups› void lookups (NXDOMAIN or an empty answer). RFC 7208 §4.6.4 says receivers SHOULD limit these to two (a limit they make configurable should default to two), and that exceeding the limit produces permerror; the limit exists to stop SPF records being used to amplify DNS traffic. Not every receiver applies it, but one that does rejects the whole record.

A void lookup is a DNS query made during SPF evaluation that comes back with nothing: the name does not exist, or it exists without a record of the type asked for. The terms that produce them are include: and redirect= targets that do not exist or have no TXT records at all, a: and mx: names with no address or MX records, and exists: targets. A target that has TXT records, none of them SPF, answered, so it is not void; it is still a broken include, which email.spf.include-unresolvable reports. The count runs across the whole evaluation, nested includes included, and it is separate from the ten-lookup limit — a record well under ten lookups can still fail here.

Typical sources are a mail or marketing service you cancelled whose SPF hostname the provider has since removed, a misspelt include, an a: naming a decommissioned server, and mx on a domain that no longer receives mail. An include: whose target has no SPF record fails on its own too, void or not, which email.spf.include-unresolvable reports, so fixing these usually clears both findings.

An exists: term built from a macro such as %{i} is designed to come back empty for most senders, and every empty answer counts at the receiver. A scan has no message to expand such a macro with, so it does not count those; if your record uses one, keep every other term that can come back empty out of it.