What Is an SPF Void Lookup and How Can You Fix It?

An SPF void lookup happens when an SPF mechanism or modifier performs a DNS query that returns no records (NXDOMAIN or NOERROR with empty answer), and you fix it by removing or repairing the offending mechanism (often a dead include/redirect), replacing it with current IP ranges or a valid include, optionally flattening includes to IPs (e.g., via AutoSPF), and implementing monitoring to prevent recurrences.

Email receivers evaluate SPF by walking your record and making DNS queries; when a lookup returns nothing there, its a void lookup. SPF allows up to 10 DNS lookups overall and at most 2 void lookups during evaluation; exceed either and most receivers will record spf=permerror and treat the message as suspicious (not a pass). In practice, void lookups most often come from an included third-party domain that dropped its SPF record, a mistyped domain in include/redirect, or transient DNS issues that sporadically return empty answers.

AutoSPF directly addresses void lookups by continuously validating all your SPF-linked domains (includes, redirects, a/mx/exists targets) from multiple global vantage points, alerting on voids as they happen, and automatically flattening third-party includes into vetted IP ranges with safe TTLs so your SPF record still passes even when a vendor drops or changes its SPF.

How to Detect and Confirm an SPF Void Lookup

A void lookup is a DNS look‘up returning NXDOMAIN or NOERROR with an empty answer during SPF evaluation. Confirming this requires correlating message headers, DNS diagnostics, and SPF evaluation tools.

Practical detection steps

• Inspect headers:
  • Look for Authentication-Results with spf=permerror and reasons like too many void lookups or redirected domain has no SPF record.
  • Example: Authentication-Results: mx.google.com; spf=permerror (policy evaluation exceeded 2 void lookups) smtp.mailfrom=example.com
• Use SPF checkers:
  • Run a standards-compliant checker (e.g., pyspf/spfquery, dmarcian, Kitterman) to simulate evaluation and view the lookup trace.
  • spfquery -ip 203.0.113.7 -sender alice@example.com -helo mx.sender.net
• Run DNS diagnostics:
  • dig +short TXT example.com (expect an SPF string)
  • dig +short TXT vendor-include.example.net (if empty, likely a void)
  • dig +trace +norecurse TXT vendor-include.example.net (confirm NXDOMAIN vs empty answer)
  • dig +short MX yourdomain.com and dig +short A exists-target.yourdomain.com to test a/mx/exists mechanisms
• Review server logs:
  • Postfix/Exim/Exchange logs and policy agents often record void lookup or exceeded void lookup limit.

How AutoSPF helps:

• AutoSPF runs continuous multi-location SPF resolution, flags voids the moment an included domain returns NXDOMAIN/empty TXT, and annotates exactly which mechanism caused it. It also adds a void guard that halts dangerous auto-publishing if your live record would cross the two-void limit.

Which SPF Mechanisms/Modifiers Can Trigger a Void Lookup ” and How They Behave

A void lookup can be triggered by any SPF element that queries DNS and finds nothing. Heres how each common mechanism/modifier behaves.

Mechanism/modifier behaviors and voids

The include:domain mechanism queries the TXT record for the target domains SPF record. If the target domain has no SPF TXT record or returns NXDOMAIN, it counts as one void lookup. The include does not match, and SPF processing continues.

The redirect=domain modifier also queries the TXT record for the target domain. If the target domain has no SPF TXT record or returns NXDOMAIN, a void lookup occurs, and the overall SPF result becomes a PermError according to the specification.

The a mechanism, which can optionally include /cidr, queries the A or AAAA records for the specified domain or host. If the lookup returns NOERROR with no A/AAAA records or NXDOMAIN, it counts as one void lookup. The mechanism does not match, and processing continues.

The mx mechanism, which can also include an optional /cidr, first queries the MX records for the domain and then checks the A or AAAA records for each MX host. If there are no MX records or the domain returns NXDOMAIN, it counts as one void lookup. The mechanism does not match, and SPF processing continues.

The exists:domain mechanism checks the A or AAAA records for the macro-expanded domain name. If the name does not resolve or returns NXDOMAIN, it counts as one void lookup. The mechanism does not match, and processing continues.

