SPF results get lumped together far too often.
An admin sees spf=softfail in one message, spf=permerror in another, spf=none in a third, and the practical question is always the same: does this mean the message failed DMARC, or does it just mean SPF was inconclusive?
The short answer is simpler than the result list makes it look:
pass helpspass SPF result is effectively "not good enough for DMARC"That last point is the one that clears up most confusion.
Per RFC 7208 Section 2.6, SPF evaluation can return none, neutral, pass, fail, softfail, temperror, or permerror. Per RFC 7489 Section 4.2, DMARC passes only when at least one underlying mechanism produces an aligned pass. So DMARC is not choosing between softfail and permerror as if one were "less failed" than the other. It is mostly asking: did SPF produce an aligned pass, yes or no?
If the goal is a fast mental model, use this table first and then dig into the details below.
| SPF result | What it means | Typical cause | Can it satisfy DMARC? |
|---|---|---|---|
none | No usable SPF policy was found for the checked identity | no SPF record, wrong identity, malformed or non-existent domain | No |
neutral | The domain explicitly declines to assert authorization | ?all, or nothing matched and policy fell through to implicit neutral | No |
softfail | The domain is signaling "probably not authorized" | ~all matched | No |
fail | The domain explicitly says the client is not authorized | -all matched | No |
permerror | SPF policy or evaluation is broken in a durable way | syntax errors, multiple SPF records, lookup-limit excess | No |
temperror | SPF evaluation hit a temporary problem | DNS timeout, transient resolver failure | No |
pass | The client is authorized for the checked identity | SPF record matched the sender IP | Yes, but only if aligned |
SPF does not authenticate the visible From: header users notice first.
SPF checks the SMTP identity, usually the MAIL FROM domain, and sometimes HELO as part of pure SPF processing. DMARC then takes the SPF result for the MAIL FROM identity and asks whether that authenticated domain is aligned with the RFC 5322 From domain.
That distinction matters because a message can have:
spf=pass for bounce.example.netFrom: billing@example.comand still fail DMARC because example.net is not aligned with example.com.
If that alignment piece still feels slippery, Return-Path vs From: why SPF can pass while DMARC fails and DMARC alignment: From vs Return-Path (strict vs relaxed) cover it in more depth.
none: there was no SPF policy to evaluatePer RFC 7208, none means either no syntactically valid domain could be extracted for the SPF check, or no SPF record was retrieved for that domain.
Operationally, none usually means one of these:
MAIL FROM domain has no SPF TXT recordThis is not the same as "the sender was unauthorized". It is closer to "SPF had no policy basis for making a decision".
From a DMARC perspective, though, none still does not help. DMARC needs an aligned SPF pass, not merely the absence of an explicit SPF fail.
That is why domains relying on DKIM alone can still see DMARC pass even when SPF shows none. And it is also why domains that expect SPF to carry DMARC by itself will see DMARC fail if SPF is none and DKIM is absent or unaligned.
neutral: the domain explicitly withholds a yes-or-no answerneutral is SPF's way of saying, "this domain is not asserting that the sending IP is authorized." RFC 7208 defines this as an explicit non-assertion, not a pass and not a fail.
In practice, neutral commonly appears when:
?allall, which falls through to SPF's default neutral resultThis is one reason records that just trail off are a bad idea operationally. They leave future debugging needlessly fuzzy. An explicit ending like ~all or -all says more.
For DMARC, neutral is treated the same as every other SPF non-pass result: it does not satisfy SPF alignment, so it does not contribute a DMARC pass.
softfail: probably unauthorized, but not a hard stopsoftfail is the result most admins half-remember because ~all is so common during SPF rollout.
Per RFC 7208, softfail is a weak statement that the host is probably not authorized. In other words, the domain is leaning toward "no" but is not publishing the stronger -all assertion yet.
That makes softfail useful as a transitional signal while cleaning up sender inventory. It can also become a trap when it stays in place forever and people begin treating it as equivalent to pass because messages still get delivered.
It is not equivalent to pass.
It is also not equivalent to DMARC pass.
DMARC does not award partial credit for softfail. If SPF returns softfail, then SPF did not produce the aligned pass DMARC is looking for.
spf=softfail may still coexist with dmarc=pass if DKIM passes in alignment. That does not mean DMARC "accepted the softfail". It means DKIM carried the DMARC result.
If the rollout question is specifically ~all versus -all, the practical guidance in SPF redirect vs include, and common SPF mistakes is a useful companion read.
fail: explicit authorization failurefail is SPF's clear negative answer. The checked IP was not authorized by the domain's published SPF policy.
This normally means a matching mechanism did not authorize the client and the record ended in -all, or another evaluation path returned a definite fail.
Among SPF results, this is the one people instinctively expect DMARC to care about most. But the DMARC rule is still the same: fail does not satisfy DMARC. Only aligned pass does.
So if a message shows:
spf=faildkim=pass with aligned d=then DMARC can still pass.
And if a message shows:
spf=pass, but for a non-aligned bounce domaindkim=failthen DMARC still fails.
That is the recurring theme: DMARC is not grading the emotional strength of the SPF failure. It is checking for aligned authentication success.
permerror: the SPF setup is brokenpermerror is where configuration mistakes start to matter more than sender intent.
RFC 7208 defines permerror as a permanent error in the published SPF data or its interpretation. This is the result that requires operator intervention.
Common causes include:
Two of the most common real-world causes are "more than one SPF record exists" and "include chains pushed the policy past the 10-DNS-lookup limit". Both are easy to create accidentally, especially when several sending platforms are added over time.
permerror is not a stronger version of fail. It does not mean the sending IP was evaluated and found unauthorized. It means SPF evaluation itself broke.
DMARC still gets no usable SPF success from that. So from the DMARC angle, permerror behaves like every other SPF non-pass result: no aligned SPF pass, therefore no SPF contribution toward DMARC pass.
If the policy itself is the problem, SPF 10-DNS-lookup limit: why it happens, how to audit includes, and mitigation patterns and SPF redirect vs include, and common SPF mistakes are the most relevant follow-ups.
temperror: SPF evaluation hit a temporary problemtemperror means the verifier ran into a transient problem, usually DNS-related, while trying to evaluate SPF.
Common triggers:
Unlike permerror, temperror does not imply the SPF record is broken. A later retry may succeed without any DNS changes by the domain owner.
That distinction matters when troubleshooting because the fix is very different:
permerror points to policy repairtemperror points to transient DNS or receiver-side evaluation issuesBut DMARC still does not count temperror as a pass. If SPF returns temperror, SPF has not supplied the aligned pass required for DMARC success.
One reason DMARC uses both SPF and DKIM is precisely to reduce dependence on a single mechanism. A transient SPF problem does not necessarily force DMARC failure if aligned DKIM still passes.
This is the core idea to keep in mind:
DMARC is not a ranking system for SPF outcomes.
Per RFC 7489, a message satisfies DMARC if at least one underlying authentication mechanism produces a pass result and that pass is aligned with the RFC 5322 From domain. For SPF, that means an SPF-authenticated MAIL FROM domain must align with the visible From domain under relaxed or strict aspf rules.
So when SPF produces any of these:
noneneutralsoftfailfailpermerrortemperrorthe SPF part of DMARC is effectively in the same state: not an aligned pass.
That does not make those SPF results interchangeable for troubleshooting. They are very different operationally. It only means DMARC does not treat them as separate "almost pass" categories.
Authentication-Results: mx.example.net;
spf=softfail smtp.mailfrom=bounces.example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comWhat happened:
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=mailer.example.net;
dkim=fail header.d=example.com;
dmarc=fail header.from=example.comWhat happened:
mailer.example.netFrom domain was example.comAuthentication-Results: mx.example.net;
spf=permerror smtp.mailfrom=example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comWhat happened:
If the goal is to fix the root cause quickly, treat the SPF result as a routing clue:
none: check whether the right MAIL FROM domain is being evaluated and whether that domain actually publishes SPFneutral: look for ?all or a record that falls through without a deliberate endingsoftfail: assume the source is probably missing from inventory or the domain is still in a transitional ~all posturefail: verify whether the sending IP or service should be authorized at allpermerror: audit syntax, duplicate SPF records, recursive include usage, and lookup counttemperror: check DNS availability, nameserver responsiveness, and whether the issue is transient across retriesThen separately ask the DMARC question:
pass?From domain?pass instead?That sequence keeps SPF troubleshooting and DMARC evaluation from getting mixed together.
none, neutral, softfail, fail, permerror, and temperror are not the same thing in SPF. They point to different states: missing policy, explicit non-assertion, weak negative assertion, hard negative assertion, broken policy, or temporary evaluation trouble.
But DMARC is stricter and simpler.
For SPF to help DMARC, SPF must produce a pass and that authenticated domain must align with the visible From domain. Everything else is just a different reason SPF did not provide that aligned pass.