auth.spf.no_all

SPF Record Has No "all" Mechanism

What we check

We check whether the SPF record ends in an all mechanism or delegates with redirect=. This finding means it does neither: the record lists senders and then simply stops.

What this finding means

RFC 7208 §4.7 defines what happens when no mechanism matches and there is no all: the result is neutral, exactly as if the record ended in ?all. Every server you listed passes; every other server on the internet gets a result receivers must treat like none. The record authorizes, but it never rejects.

Why it matters

Forged mail is never failed by SPF. Without a fail result there is nothing for a receiver to act on and nothing for DMARC to count as an SPF failure.
It is easy to miss. The record looks complete because it is syntactically valid; only the missing terminal mechanism gives it away.
A redirect= is the one legitimate reason to have no all, and that case is not reported here.

How to fix

Append a terminal all, softfail while you verify your senders, hard fail once the aggregate reports are clean:
```
example.com.  IN  TXT  "v=spf1 include:_spf.provider.example ip4:192.0.2.10 -all"
```
Re-scan. The finding clears once the record ends in ~all, -all or a redirect=.

How it's graded

Not scored — this finding carries no point deduction in the current model; the Grading page lists it under "Findings without a deduction". See Grading Methodology for the full scoring model.