SPF evaluation-order diagnostics
SPF include after all? Later terms are ignored
SPF is evaluated from left to right. The all mechanism always matches, so an include, IP range or other mechanism placed after it can never authorize a sender.
A legitimate sender was added to SPF, but receivers still report failure because its mechanism appears after the terminal result.
v=spf1 -all include:_spf.sender.example
Check SPF evaluation order free
Why an SPF include after all does not work
Each SPF mechanism is considered in order until one matches. The all mechanism matches every remaining address, usually with -, ~, ? or + as its qualifier. Nothing after that point is reachable.
A redirect= modifier is also ineffective when all exists, because redirect is used only after the mechanism list ends without a match. This is a policy-order issue, not a DNS propagation delay.
What the check does—and does not—prove
MailFixIt parses the selected SPF record and identifies sender mechanisms positioned after all. It does not recursively resolve unreachable terms because they cannot affect the current policy outcome.
The result proves that a term is ignored, but it does not prove that the term belongs in the record. Confirm that the associated service genuinely sends mail for this envelope domain before moving or retaining it.
Possible diagnostic results
Unreachable term found
An include, address, MX, A or other mechanism follows all. Review sender ownership before reordering it.
Evaluation order valid
The terminal mechanism is last. Investigate authorization content, lookup limits or the exact envelope domain instead.
Redirect ineffective
The policy contains both all and redirect=. Decide which policy model is intended; using both does not create fallback behavior.
Multiple or invalid SPF records
Evaluation order is not the only issue. Consolidate selected SPF policies and correct syntax while preserving legitimate senders.
How to fix ignored SPF mechanisms
- Export the current TXT values and inventory every service authorized to send for the domain.
- Map each SPF mechanism to an active sender; remove obsolete services rather than merely moving them.
- Place legitimate sender mechanisms before the single final
allmechanism. - If using
redirect=, follow its intended policy model instead of combining it withall. - Recheck syntax, DNS lookup limits and a real message's envelope domain.
The provider domain is fictional and belongs only in a policy if that service is authorized.
Before: v=spf1 -all include:_spf.sender.example After: v=spf1 include:_spf.sender.example -all
Rollback by restoring the exported policy if legitimate mail regresses. Keep only one selected SPF record; do not publish the corrected version beside the old one.
When ordering is probably not the cause
If all is already last, SPF can still fail because the message uses another envelope domain, the provider include is missing or invalid, the sender IP is not covered, or evaluation exceeds DNS lookup limits. Inspect the receiver's smtp.mailfrom result rather than assuming the visible From address selects SPF.
Verify the repair
Resolve the public TXT record and confirm one SPF policy with the terminal mechanism last. Then send through each authorized service and inspect the resulting Authentication-Results. Verification should cover all legitimate senders, not only the one that exposed the error.
Related SPF checks
SPF evaluation FAQ
Are SPF mechanisms after all evaluated?
No. The all mechanism always matches, so evaluation ends there. Includes, IP mechanisms and other terms placed after it are unreachable.
Does redirect work when an SPF record already contains all?
No. The redirect modifier is used only when no mechanism matches. Because all always matches, redirect has no effect when all is present.
Technical references
RFC 7208: mechanism evaluation · RFC 7208: all mechanism · RFC 7208: redirect