SPF Void Lookups: Why Your SPF Quietly Fails at Gmail

A void lookup is what RFC 7208 §4.6.4 calls a DNS query that returns either NXDOMAIN (the name does not exist) or an empty answer (the name exists but has no record of the requested type). When a mail server evaluates your SPF record and hits an `include:` mechanism that points at a domain that no longer publishes an SPF record — because the vendor renamed the include, retired the product, or shut the service down — that query returns NXDOMAIN, and the receiver counts it as a void lookup.

The RFC says, in plain language, that an SPF evaluator SHOULD treat the policy as a permanent error after the second void lookup. The word 'SHOULD' is the lawyer-speak version of 'do this unless you have a really good reason not to' — and the major mailbox providers have decided they have no reason not to. Gmail, Microsoft 365, and Yahoo all enforce the 2-void-lookup limit in production today. Your SPF record can be 100% within the 10-mechanism MUST limit, syntactically perfect, end in `-all`, and still PermError at Gmail because the third include in your record points at a dead vendor.

The practical effect is identical to busting the 10-lookup limit: receivers throw away the SPF result entirely. Your DMARC alignment then has to rely solely on DKIM. If DKIM is also missing, broken, or unaligned — which is depressingly common — your mail lands in spam or gets rejected outright.

DMARCguard's 2026 SPF Supply Chain Study scanned 5.5 million domains and found that 4.8% of SPF-enabled domains exceed the 10-mechanism limit. The void-lookup limit is even less-monitored, but the underlying failure mode — a stale include left behind after a vendor migration — is so common that most production SPF records have at least one dead include just waiting to start counting against the limit.

The scenario typically goes like this: a marketing team adopts a new email tool, adds `include:_spf.newvendor.com` to the SPF record. Six months later, the project ends, the team decommissions the vendor account, but nobody removes the include. A year later, the vendor renames `_spf.newvendor.com` to `_spf.newvendor.io` and lets the old name expire. Now every email your domain sends triggers an NXDOMAIN against the old include. One stale vendor is fine — the record still has one void lookup of headroom. Two? Now you are in PermError territory.

The other version is even sneakier: vendor consolidation. Mailchimp, Mandrill, and Mailgun have all gone through corporate restructurings that left old include hostnames pointing at deprecated zones. If your SPF record references one of those, the include resolved fine when you wrote it down — and started returning NXDOMAIN months later without anyone noticing.

The takeaway is simple: void lookups are an entropy problem. Every SPF record drifts toward failure as the vendor landscape shifts. The only defence is to count them.

EdgeDNS's SPF check endpoint returns a `void_lookup_count` field for every domain. The check recursively expands every `include:`, every `redirect=`, and every `a` / `mx` / `exists` mechanism, counts the void responses along the way, and surfaces the total alongside an `exceeds_void_limit` boolean.

From the command line:

If `void_lookup_count` comes back as 1, you still have headroom — but you are one stale-vendor change away from PermError. If it comes back as 2, you are at the limit. If it comes back as 3+, your SPF is already broken at the major mailbox providers.

The fix is always the same: identify which include is voiding and either remove it (if the vendor is decommissioned) or update it (if the vendor renamed). The companion SPF Trust Surface endpoint returns a `flattening_recommendations` array sorted by lookup cost, with each entry tagged `remove` (zero IPs authorized — likely dead), `flatten_inline` (low IP count, cheap to replace with literal `ip4:` mechanisms), or `keep` (large vendor where flattening introduces fragility).

The walkthrough is:

1. Run `/v1/security/spf-trust-surface?domain=yourdomain.com`. 2. Look for entries with `recommendation: 'remove'`. Those are almost always the void-lookup culprits. 3. Cross-reference with your actual vendor list. Anything you cannot map to an active service gets dropped. 4. Re-run `/v1/security/spf` and confirm `void_lookup_count` is back to zero.

Most teams find at least one stale include on the first pass. Some find half a dozen.

The same expansion that counts void lookups also counts the unique IPs your SPF record authorises. The `authorized_ipv4_count` and `authorized_ipv6_count` fields tell you exactly how many IP addresses are cryptographically allowed to send mail as your domain after every include is resolved.

For a typical Google Workspace + Mailchimp + Salesforce setup, this number is in the thousands. For a serious enterprise stack with five or six marketing tools, ten thousand is not unusual. The number is mostly informational — but it tells you something important: every one of those IPs is a potential pivot if the vendor running it is compromised. The SPF trust surface is your delegated-trust perimeter; the IP count is its size.

Security teams use this number as a vendor-rationalisation signal. If you have ten thousand authorised IPs and 80% of your real mail comes from two senders, the other 20% of senders are buying you a perimeter you do not need.

SPF flattening — replacing `include:` mechanisms with the literal IP addresses they resolve to — is the standard fix for the 10-lookup limit, and it is also a valid void-lookup fix. But flattening is not free. Once you flatten an include, you are responsible for keeping the IP list in sync with the vendor. If Mailchimp adds a new sending IP range and you flattened their include three months ago, your mail from the new range will fail SPF until you update.

The trade-off matrix that works in practice:

• Flatten low-volume vendors with stable IP ranges. Postmark, Mailjet, Amazon SES regional endpoints — all good candidates. The IP lists are small and rarely change.

• Keep includes for large vendors with dynamic infrastructure. Google Workspace and Microsoft 365 add and remove IPs regularly; you do not want to chase their netblocks.

• Always remove dead vendors entirely. If a vendor's include resolves to NXDOMAIN, the only correct action is removal. Flattening it preserves a perimeter you are not even using.

The flattening_recommendations field on the SPF Trust Surface endpoint gives you per-include guidance ranked by lookup cost. The top entry is the most impactful change you can make.

Void lookups are an entropy problem, which means a one-time audit is not enough — you need to re-check periodically. The recommended cadence is:

• Quarterly: run an SPF Trust Surface audit and prune dead includes. Calendar this.

• After every vendor change: add a manual SPF check to your vendor offboarding runbook. The moment you cancel a marketing tool, the include should come out of DNS.

• Before a major campaign: spot-check `/v1/security/spf` and confirm `void_lookup_count: 0` and `exceeds_dns_limit: false`. Sixty seconds of work that has saved real campaigns.

The automated version is to run the SPF check as a cron job from a monitoring tool, alerting when `void_lookup_count > 0` or `exceeds_dns_limit` flips to true. Both are early-warning signals — the policy is still being honoured today, but you are one vendor change away from PermError.

SPF (Sender Policy Framework) — the DNS-published list of servers allowed to send mail as your domain.

DMARC — the policy layer that tells receivers what to do when SPF or DKIM fails.

PermError — RFC 7208's term for 'this SPF record is unusable; ignore it'. Caused by syntax errors, exceeding 10 lookups, or — as covered here — exceeding 2 void lookups.

Void lookup — an SPF-evaluation DNS query that returns NXDOMAIN or an empty answer. Limited to 2 per evaluation by RFC 7208 §4.6.4.

Flattening — replacing an `include:` mechanism with the literal IP addresses it resolves to. Trades DNS lookups for maintenance burden.

Trust surface — the full set of IPs and vendors authorised to send mail as your domain after every include is resolved.