SPF record null value

"SPF Record Null Value" is a diagnostic label used by SPF checkers like MXToolbox — it is not a reply code defined in any RFC. It means that while evaluating your SPF record, a mechanism that requires a DNS lookup (typically an include:, a, mx, or exists: term) returned no records — what RFC 7208 calls a void lookup.

What causes an SPF Record Null Value?

There are two distinct situations that get reported under this label, and they need different fixes:

1. A referenced mechanism resolves to nothing (the common case). Your record points at a domain that no longer publishes the expected records. Per RFC 7208 §4.6.4, a void lookup is a DNS query that returns either a positive answer with zero answer records (RCODE 0, 0 answers) or a Name Error (RCODE 3 / NXDOMAIN). For example, a:mail.example.com or mx pointing at a host with no A/MX record.

For a, mx, exists:, and ptr mechanisms, a single void lookup does not by itself fail SPF. RFC 7208 §5 says a mechanism whose query returns Name Error "continues as if the server returned no error and zero answer records" — i.e., it simply does not match, and evaluation moves on. The checker still flags it because, as MXToolbox notes, a null result "is commonly an indication of a problem with the related DNS lookup" rather than something intentional.

include: is a different, higher-severity case. If include:_spf.vendor.com is flagged as a null value, don't assume it's a harmless non-match. RFC 7208 §5.2's result table maps a recursive check_host() result of none (the included domain has no SPF record at all) directly to the include mechanism returning PermError — not a silent skip. In practice, MXToolbox's own diagnostic for this case reports it plainly as "A null DNS lookup was found for include," and it is the most common real-world trigger of this label. So a null include: is more likely to actually break your SPF record's evaluation than a null a:/mx:/exists: term — treat it with higher urgency and fix it immediately rather than assuming evaluation will just move past it.

2. A literal invalid token in the record. Less often, someone has written something like v=spf1 null -all, where null is not a valid SPF mechanism or modifier. This is a true syntax error and produces a PermError (RFC 7208 §2.6.7, "the domain's published records could not be correctly interpreted"), which fails the whole record.

How do I fix an SPF Record Null Value?

1. Run a full SPF check (MXToolbox SPF Record Lookup or dig +short TXT yourdomain.com) and identify the exact term flagged as null.
2. Resolve the referenced name directly. For an a/mx/exists: term, query the target — e.g. dig +short A mail.example.com. For an include: term, check whether the included domain publishes any SPF record at all — e.g. dig +short TXT _spf.vendor.com. An empty result confirms the void lookup; for include:, this specifically means the included domain's SPF result is "none," which pushes your record toward PermError.
3. Correct or remove the dead term. If the vendor changed their include domain, update it to the current value from their docs. If the service is no longer used, delete the mechanism. If it was a typo (e.g. a literal null), replace it with a valid mechanism such as ip4:, ip6:, or include:.
4. Watch the void-lookup budget. RFC 7208 §4.6.4: implementations SHOULD limit void lookups to two by default (this is a configurable recommendation, not a hard protocol ceiling). A third void lookup can tip the record into PermError under a typical validator's default configuration, so clean these up rather than ignoring them.
5. Keep the structure valid. The record must begin with exactly v=spf1 (RFC 7208 §4.5). Best practice — though not a strict RFC requirement — is to end the record with an all mechanism (e.g. -all) so the policy is unambiguous; RFC 7208 §4.7 recommends this to explicitly terminate evaluation, for example:

v=spf1 include:_spf.google.com ip4:198.51.100.10 -all

If the lookup returns no record at all (rather than a null mechanism inside one), that is a different result — SPF "None" (RFC 7208 §2.6.1), meaning publish an SPF record in the first place.