SPF has terms after the all mechanism, where nothing is evaluated
Updated
What this check looks for
Your record has terms after its closing rule. Receivers stop at the closing rule, so nothing after it is evaluated: a sender listed there is not authorised, and a second closing rule decides nothing.
Why it matters
A record that looks complete can silently leave a provider out. What happens to that provider's mail depends on the closing rule — a hard fail, a soft fail, or a neutral result that authenticates nothing — and the record itself is valid, so a checker that only parses it will not say so.
When the check passes, your report says: “Every term in the SPF record comes before the all mechanism”.
What it costs your score
When this check fails it removes 8 points from your Email authentication score, before the status, confidence and repeat multipliers are applied. Email authentication carries a weight of 15 in the overall score.
It shares the email-auth.spf family ceiling of 35 points: however many findings that family produces, together they cannot remove more than that from Email authentication. One underlying problem showing up in several places is still one problem.
- Severity
- medium
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 8 points
- Family cap
- email-auth.spf · 35
- Category
- Email authentication
- Module
- Email spf
- Fix owned by
- dns host
- In the ruleset since
- 2026.10
How to fix it
Move every mechanism to before the all mechanism, and keep one all.
A sender listed after all is not authorised, and a second all is never reached.
Cut the mechanisms that follow
‹all›and paste them in front of it, keeping onealllast.Re-run the check: the moved mechanisms now count towards the ten-lookup limit.
How to confirm it worked
dig +short TXT ‹domain› — expect the all mechanism to be the last term
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
The record for ‹domain› closes with ‹all› and then lists ‹terms›. ‹consequence›
RFC 7208 §5.1: all matches every sender, so mechanisms after it are never evaluated and a receiver never spends a lookup on them. Move the mechanisms before all, delete a repeated all, and then re-check the lookup count: once a moved mechanism is evaluated, the lookups it costs count towards the limit of ten.
Standards and references
- RFC 7208 §5.1 — "all" § 5.1
Test this on your domain
Run the check that produces this finding, on its own, against any domain.