An SPF result of neutral or none does not authenticate the sending host. Both outcomes can coexist with a delivered message, so delivery alone is a poor diagnostic. The practical job is to identify why the evaluator reached that result and whether it is expected for the identity actually used.
Distinguish absence from an explicit non-assertion
RFC 7208 §2.6.1 defines none as an outcome where no usable domain identity can be extracted from the SMTP session or no SPF record is retrieved. Under RFC 7208 §2.6.2, neutral means the domain is not asserting whether the IP is authorised. A record ending in ?all can produce neutral for a source that did not match an earlier mechanism. A valid record that reaches its end without a match or redirect also has an implicit neutral default under RFC 7208 §4.7.
This is different from pass. Pass explicitly authorises the connecting host for the evaluated identity. Neutral does not mean “probably authorised”, and none does not mean “safe because there is no prohibition”. RFC 7208 §8.2 requires neutral to be treated like none for handling purposes, but keeping the two labels separate is useful for diagnosing the configuration.
Start with the observed identity
Read receiver-generated authentication results from a system you trust. Record whether the check used MAIL FROM or HELO, the domain evaluated and the connecting IP. Do not accept an arbitrary sender-supplied Authentication-Results line as authoritative evidence.
A common investigation error is to query the visible From domain while the message uses a different envelope domain. A valid SPF record on example.com says nothing by itself about the record returned for bounce.example.com. Another error is to query only a registrar's editor rather than the authoritative servers actually serving the name.
For a none result, inspect the exact queried name and TXT answer. Check whether a v=spf1 record exists there, whether the message used the intended envelope identity, and whether the recorded check occurred before a recent DNS change. A current DNS lookup cannot recreate historical DNS state by itself.
Do not merge error states into none
Under RFC 7208 §4.5, two selected SPF records produce permerror, not a harmless absence of policy. A temporary DNS failure can produce temperror. Those conditions need their own investigation paths. A dashboard that groups all non-pass outcomes under “missing SPF” can send an administrator toward the wrong repair.
For neutral, examine the policy in order. Was a question-mark qualifier intentional? Did an unmatched message reach the end of a record lacking an effective final mechanism? If the domain delegates policy through redirect, inspect the target and the resulting evaluation rather than assuming the top-level text is the whole policy.
Use a small diagnostic matrix
The following are synthetic expectations, not production configuration advice:
v=spf1 ip4:192.0.2.10 ?all, evaluated for 192.0.2.10: pass.- The same record, evaluated for 198.51.100.20: neutral.
v=spf1 ip4:192.0.2.10, evaluated for 198.51.100.20: neutral through the default result.- No SPF TXT record at an otherwise valid evaluated name: none, assuming the lookup completes without a different error.
The documentation-only IP addresses distinguish policy logic from a live tenant test. Repeat equivalent tests with your authorised sources in a controlled environment, then compare real receiver evidence.
Repair only the demonstrated cause
If the intended envelope domain lacks a record, design a policy for its actual senders. If neutral is intentional, document why. If a record accidentally falls through, decide the intended final statement after checking legitimate paths. Do not replace neutral with universal pass through +all: when reached, that grants pass rather than fixing the inventory. Earlier matches or errors can still determine a result.
Close the investigation with the original observation, the identified cause, the approved change if any, and a fresh message result. A DNS screenshot is evidence of publication; a received-message result is evidence of a particular evaluation. Keep both when the business depends on the route.
Use the evidence for a decision
Keep one row for identity/IP/time, exact result, policy snapshot and cause. A completed lookup with no selected SPF record is not the same as a timeout or multiple selected records. If a dashboard combines them, use its underlying evidence before changing DNS. The synthetic neutral cases demonstrate control flow, not authentication success or delivery assurance.