SPF Void Lookup Limit: Fix the PermError

Your SPF can be under 10 lookups and still fail

A domain can have nine SPF DNS lookups, look clean in a quick count, and still return permerror at a receiver that enforces the SPF void lookup limit.

A void lookup is a DNS lookup that gives SPF no usable answer. RFC 7208 names two cases: the lookup returns a positive DNS response with zero answers, or the lookup returns a Name Error, also called NXDOMAIN. In plain terms, SPF asked DNS a question and got nothing it could use.

RFC 7208 says SPF implementations should limit void lookups to two, and a default of two is recommended when the limit is configurable. When an implementation enforces that limit, going over it produces permerror. That can hurt delivery because Gmail, Outlook, and other mailbox providers use authentication results along with reputation, complaints, content, and engagement when they decide whether mail reaches the inbox.

This is separate from the better-known 10 DNS lookup limit. The 10-limit applies during SPF evaluation to DNS-causing terms: include, a, mx, ptr, exists, and the redirect modifier. Nested includes count too. The SPF TXT lookup for the original domain does not count toward that 10-term limit.

What usually causes SPF void lookups

Void lookups usually come from old vendor records, broad mechanisms, or hostnames that were once real and later disappeared.

• include:vendor.example points to a name that returns NXDOMAIN or no TXT answer.
• a:mail.example.com points to a host with no usable A or AAAA answer for the check being made.
• mx asks for MX records, but the domain has no MX answer, or its MX hostnames have no usable address records.
• exists:%{i}._spf.example.com expands to names that often return NXDOMAIN.
• ptr creates reverse DNS work and is marked "do not use" in RFC 7208.
• redirect=_spf.oldvendor.example points to a dead or moved SPF policy.

Be careful with one common trap: a referenced domain can have TXT records but no TXT record that starts with v=spf1. That is still a bad include or redirect, and it can produce permerror, but it is not always a void lookup. Void means the DNS query itself came back empty or NXDOMAIN.

The fix is to test each DNS-causing term from left to right, using the same domain that appears in your SPF record. If a term returns NXDOMAIN or an empty answer, remove it or replace it with the current value from that sender. Do not add another include to hide the error. That usually raises both the total lookup count and the chance of more void answers.

Keep one SPF TXT record at the sending domain. Multiple SPF records at the same name are another permerror. Use ip4 and ip6 for stable sending IPs because they do not spend DNS lookups during SPF evaluation. End the record with ~all while you are still checking all senders. Use -all after every real sender is covered and passing.

A safe repair plan

Treat a void lookup permerror as a broken dependency list. Your goal is a shorter SPF record that names only current senders.

• Start with the domain in the bounce, header, or DMARC report. For SPF, that is usually the Return-Path or envelope sender domain.
• Find the single TXT record that starts with v=spf1.
• List every include, a, mx, exists, ptr, and redirect term, including terms inside nested includes.
• Check each term for a real DNS answer. Mark NXDOMAIN and empty-answer results as void lookups.
• Remove vendors you no longer use. Replace renamed vendor domains with the exact value from their current docs.
• Flatten only stable IP ranges. Do not flatten cloud services that change IPs often unless the provider tells you to publish those IPs directly.
• Publish the shorter SPF record and retest from public DNS after the TTL has passed.

After SPF is clean, check the rest of the mail path. DKIM should sign mail with selectors that exist in DNS, usually under selector._domainkey.yourdomain, and with keys and algorithms accepted by the mailbox providers you send to. DMARC should live at _dmarc.yourdomain. Start with p=none while you review reports, then move to quarantine or reject after every real sender passes DMARC through aligned SPF or aligned DKIM. Add a rua address so you can see who is sending as your domain.

Also confirm MX and reverse DNS where they apply. MX records control where you receive mail. Reverse DNS and matching forward DNS matter most for the IPs that send your mail. Blocklists can matter too, but fix authentication first. A listed IP with broken SPF, DKIM, and DMARC gives filters too many reasons to distrust the message.

How this affects Gmail and Outlook placement

A void lookup permerror tells a receiver that your SPF policy could not be read cleanly.

Mailbox providers do not publish a simple rule that says one SPF permerror always sends mail to spam. They combine authentication, domain reputation, IP reputation, user complaints, message content, list quality, and past engagement. Still, a permanent SPF error is a real negative signal because the receiver cannot confirm that the sending IP is allowed by your policy.

Google's sender guidelines require SPF or DKIM for all senders, and SPF, DKIM, and DMARC for bulk senders. Google also recommends DMARC reporting and aligned domains for DMARC. Microsoft explains the same split between the SMTP envelope sender used by SPF and the visible From address users see. That is why modern deliverability needs SPF, DKIM, and DMARC working together.

You can check your live SPF, DKIM, DMARC, MX, and blocklist status with the free InboxRadar domain scorecard. Use it as a quick outside view after each DNS change, then keep your own notes on which systems are allowed to send. For more background, see the related deliverability guides.