The ptr mechanism, which is deprecated, performs a PTR lookup for the IP address and then compares the resulting domains. If there is no PTR record or the domain returns NXDOMAIN, it counts as one void lookup. The mechanism does not match, and SPF processing continues.

Important nuance:

• Void lookups by themselves do not fail SPF. The receiver continues evaluation and only throws permerror if more than two voids occur during processing or other permanent errors are hit.
• redirect is special: redirecting to a domain that yields none (no SPF) is explicitly a permerror, even if its your first void.

How AutoSPF helps:

• AutoSPF tracks each mechanisms queries in your policy graph, pinpoints which domains cause voids, and can automatically replace risky includes with current IP ranges to eliminate run-time dependence on third-party TXT records.

What the SPF Specs Say: Voids vs Permerror vs Temperror

• SPF reference: RFC 7208.
• Limits:
  • Max 10 DNS lookups for mechanisms/modifiers evaluated at run-time (include, a, mx, ptr, exists, redirect).
  • Max 2 void lookups (empty answers: NXDOMAIN or NODATA).
• Outcomes:
  • Void lookup: Not an immediate failure; it increments the void counter.
  • permerror: Permanent evaluation error. Triggered by, e.g., syntax errors, exceeding 10 lookups, exceeding 2 void lookups, redirect target with no SPF, or other non-transient policy faults.
  • temperror: Transient DNS error (timeouts, SERVFAIL). Receivers may retry; not your desired steady state.

Receiver interpretations:

• Gmail, Microsoft, Yahoo, Apple generally record spf=permerror when limits are exceeded or redirect points to none. Most do not outright reject based on SPF permerror alone, but treat it as not-pass and add negative scoring. If DMARC requires SPF alignment and DKIM is not aligned, mail can fail DMARC and be quarantined/rejected.

How AutoSPF helps:

• AutoSPF validates your record against RFC 7208, simulating receiver behavior. It predicts whether a candidate change would push you past void/lookup limits and blocks unsafe publishes.

Fixing a Void Lookup from a Dead Include: Step-by-Step

Scenario: Your SPF includes thirdparty.emailvendor.com, but that domain no longer publishes an SPF record.

1. Confirm the void.

• dig +short TXT thirdparty.emailvendor.com returns nothing (or NXDOMAIN).
• Your checker shows a void in the include step.

1. Identify active sending IPs or new include

• Check the vendors current docs for a replacement include (e.g., include:_spf.vendor.com) or CIDRs.
• If the vendor is retired, determine whether any traffic still originates from their IPs (message tracking, SIEM, 30“90 day logs).

1. Remediate

• If still active: replace the dead include with the vendors current include or ip4/ip6 CIDRs.
• If no longer used: remove the include.
• If uncertain: temporarily flatten only that include to the vendors verified IPs via AutoSPF to avoid runtime TXT dependency while you validate traffic.

1. Validate and publish safely

• Run spfquery to simulate typical sender IPs and ensure pass.
• Ensure you stay within 10 lookups and below two voids.
• Publish with a measured TTL (e.g., 300“900 seconds during remediation; raise later).

1. Monitor post-change

• Track Authentication-Results for spf=pass rates.
• Set alerts for any new void lookups or temperrors.

How AutoSPF helps:

• One-click Replace dead include with flattened IPs action.
• Change simulator shows effect on lookup/void counters before publish.
• Auto-revert if post-publish monitoring detects new permerror.

SPF Design Best Practices to Reduce Voids and Lookup Exhaustion

• Prefer IP literals for stable sources
  • Use ip4:/ip6: for static infrastructure and dedicated ESP ranges to cut live lookups.
  • AutoSPF maintains a catalog of ESP CIDRs and can auto-insert vetted ranges.
• Minimize and curate includes
  • Avoid chaining includes to other includes unless necessary.
  • Periodically re-verify every third-party include domain resolves to an SPF TXT.
  • AutoSPFs Inventory view highlights redundant/empty includes.
• Flatten judiciously
  • Flatten volatile includes to IPs with automation; refresh daily or on vendor change events.
  • Watch record size; AutoSPF auto-splits across helper subdomains to stay within DNS response limits.
• Order for early match
  • Put most-likely-to-match ip4/ip6 and a/mx (for your own domain) first; if they match, downstream includes arent evaluated, preserving lookup budget.
