SPF ~all oder -all? Softfail und Hardfail einfach erklärt

Erst nachsehen: Wie endet Ihr SPF-Eintrag?

Geben Sie Ihre Domain im kostenlosen Domain-Check ein: Kostenloser Domain-Check. Er zeigt Ihren SPF-Eintrag und meldet, wenn der Abschluss fehlt oder +all beziehungsweise ?all lautet. Ein typischer Eintrag sieht so aus:

v=spf1 include:spf.protection.outlook.com include:[newsletter-include] ~all

Der letzte Teil, der Abschluss, regelt alle Server, die vorher nicht genannt sind. Das Zeichen davor heisst Qualifier und bestimmt das Ergebnis.

Die vier Abschlüsse und was der Empfänger tut

SPF prüft die Adresse im Umschlag der Mail (Return-Path), nicht den sichtbaren Absender. Kommt die Mail von einem Server, der im Eintrag fehlt, gilt der Abschluss:

• -all ergibt fail (Hardfail): «Dieser Server darf nicht für uns senden.» Der Standard RFC 7208 erlaubt dem Empfänger, die Mail abzuweisen, empfohlen ist dann der Code 550. Viele Empfänger stellen trotzdem zu und bewerten nur schlechter.
• ~all ergibt softfail: «Wahrscheinlich nicht berechtigt, aber wir legen uns nicht fest.» Laut Standard soll der Empfänger die Mail nicht allein deshalb abweisen, darf sie aber genauer prüfen, etwa als Spam markieren.
• ?all ergibt neutral: keine Aussage. Der Standard verlangt, das wie «kein SPF» zu behandeln. Gedacht für Tests, nicht für den Betrieb.
• +all ergibt pass für jeden Server der Welt. Das ist kein Schutz, sondern eine Freigabe.

Fehlt der Abschluss ganz, ist das Ergebnis für fremde Server ebenfalls neutral, als stünde ?all am Ende.

Warum DMARC die Frage entschärft

DMARC unterscheidet nicht zwischen Softfail und Hardfail. Für DMARC zählt nur, ob SPF besteht und zur sichtbaren Absenderdomain passt. Beide Ergebnisse sind kein Bestehen. Ob eine gefälschte Mail abgewiesen wird, entscheidet Ihre DMARC-Regel (p=quarantine oder p=reject), nicht das Zeichen vor all.

Zwei Einschränkungen gibt es trotzdem:

• Manche Empfänger prüfen SPF vor DMARC. Der DMARC-Standard RFC 7489 warnt ausdrücklich: Bei -all kann ein solcher Empfänger die Mail abweisen, bevor DMARC und damit DKIM überhaupt geprüft werden. Die Branchenorganisation M3AAWG fordert Empfänger deshalb auf, bei SPF fail erst nach der DMARC-Prüfung abzuweisen, ausser beim Eintrag v=spf1 -all.
• Microsoft als Empfänger schreibt in seiner Dokumentation, dass die DMARC-Regel bei SPF-Softfail praktisch nicht greift, wenn die Mail keine DKIM-Signatur trägt. In den Anti-Spam-Richtlinien von Microsoft 365 gibt es zudem die Option «SPF record: hard fail». Sie ist standardmässig aus. Schaltet ein Empfänger sie ein, stuft Microsoft 365 Mails mit SPF fail als Spam mit hoher Sicherheit ein, unabhängig von DKIM.

Was die grossen Anbieter empfehlen

Die Empfehlungen widersprechen sich, und beide Seiten haben gute Gründe:

• Microsoft empfiehlt für Microsoft-365-Domains -all, weil gleichzeitig DKIM und DMARC empfohlen werden. Die DMARC-Berichte sollen zeigen, ob alle Versandwege erfasst sind.
• Google empfiehlt in der Hilfe zu Google Workspace ~all.
• M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) schreibt in ihren Empfehlungen zur E-Mail-Authentifizierung von 2020, SPF-Einträge «sollten auf ~all enden». Domains, die keine Mails senden, sollen v=spf1 -all veröffentlichen.

Einig sind sich alle in zwei Punkten: SPF allein genügt nicht, es braucht DKIM und DMARC. Und eine Domain ohne Mailversand bekommt v=spf1 -all.

Das Risiko von -all bei Weiterleitungen

Leitet ein Empfänger Ihre Mail weiter, etwa vom Vereinspostfach an eine private Adresse, sendet ab dort der Server des Weiterleiters. Dieser steht nicht in Ihrem SPF-Eintrag. SPF scheitert also zwangsläufig, egal welcher Abschluss.

