SPF has both redirect= and an all mechanism
Updated
What this check looks for
Your record contains a redirect to another domain's policy and also its own closing rule. The closing rule wins and the redirect is never used, which is almost never what was intended.
Why it matters
The policy you believe is in force — the one at the redirect target — is being ignored entirely.
When the check passes, your report says: “The record uses redirect= or an all mechanism, not both”.
What it costs your score
When this check fails it removes 6 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
- 6 points
- Family cap
- email-auth.spf · 35
- Category
- Email authentication
- Module
- Email spf
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Decide which one you want and remove the other.
As written, the redirect is dead configuration and the policy in force may not be the one you think.
Read both records:
dig +short TXT ‹domain›anddig +short TXT ‹redirect domain›.To use the other domain's policy, delete the
allmechanism and keepredirect=‹redirect domain›as the last term. Check that the target record lists every server that sends for this domain and ends in its own~allor-all.To keep your own policy, delete the
redirect=modifier and keepall. Move any sender that was listed only at the target into this record with aninclude:.
How to confirm it worked
dig +short TXT ‹domain› — expect either redirect= or all, not both
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› contains both redirect=‹redirect domain› and an all mechanism. RFC 7208 §6.1 states that redirect is only used when the record contains no all mechanism; where both appear, redirect is ignored.
The two do different jobs. include: asks another domain's record whether the sender is allowed and carries on if it is not; redirect= hands the whole decision to another domain's record, final all included. It exists so several domains can share one centrally maintained policy, each publishing only v=spf1 redirect= and the shared name. Once a record has its own all, evaluation always ends there before the redirect is reached.
So a record such as v=spf1 include:_spf.provider.example redirect=_spf.example.com ~all authorises the provider and soft-fails everyone else, and the servers listed at the redirect target are never consulted. If those servers send real mail, that mail is failing SPF today.
A redirect also costs one of the ten DNS lookups, and if its target publishes no SPF record the result is permerror. Our SPF generator writes a single record that ends in an all mechanism and uses no redirect; keep the redirect only where sharing one policy across domains is what you intend.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.