SPF Void Lookups: Causes, Limits and Fixes

An SPF void lookup is a DNS query made while evaluating an SPF policy that returns no usable answer. Too many void results can turn an apparently tidy record into an SPF PermError.

What counts as a void lookup

RFC 7208 describes a void lookup as an empty DNS result such as NXDOMAIN or a successful response with no answers. It is not the same as every lookup-causing SPF term, and it is not measured by counting characters in the TXT record.

The two-result limit

SPF evaluation should permit no more than two void lookups. A third void result during one evaluation causes a permanent error. This limit is separate from the overall limit on DNS-querying mechanisms and applies across nested include and redirect processing.

Where void results arise

An include or redirect may point to a name that no longer publishes the expected SPF policy. The a, mx, exists or ptr mechanisms can also produce empty answers. Nested provider policies matter: the problem may not be visible in the top-level record.

Worked chain

Suppose a policy includes two retired vendor names. Each returns NXDOMAIN, producing two void results. A later exists mechanism returns no answer and becomes the third. Evaluation stops with PermError even if a valid include appears afterwards.

Diagnosis process

Capture the exact public SPF record and DNS responses with timestamps.
Follow include and redirect paths in evaluation order.
Record which query name and type produced each empty response.
Confirm whether the associated sender is still authorised and active.
Test the proposed change against every legitimate sending route before publishing.

Safe remediation

Remove obsolete authorisations, correct misspelled or retired provider names, or adopt the provider's current supported record. Do not replace includes with copied IP addresses unless the provider explicitly supports that maintenance model. Preserve the prior value and TTL for rollback.

What this site can verify

The local SPF Record Checker inspects pasted text and flags lookup-causing mechanisms, but it deliberately performs no live DNS resolution. Confirm real void results with an authorised DNS tool and received-message evidence. The technical definition is in RFC 7208 section 4.6.4.

Authoritative references

Read the underlying standards and provider instructions before changing production DNS: RFC 7208 (SPF), RFC 9989 (DMARC), Google Workspace SPF guidance and your sending provider's current DKIM documentation.

Editorial responsibility

Published by Acerville Sparks Limited. Software assists research, drafting and automated record testing. Internet standards, provider documentation, reproducible checks and limitations are shown so readers can inspect the work. No independent deliverability consultant review is claimed. Reviewed 4 September 2026.

What this site does not do

No inbox guarantee. No live DNS checks. No storage of entered data. No passwords or private keys requested.