Der Unterschied: Mit -all riskieren Sie, dass ein Empfänger, der SPF früh und streng auswertet, die Mail sofort abweist. Ihre gültige DKIM-Signatur hätte DMARC bestehen lassen, kommt aber nie zum Zug. Mit ~all wird die Mail in der Regel angenommen, DKIM wird geprüft und rettet DMARC.

Wichtig: ~all repariert DMARC bei Weiterleitungen nicht. Ohne ausgerichtete DKIM-Signatur scheitert DMARC so oder so. Der Abschluss entscheidet nur, ob DKIM überhaupt die Chance bekommt.

Wie Sie Weiterleitungen trotzdem zuverlässig machen: Weiterleitung: SPF fail und weitergeleitete Mails im Spam

Warum +all gefährlich ist

+all erlaubt jedem Server, im Namen Ihrer Domain zu senden. Mit DMARC ist das besonders tückisch: Ein Fälscher setzt Ihre Domain im Umschlag und im sichtbaren Absender ein. SPF besteht und passt zur Absenderdomain, also besteht auch DMARC. Ihre Regel p=reject wird damit wirkungslos.

+all entsteht meist aus Ungeduld: Eine Mail kommt nicht an, jemand «öffnet» den Eintrag, und die Lücke bleibt Jahre stehen. Dasselbe gilt für einen Eintrag ohne Qualifier, also nur all: Ohne Zeichen gilt +.

Empfehlung für KMU je nach DMARC-Stufe

1. Domain sendet keine Mails (Zweitdomains, alte Firmennamen): v=spf1 -all und DMARC mit p=reject.
2. Noch kein DMARC oder p=none: ~all. Solange Sie nicht sicher wissen, wer alles in Ihrem Namen sendet (Buchhaltung, Webshop, Scanner, Newsletter), bremst -all vergessene Versandwege aus. Richten Sie zuerst DMARC mit Berichten ein, siehe DMARC von p=none auf quarantine und reject – wann ist es sicher?.
3. p=quarantine oder p=reject, alle Versandwege signieren mit DKIM: Hier ist -all vertretbar und entspricht der Microsoft-Empfehlung. ~all bleibt ebenso korrekt. Leiten viele Empfänger Ihre Mails weiter, etwa bei Vereinen, Schulen oder Mitgliederlisten, bleiben Sie bei ~all.

Der Wechsel von ~all auf -all ist kein Ersatz für DMARC. Den Schutz vor gefälschten Absendern bringt erst p=reject.

Fehlerbilder in der Kopfzeile erkennen

Senden Sie eine Testmail an ein externes Postfach und öffnen Sie die vollständigen Kopfzeilen, in Gmail über «Original anzeigen». Suchen Sie Authentication-Results. Verkürzte Beispiele:

spf=softfail (domain of transitioning info@example.com does not designate 203.0.113.25 as permitted sender) smtp.mailfrom=info@example.com

spf=fail (sender IP is 203.0.113.25) smtp.mailfrom=example.com; dkim=none; dmarc=fail action=quarantine header.from=example.com

So lesen Sie das:

• spf=softfail oder spf=fail, aber dkim=pass und dmarc=pass: meist eine Weiterleitung. Die Mail ist in Ordnung.
• spf=fail und dmarc=fail bei einer echten Mail von Ihnen: Der sendende Server fehlt im SPF-Eintrag. Ergänzen Sie das include des Anbieters. Achten Sie auf die Grenze von zehn DNS-Abfragen: SPF-Fehler «too many DNS lookups» – warum zehn Abfragen reichen müssen.
• spf=permerror: Der Eintrag ist ungültig, oft wegen zweier SPF-Einträge: Zwei SPF-Einträge bei einer Domain – warum das alles ungültig macht.
• spf=neutral: Der Eintrag endet mit ?all oder hat keinen Abschluss.

Typische Fehler

• all mitten im Eintrag: Alles nach all wird ignoriert. v=spf1 -all include:[anbieter] gibt den Anbieter nicht frei.
• -all zu früh: Der Webshop oder die Buchhaltung fehlt im Eintrag, Rechnungen werden abgewiesen.
• +all als Notlösung: hebt den Schutz für SPF und DMARC auf.
• Geparkte Domains ohne SPF: Fälscher weichen gern auf ungenutzte Domains aus.

Was DomainRadar dabei übernimmt

DomainRadar prüft Ihren SPF-Eintrag täglich und meldet einen fehlenden, zu offenen oder ungültigen Abschluss. Aus den DMARC-Berichten sehen Sie, welche Quellen SPF nicht bestehen und ob es Ihre eigenen Versandwege, Weiterleitungen oder Fälschungen sind. So entscheiden Sie den Wechsel auf -all auf Grundlage von Daten.