SPF ~all oder -all: Softfail oder Hardfail im Jahr 2026?

Veröffentlicht am 2. November 2026 · 6 Min. Lesezeit · spFlat! Blog

Jeder SPF-Eintrag endet mit einem all-Mechanismus, und das Zeichen davor ist vermutlich das meistdiskutierte Zeichen der gesamten E-Mail-Authentifizierung. Sollte Ihr Eintrag auf ~all (Softfail) oder auf -all (Hardfail) enden?

Die kurze Antwort für 2026: Wenn Ihre Domain E-Mails versendet und Sie DMARC nutzen, verwenden Sie ~all. Wenn Ihre Domain nie E-Mails versendet, verwenden Sie -all. Die lange Antwort erklärt, warum die strenger wirkende Option nicht automatisch die sicherere ist, und warum beides keine Rolle spielt, wenn Ihr SPF-Eintrag fehlerhaft ist.

Die vier Qualifier im Überblick

Der Qualifier gilt nur für E-Mails von Servern, die zu keinem vorherigen Eintrag im Record passen. E-Mails aus Ihren gelisteten ip4:-, ip6:- und include:-Quellen erhalten pass, egal wie der Eintrag endet.

Was Softfail und Hardfail laut Standard bedeuten

RFC 7208 definiert fail als ausdrückliche Aussage, dass der sendende Host nicht berechtigt ist, die Domain zu verwenden. softfail ist schwächer: Der Host ist wahrscheinlich nicht berechtigt, aber der Domaininhaber möchte sich nicht festlegen. Keines der beiden Ergebnisse schreibt dem Empfänger vor, was zu tun ist. Das regelt die lokale Richtlinie, und Empfänger gehen unterschiedlich damit um.

Ohne DMARC ist dieser Unterschied relevant, weil der Qualifier dann Ihr einziges Richtliniensignal ist. Mit DMARC sieht die Sache völlig anders aus.

Warum DMARC den Qualifier unwichtiger macht

DMARC interessiert sich nicht dafür, wie SPF fehlgeschlagen ist. Es stellt zu SPF nur eine Frage: Wurde SPF bestanden, mit einer Domain, die zum From:-Header passt (Alignment)? Softfail, Fail und Neutral sind schlicht "nicht bestanden".

Mit DMARC auf p=reject gilt also:

• ~all mit DMARC p=reject: gefälschte E-Mails werden abgelehnt.
• -all mit DMARC p=reject: gefälschte E-Mails werden abgelehnt.

Der Schutz gegen Spoofing ist identisch. Die Durchsetzung steckt in Ihrer DMARC-Richtlinie, nicht in den letzten vier Zeichen Ihres SPF-Eintrags. (Alignment ist neu für Sie? Lesen Sie zuerst SPF vs DKIM vs DMARC.)

Das eigentliche Risiko von -all: Ablehnung, bevor DMARC greift

Manche Empfänger prüfen SPF, sobald der sendende Server MAIL FROM übermittelt, also bevor die eigentliche Nachricht angekommen ist. Steht in Ihrem Eintrag -all und ist die sendende IP nicht gelistet, kann der Empfänger sofort ablehnen. DKIM wird nie geprüft und DMARC läuft nie.

Die DMARC-Spezifikation warnt genau davor. RFC 7489 (Abschnitt 10.1) weist darauf hin, dass ein -all eine frühe Ablehnung auslösen kann, noch bevor eine DMARC-Verarbeitung stattfindet.

Das schadet genau in den Situationen, in denen DMARC die Nachricht gerettet hätte:

• Weiterleitung. Ein Empfänger leitet Ihre E-Mail von einer alten Adresse weiter, oder eine Mailingliste verteilt sie. Der weiterleitende Server steht nicht in Ihrem SPF-Eintrag, also schlägt SPF fehl. DKIM wäre weiterhin gültig und aligned gewesen, aber die Nachricht wurde bereits abgewiesen.
• Ein Absender, von dem niemand wusste. Das Marketing nutzt eine neue Plattform, die mit DKIM signiert, aber noch nicht in Ihrem SPF-Eintrag steht. Mit ~all besteht DMARC über DKIM. Mit -all weisen manche Empfänger die Nachricht ab.
• Veraltete IP-Listen. Ein Anbieter ergänzt neue Adressbereiche, und Ihr manuell geflatteter Eintrag enthält sie noch nicht.

Deshalb empfiehlt M3AAWG (die Messaging, Malware and Mobile Anti-Abuse Working Group) in ihren Email Authentication Recommended Best Practices ~all für Domains, die E-Mails versenden.

Was sollten Sie verwenden?

Eine Domain, die nie E-Mails versendet, sichern Sie vollständig ab:

example.com.         TXT  "v=spf1 -all"
_dmarc.example.com.  TXT  "v=DMARC1; p=reject"
example.com.         MX   0 .

Die letzte Zeile ist ein Null-MX (RFC 7505): Die Domain nimmt auch keine E-Mails an. Hier hat -all keinen Nachteil, denn es gibt keine legitimen E-Mails, die verloren gehen könnten.

Beides hilft nicht, wenn SPF defekt ist

All das setzt voraus, dass SPF überhaupt ausgewertet wird. Braucht Ihr Eintrag mehr als 10 DNS-Lookups, bricht die Prüfung mit einem PermError ab, bevor all erreicht wird. Ihr sorgfältig gewählter Qualifier wird nie gelesen, und für DMARC ist SPF schlicht nicht bestanden.

Dasselbe gilt für zwei SPF-Einträge auf einer Domain, einen Syntaxfehler oder zu viele Void-Lookups. Bevor Sie über ~all oder -all diskutieren, stellen Sie sicher, dass der Eintrag funktioniert:

• Welche SPF-Lookups wirklich zählen
• SPF PermError beheben
• SPF-Flattening erklärt

Mit spFlat! besteht Ihr Eintrag aus einem kurzen spFlat!-Include. spFlat! schlägt dabei ~all vor, passend zur Empfehlung oben, und hält die IP-Liste hinter diesem Include aktuell. Der Eintrag selbst liegt in Ihrem eigenen DNS: Wenn Sie für eine Domain bewusst -all möchten, können Sie das Ende selbst anpassen. Weil die IP-Liste aktuell bleibt, entfällt auch das Problem veralteter Listen, das -all bei manuell geflatteten Einträgen riskant macht.

Bevor Sie den Qualifier ändern

1. Prüfen Sie, ob Ihr SPF-Eintrag fehlerfrei ausgewertet wird und unter 10 Lookups bleibt.
2. Stellen Sie sicher, dass jeder versendende Dienst mit DKIM signiert, aligned zu Ihrer Domain.
3. Lesen Sie einige Wochen lang Ihre DMARC-Aggregatberichte und suchen Sie nach legitimen Quellen, bei denen SPF fehlschlägt.
4. Stellen Sie DMARC auf p=quarantine und danach auf p=reject.
5. Entscheiden Sie erst dann über den Qualifier. Bei den meisten sendenden Domains bleibt es bei ~all.

Zusammenfassung

• ~all für Domains, die E-Mails versenden, -all für Domains, die das nie tun.
• Mit durchgesetztem DMARC bieten Softfail und Hardfail denselben Schutz gegen Spoofing.
• -all kann zu Ablehnungen führen, bevor DKIM und DMARC laufen, und bricht so weitergeleitete E-Mails.
• Ein PermError macht die ganze Frage hinfällig. Reparieren Sie zuerst den Eintrag.