auth.spf.no_all

SPF-Eintrag ohne „all“-Mechanismus

Was wir prüfen

Wir prüfen, ob der SPF-Eintrag mit einem all-Mechanismus endet oder per redirect= delegiert. Dieser Befund bedeutet: Er tut keins von beidem. Der Eintrag listet Absender und hört dann einfach auf.

Was dieses Ergebnis bedeutet

RFC 7208 §4.7 legt fest, was passiert, wenn kein Mechanismus passt und kein all vorhanden ist: Das Ergebnis ist neutral, genau so, als endete der Eintrag mit ?all. Jeder gelistete Server besteht; jeder andere Server im Internet bekommt ein Ergebnis, das Empfänger wie none behandeln müssen. Der Eintrag autorisiert, weist aber nie ab.

Warum das wichtig ist

Gefälschte Mail scheitert nie an SPF. Ohne Fail-Ergebnis gibt es nichts, worauf ein Empfänger reagieren könnte, und nichts, was DMARC als SPF-Fehlschlag zählt.
Leicht zu übersehen. Der Eintrag wirkt vollständig, weil er syntaktisch gültig ist; nur der fehlende Abschluss verrät ihn.
Ein redirect= ist der einzige legitime Grund für ein fehlendes all, und dieser Fall wird hier nicht gemeldet.

So behebst du das

Hänge ein abschließendes all an, Softfail, solange du deine Absender prüfst, harter Fehlschlag, sobald die Aggregatberichte sauber sind:
```
example.com.  IN  TXT  "v=spf1 include:_spf.provider.example ip4:192.0.2.10 -all"
```
Scanne erneut. Der Befund verschwindet, sobald der Eintrag mit ~all, -all oder einem redirect= endet.

So fließt es in die Bewertung ein

Nicht bewertet — dieser Befund kostet im aktuellen Modell keine Punkte; die Bewertungsseite führt ihn unter „Befunde ohne Abzug“. Das vollständige Scoring-Modell steht in der Bewertungsmethodik.