What does an SPF check result actually mean?

SPF is a set of outcomes, not a single answer

Unlike a simple yes/no check, RFC 7208 defines SPF evaluation as producing one of seven named results: Pass, Fail, SoftFail, Neutral, None, PermError and TempError. AdminKit’s SPF check parses your domain’s SPF record with its own code, walks every mechanism in it, and reports which of these outcomes your current record would actually produce — along with the specific reason, rather than a bare label. Knowing which result you’re looking at, and why, matters more than just seeing “it looks fine,” because several of these results look superficially similar but mean very different things to a receiving mail server.

Pass: the sending IP is authorized

A Pass means the connecting server’s IP matched one of the mechanisms in your SPF record — an ip4, ip6, a, mx, include, or exists mechanism resolved to include that address. This is the result every legitimate sending source should produce. It’s worth being precise about what Pass actually verifies: it confirms the IP is authorized to send for the domain used in the SMTP envelope (the “return-path” or “mail from” domain), not the domain shown in the message’s visible From: header a recipient sees — those can differ, which is exactly the gap DMARC’s alignment check exists to close.

Fail and SoftFail: two different strengths of “not authorized”

Both results mean the sending IP didn’t match anything in the record, but the SPF record’s own trailing all mechanism decides which one gets returned, via its qualifier. Fail (-all) is defined in RFC 7208 §4.6.2 as “an explicit statement that the client is not authorized to use the domain” — the strongest signal SPF can send, and many receivers reject or heavily penalize mail that fails this way. SoftFail (~all) is explicitly described as only “a weak statement,” meant to flag a message as suspicious (commonly routed to spam) without outright rejecting it — useful while a domain owner is still confirming every legitimate sending source is listed, before committing to a hard -all.

Neutral and None: SPF isn’t asserting anything

Neutral results from an explicit ?all qualifier, and is defined as the domain owner stating it has no opinion on whether the connecting host is authorized. None is different: it means no SPF record exists for the domain being checked at all, rather than one that exists but declines to assert anything. In practice, both results give a receiver nothing to act on — mail is evaluated as if SPF weren’t a factor either way. If a domain’s default all mechanism is left off entirely (no all term at all), evaluation falls through to Neutral behavior by default.

PermError: the record itself is broken

A PermError is categorically different from the results above — it means SPF evaluation could not be completed correctly because of a problem with the record’s configuration, not because of anything specific to the sending IP. The two most common causes: more than one SPF-type TXT record published at the same name (RFC 7208 §4.5 treats this as an automatic PermError, since a receiver can’t know which one to trust), and exceeding the hard limit of 10 DNS lookups during evaluation, set by RFC 7208 §4.6.4. A PermError is often treated as badly as a hard Fail by receivers — see fixing SPF “too many DNS lookups” (PermError) for how the lookup limit gets exceeded and how to fix it.

TempError: a temporary evaluation problem

A TempError means something transient went wrong during evaluation — typically a DNS query that timed out or returned a server failure — rather than anything wrong with the record’s actual content. RFC 7208 treats this as inconclusive, and most receivers retry the message later or temporarily defer it rather than rejecting outright. A TempError that appears once and doesn’t recur usually isn’t worth investigating; one that persists across repeated checks points to a DNS resolution problem independent of the SPF record’s syntax.

Reading your own result

Run AdminKit’s SPF check against your domain to see which of these seven outcomes your current record produces, along with the specific mechanism and qualifier responsible. If the result is Pass with a strong -all, SPF is doing its job for that sending source. If it’s PermError, fix the underlying record problem before anything else — a broken record can make even your legitimate mail fail. For how SPF fits together with DKIM and DMARC as a complete authentication setup, see SPF, DKIM and DMARC explained.