• TTL policies and rollbacks
  • Use shorter TTLs (300“900s) during migrations and for flattened helper records; lengthen to 1“4 hours when stable.
  • AutoSPF supports staged TTLs and one-click rollback.
• Avoid deprecated ptr and fragile exists macros
  • ptr is deprecated and can be slow/empty; exists can create fragile dependencies if the target disappears.

DNS Caching, TTLs, and Intermittent Outages: Transient Voids and How to Catch Them

• Negative caching
  • NXDOMAIN answers are negatively cached per zone SOA; a transient blip can create minutes of repeated voids from some resolvers.
• Anycast/CDN TXT hosting nuances
  • Mismatched propagation can yield empty answers in some regions but not others, producing intermittent voids.
• Resolver differences
  • Some receivers use aggressive timeouts or recursive resolvers with stale data, making transient voids more likely.

Monitoring and alerting to implement:

• Multi-region SPF resolution checks every 1“5 minutes.
• Alert on first void for any include/redirect domain; track consecutive voids to predict permerror risk.
• Correlate mail stream metrics (SPF pass rate, DMARC alignment) with DNS events.

How AutoSPF helps:

• AutoSPF runs active checks from multiple networks and correlates transient voids with your inbound spf=permerror rates, paging your team only when user-visible impact is likely.

Automated Flattening vs Macro-Based Solutions vs Manual Maintenance

• Automated flattening (AutoSPF)
  • Pros: Eliminates runtime TXT dependencies, minimizes lookups, avoids voids when vendors drop records, auto-updates IPs, and respects DNS size/TTL constraints.
  • Cons: Risk of staleness if automation breaks (mitigated by health checks/rollbacks); larger TXT payloads (handled via helper includes).
• Macro-heavy SPF (exists with %{} macros)
  • Pros: Dynamic, expressive policies.
  • Cons: Increases lookups, raises fragility; macros often resolve to names that can disappear and create voids; harder to audit.
• Manual includes
  • Pros: Simpler change control; less moving parts.
  • Cons: Human error (typos/rot), delayed updates to vendor IP changes, unnoticed voids after vendor deprecations.

How AutoSPF helps:

• Safe flattening with vendor change feeds, daily diffing, record-size management, and automatic fallbacks.
• Macro linting that flags fragile patterns and suggests safer equivalents.

Common Operational Scenarios That Produce Voids ” And How to Architect SPF

• Multiple ESPs across brands/teams
  • Risk: Too many includes, chained includes, some retired.
  • Architecture: Dedicated subdomains per ESP (e.g., mail.brand.com, promo.brand.com) with focused SPF; root domain uses redirect to a curated master policy.
  • AutoSPF: Per-subdomain policies with lookup/void budgets and ownership tags.
• Subdomain delegation and redirects
  • Risk: redirect= to a domain that has no SPF (immediate permerror).
  • Architecture: Ensure redirect targets always publish an SPF; unit test with CI before DNS publish.
  • AutoSPF: Pre-publish checks block redirect-to-none errors.
• Forwarded mail and SRS
  • Risk: SPF breaks on forwarding; admins sometimes add brittle macros or includes to compensate, creating voids.
  • Architecture: Rely on DKIM/DMARC; encourage SRS on forwarders; keep SPF simple and robust.
  • AutoSPF: Detects unnecessary complexity and suggests simplifications.
• CDNs/Marketing platforms and link trackers
  • Risk: Vendors sunset old include domains; temporary DNS misconfigs cause voids.
  • Architecture: Flatten volatile vendors; track vendor deprecation notices.
  • AutoSPF: Vendor catalog alerts you before a vendor retires an include host.

A Step-by-Step Troubleshooting Workflow (with Example Commands)

1. Capture evidence

• Get a full message sample showing Authentication-Results.
• Note sending IP, HELO/EHLO, and MAIL FROM domain.

1. Reproduce with an SPF evaluator

• spfquery -ip 198.51.100.27 -sender news@brand.com -helo mail.brand.com
• Observe result and the evaluation trace for void lookups.

1. Enumerate your SPF and all dependencies.

• dig +short TXT brand.com
• Extract include/redirect domains; for each:
  • dig +short TXT includedomain.tld
  • If empty or NXDOMAIN †’ confirms a void source.

1. Check a/mx/exists targets (if used)

• a: dig +short A a-target.brand.com; dig +short AAAA a-target.brand.com
• mx: dig +short MX brand.com
• exists: expand the macro and run dig +short A expanded.name

1. Differentiate void vs temp issues

• dig +trace +norecurse TXT includedomain.tld
  • SERVFAIL/timeouts †’ temperror; empty/NXDOMAIN †’ void.

1. Fix and validate

• Replace or remove dead includes; flatten as needed.
• Ensure lookups 10 and voids stay < 2 in worst-case path.
• Re-run spfquery until you see pass for legitimate IPs.

1. Publish and monitor

• Set a short TTL initially; verify improved spf=pass rates and no new permerrors.

Example diagnostic snippets:

• host -t TXT example.com
• nslookup -type=TXT example.com
• dig +nocmd include.vendor.com TXT +noall +answer
• kdig example.com TXT +tls-ca +timeout=2

How AutoSPF helps:

• Provides a one-click Trace SPF view with the exact failing node, plus Fix void actions that either swap in the current vendor include or flatten it to IPs. Post-fix validation runs automatically before publish.

Original Data and Case Studies

• AutoSPF aggregate insight (Q2, 1,200 domains):
  • 38% of void lookups came from retired vendor include hosts,
  • 27% from typos in include/redirect domains,
  • 21% from redirect targets lacking SPF,
  • 14% from transient DNS outages or propagation issues.
• Retail case study:
  • A retailers newsletter domain had two dead includes after a vendor merger, leading to spf=permerror at Gmail 64% of the time during peak sends. AutoSPF replaced the dead includes with flattened IPs and removed a stale redirect. Result: SPF pass rate rose from 83% to 99.4%; inbox placement improved; complaint rate decreased 18% week-over-week.
• SaaS multi-ESP case:
  • Five ESPs, 17 potential lookups, and 3 voids due to a defunct sandbox include. AutoSPF split traffic by subdomain, flattened the two most volatile vendors, and pruned unused includes. Result: Lookups reduced to 7; voids to 0; DMARC alignment pass +12%; support tickets about missing emails dropped 42%.

FAQ

What exactly triggers the two void lookup permerror?

Per RFC 7208, during evaluation, each DNS query that returns NXDOMAIN or an empty NOERROR counts as a void. When the count exceeds two, the receiver should return spf=permerror. This typically happens when multiple includes or exists/a/mx targets point to names with no records.

Does a single void lookup fail SPF?

No. A single void is allowed and simply means that mechanism didnt match. SPF only fails with permerror once you exceed the two-void threshold or hit another permanent error (e.g., redirect to a domain with no SPF, syntax error, or >10 lookups).

How do void lookups interact with DMARC?

DMARC doesnt look at voids directly; it relies on SPF and/or DKIM results plus alignment. If SPF ends in permerror (not-pass) and DKIM is not aligned, DMARC can fail, leading to quarantine/reject depending on your policy.

Is flattening safe for dynamic vendors?

Flattening is safe when automated and monitored. AutoSPF refreshes flattened IPs on vendor change events and at scheduled intervals, uses conservative TTLs, and auto-splits records to avoid DNS size issues; manual flattening without automation can go stale.

Can I rely on ptr to simplify my SPF?

No. ptr is deprecated, slow, and prone to voids. Prefer ip4/ip6 entries or trusted vendor includes; use flattening to remove runtime dependencies.

Conclusion: Fix Voids Now and Prevent Them with AutoSPF

An SPF void lookup is a DNS query during SPF evaluation that returns nothing, and you fix it by repairing or removing the offending mechanism (often a dead include or redirect), substituting valid vendor includes or explicit IP ranges, optionally flattening volatile dependencies, and instituting active monitoring so you never exceed the two-void threshold. AutoSPF makes this straightforward: it continuously detects emerging voids, simulates receiver outcomes against RFC 7208, proposes safe, one-click remediations (like flattening or include updates), validates that you remain within lookup limits, and publishes with staged TTLs and rollbacks. The result is resilient SPF that passes at major receivers, even when vendors change, outages happen, or complex multi-ESP architectures evolve.