SPF „Hard Fail“ vs. „Soft Fail“: Worin besteht der Unterschied?

Die SPF-Ergebnisse mögen auf den ersten Blick einfach erscheinen, bis sich eine einzige Richtlinienentscheidung auf die Filterung, die Widerstandsfähigkeit gegen Spoofing und die Zustellungsergebnisse auswirkt. In diesem Leitfaden wird erläutert, was unter „SPF Hard Fail“ und „SPF Soft Fail“ zu verstehen ist, worin der Unterschied zwischen beiden besteht, wann jeweils welche Variante sinnvoll ist und warum SPF am besten als Teil einer umfassenderen E-Mail-Authentifizierungsstrategie funktioniert.

Was ist ein SPF-Fehler?

SPF prüft, ob ein Mailserver berechtigt ist, E-Mails für eine Domain zu versenden. In diesem Abschnitt wird erläutert, wie es zu einem SPF-Fehler kommt und was die gängigen Authentifizierungsergebnisse in der Regel bedeuten.

Wie es zu einem SPF-Fehler kommt

SPF ( Sender Policy Framework) vergleicht die IP-Adresse des Absenders mit dem im DNS für die Domain veröffentlichten SPF-Eintrag. Ein SPF-Fehler tritt auf, wenn der empfangende Server nicht bestätigen kann, dass die Absender-IP für die in dem RFC 5321-Feld „Mail From“ – auch als „Return-Path“ bezeichnet – verwendete Domäne autorisiert ist.

Diese Unterscheidung ist von Bedeutung, da der SPF-Wert nicht immer anhand der im Posteingang angezeigten sichtbaren „Von“-Adresse überprüft wird. Eine Nachricht kann für den Empfänger legitim erscheinen, obwohl sie aufgrund der „Return-Path“-Domäne die SPF-Prüfung nicht besteht.

Häufige Ergebnisse der SPF-Authentifizierung

Die Ergebnisse der SPF-Authentifizierung können variieren. Möglicherweise wird folgende Meldung ausgegeben:

• SPF-Prüfung bestanden: Der sendende Server ist durch den SPF-Eintrag der Domain autorisiert, sodass die SPF-Authentifizierung erfolgreich ist.
• SPF fehlt: Für die Domain wurde kein SPF-Eintrag veröffentlicht, sodass der empfangende Server keine Angaben zur Auswertung hat.
• neutral: Aus der Domain geht nicht eindeutig hervor, ob der Absender autorisiert oder nicht autorisiert ist; daher ist das Ergebnis nicht eindeutig.
• SPF-Softfail: Der Absender ist wahrscheinlich nicht autorisiert, doch die Domain fordert die Empfänger nicht dazu auf, die Nachricht sofort zurückzuweisen.
• SPF-Hardfail: Der Absender ist gemäß dem SPF-Eintrag nicht autorisiert, und die Domain wendet in Bezug auf diese Nachricht strengere Kriterien an.
• SPF-Fehler: Die SPF-Prüfung konnte aufgrund eines vorübergehenden Problems, wie beispielsweise eines DNS-Timeouts oder eines Fehlers bei der DNS-Abfrage, nicht vollständig durchgeführt werden.
• permerror: Der SPF-Eintrag konnte aufgrund eines dauerhaften Problems im SPF-Eintrag – beispielsweise einer ungültigen Syntax oder zu vieler DNS-Abfragen – nicht ausgewertet werden.

Einige Ergebnisse deuten auf ein echtes Autorisierungsproblem hin, während andere auf fehlende Richtlinien, unzureichende Richtlinien, Probleme mit der SPF-Syntax oder DNS-Probleme hindeuten.

Aus diesem Grund ist es hilfreich, vor der Fehlerbehebung das genaue SPF-Ergebnis zu überprüfen. Anhand des konkreten Ergebnisses lässt sich in der Regel feststellen, ob es sich bei dem Problem um einen nicht autorisierten Absender, einen fehlenden Eintrag, einen allgemeineren SPF-Fehler oder um ein Problem mit einem Eintrag oder einer Abfrage handelt.

SPF: „Hard Fail“ vs. „Soft Fail“

Beide Ergebnisse bedeuten, dass SPF nicht bestätigen konnte, dass die Absenderquelle autorisiert war. Der Unterschied liegt darin, wie stark der Domaininhaber wünscht, dass die empfangenden Systeme diesen Fehler interpretieren.

Unterschiede in der Syntax

Der technische Unterschied beginnt bereits im SPF-Eintrag selbst:

• Bei einem „Soft Fail “ wird „~all“ verwendet
• Bei einem schwerwiegenden Fehler wird die Option -all verwendet

Dieses single Zeichen verändert das Signal, das die Domäne an die empfangenden Systeme übermittelt.

Semantische Unterschiede

„Soft Fail“ bedeutet, dass die Domain angibt, der Absender sei wahrscheinlich nicht autorisiert. Dies deutet auf Besorgnis hin, stellt jedoch keine politische Stellungnahme dar, die stark genug wäre, um allein aufgrund des SPF abgelehnt zu werden.

Ein „Hard Fail“ bedeutet, dass die Domain angibt, der Absender sei nicht autorisiert. Dies ist die strengere politische Position und spiegelt das größere Vertrauen wider, dass legitime E-Mail-Ströme bereits im SPF-Eintrag berücksichtigt sind.

Stand der Dinge und politische Zielsetzung

Sowohl „Soft Fail“ als auch „Hard Fail“ sind Ergebnisse von SPF-Fehlern, doch „spf softfail“ und „spf hardfail“ spiegeln unterschiedliche Richtlinienabsichten wider. „Soft Fail“ wird häufig verwendet, wenn ein Unternehmen noch dabei ist, alle Absenderquellen zu überprüfen, oder wenn es bei der Bereinigung seines Absenderverzeichnisses falsche Ablehnungen vermeiden möchte. 

Ein „Hard Fail“ ist eher angebracht, wenn der Domaininhaber größeres Vertrauen in die SPF-Abdeckung hat und bereit ist, entschlossener gegen unbefugte E-Mails vorzugehen.

Wie sie von den Empfangsstellen behandelt werden

In der Praxis werden „Soft-Fail“-Meldungen zwar häufig akzeptiert, jedoch gefiltert, gekennzeichnet oder mit größerer Vorsicht weitergeleitet. Meldungen über schwerwiegende Fehler werden im gesamten E-Mail-Sicherheitssystem mit höherer Wahrscheinlichkeit abgelehnt, unter Quarantäne gestellt oder strenger bewertet.

Diese Unterschiede sind von Bedeutung, da eine falsche Fehlerart entweder zu unnötigen Problemen bei der Übermittlung oder zu einem unnötigen Risiko durch Spoofing führen kann.

Welchen SPF-Fehlermodus sollten Sie verwenden?

Die Wahl des geeigneten SPF-Fehlermodus hängt davon ab, wie vollständig Ihr Absenderverzeichnis ist und wie viel Zustellungsrisiko Ihr Unternehmen bereit ist zu akzeptieren. In den folgenden Abschnitten wird erläutert, wann ein „Soft Fail“ in der Regel die sicherere Wahl ist und wann ein „Hard Fail“ sinnvoller ist.

Wann sollte „Soft Fail“ verwendet werden?

Falls Ihre Organisation noch nicht sicher ist, ob alle legitimen Absenderquellen im SPF-Eintrag enthalten sind, ist „~all“ in der Regel der sicherere Ausgangspunkt. Dadurch wird das Risiko verringert, dass legitime E-Mails zurückgewiesen werden, während Sie die Erfassung der Absender und die SPF-Bereinigung durchführen.

Dies ist insbesondere bei Plattformwechseln, bei der Einbindung von SaaS-Tools von Drittanbietern oder wenn verschiedene Geschäftsbereiche unterschiedliche E-Mail-Ströme verwalten, von großem Nutzen. In solchen Fällen bietet eine „Soft-Fail“-Richtlinie den Teams Spielraum, die Ergebnisse der SPF-Authentifizierung zu beobachten, ohne sofort zu einer strengen „Hard-Fail“-Haltung überzugehen.

Wann sollte „Hard Fail“ verwendet werden?

Ein Wechsel in den Ordner „-all“ ist sinnvoller, sobald die legitimen Absenderquellen vollständig dokumentiert und validiert sind. Dazu gehören die interne E-Mail-Infrastruktur, Cloud-E-Mail-Dienste sowie externe Absender.

Sobald die SPF-Abdeckung vollständig und stabil ist, kann eine „Hard-Fail“-Richtlinie eine höhere Widerstandsfähigkeit gegen Spoofing bei geringerem Risiko von Fehlablehnungen bieten. Für die meisten Organisationen besteht der praktikable Weg darin, zunächst mit einem „Soft Fail“ zu beginnen, solange die SPF-Abdeckung noch überprüft wird, und erst dann zu einem „Hard Fail“ überzugehen, wenn ein hohes Maß an Vertrauen in den Eintrag besteht.

Häufige Anwendungsfälle für „SPF Hard Fail“ und „SPF Soft Fail“

Der richtige Anwendungsfall hängt oft davon ab, wie umfassend und stabil Ihre SPF-Abdeckung ist. Ein „Soft Fail“ ist in der Regel während der Bereinigung und Erkennung praktischer, während ein „Hard Fail“ besser geeignet ist, sobald die sendenden Quellen streng kontrolliert werden.

Wo „Soft Fail“ häufig auftritt

In Übergangsphasen kommt es häufig zu „Soft Fail“. Unternehmen verwenden häufig „~all“, während sie noch dabei sind, Absender von Drittanbietern zu identifizieren, ältere SPF-Mechanismen zu bereinigen oder E-Mail-Dienste nach Anbieter- und Infrastrukturwechseln zu konsolidieren.

Es eignet sich zudem für Domains mit komplexen Absender-Ökosystemen. Wenn mehrere SaaS-Plattformen, Abteilungen oder regionale Systeme im Namen derselben Domain E-Mails versenden, kann es schwieriger sein, die SPF-Einstellungen stets auf dem neuesten Stand zu halten. In solchen Umgebungen bietet „Soft Fail“ eine Möglichkeit, die SPF-Richtlinie zu überwachen und zu optimieren, ohne den Betrieb wesentlich zu beeinträchtigen.

Wo schwerwiegende Ausfälle häufig vorkommen

Ein „Hard Fail“ tritt häufiger in streng kontrollierten Versandumgebungen auf. Wenn eine Domain E-Mails ausschließlich über Microsoft 365, ausschließlich über Google Workspace oder über eine andere streng regulierte Plattform mit gut dokumentierter Absenderinfrastruktur versendet, ist die sichere Unterstützung wesentlich einfacher.

Dies ist zudem für sicherheitsbewusste Organisationen sinnvoll, die über ausgereifte Regeln zur Absenderverwaltung verfügen und eine geringe Toleranz gegenüber dem Risiko von Absenderfälschungen aufweisen. In solchen Umgebungen trägt die strengere SPF-Richtlinie dazu bei, dass unbefugte E-Mails für die empfangenden Systeme deutlicher erkennbar sind.

Strategien zur Gewährleistung einer sicheren SPF-Implementierung

SPF funktioniert am besten, wenn es als fortlaufender Verwaltungsprozess betrachtet wird und nicht als einmalige DNS-Aufgabe. Die folgenden Vorgehensweisen tragen dazu bei, Fehlkonfigurationen zu reduzieren und sicherzustellen, dass die SPF-Richtlinie mit dem tatsächlichen E-Mail-Verkehr übereinstimmt.

Verwenden Sie ein Tool zur Erstellung von SPF-Einträgen

Ein Tool zur Überprüfung oder Erstellung von SPF-Einträgen kann Teams dabei helfen, sauberere Einträge zu erstellen, die SPF-Syntax zu testen und Probleme zu erkennen, bevor Änderungen live geschaltet werden. Dies ist insbesondere bei der SPF-Bereinigung, bei Plattformmigrationen oder beim Onboarding von Absendern von großem Nutzen.

Verwenden Sie geeignete SPF-Mechanismen

Jeder SPF-Mechanismus sollte einer tatsächlichen Absenderquelle zugeordnet sein. Ein übermäßiger Einsatz von „include“, das Beibehalten veralteter Einträge oder die Freigabe umfangreicher IP-Bereiche kann die Richtlinie schwächen und die Fehlerbehebung erschweren.

Pflege und Optimierung des SPF-Eintrags

Die Datensätze sollten übersichtlich bleiben. Entfernen Sie veraltete Absender, vermeiden Sie unnötige verschachtelte Includes und achten Sie auf das Limit für DNS-Abfragen. Falls die SPF-Prüfung zu viele DNS-Abfragen erfordert, kann sie anstelle eines einwandfreien Autorisierungsergebnisses einen „permerror“ zurückgeben. 

Es ist zudem wichtig, mehrere SPF-Einträge zu vermeiden, da die Veröffentlichung von mehr als einer SPF-Richtlinie für denselben Host zu Validierungsproblemen führen kann, anstatt ein einwandfreies Ergebnis zu liefern.

Wenden Sie Richtlinien zur Fehlerbehandlung sorgfältig an

Die Wahl zwischen „Soft Fail“ und „Hard Fail“ sollte die tatsächliche Abdeckung der Absender widerspiegeln. Eine strengere Richtlinie ist nicht automatisch besser, wenn die Datenlage unvollständig ist. Die wirksamste SPF-Richtlinie ist eine, die dem tatsächlichen E-Mail-Verkehr entspricht.

Überwachung der SPF-Authentifizierungsergebnisse

Die Überprüfung der SPF-Authentifizierungsergebnisse im Zeitverlauf hilft Teams dabei, Abweichungen, fehlende Absender und Fehlkonfigurationen zu erkennen, bevor diese zu umfassenderen Zustellbarkeitsproblemen führen – insbesondere, wenn dies durch ein DMARC-Berichtstool unterstützt wird. Regelmäßige SPF-Prüfungen erleichtern es zudem, wiederholte SPF-Fehler zu erkennen, bevor diese zu größeren Problemen bei der Absenderautorisierung führen.

Kombinieren Sie SPF mit DMARC

Der Lichtschutzfaktor allein reicht nicht aus. DMARC sorgt für eine bessere Abstimmung und die Durchsetzung von Richtlinien, wodurch SPF in Produktionsumgebungen, in denen die Widerstandsfähigkeit gegen Spoofing von Bedeutung ist, an Bedeutung gewinnt. Diese bewährten Verfahren helfen Unternehmen dabei, SPF als Teil einer stärkeren und umfassenderen Authentifizierungsstrategie einzusetzen.

Warum der Lichtschutzfaktor (LSF) möglicherweise nicht ausreicht

SPF ist nützlich, löst jedoch allein nicht jedes Problem bei der E-Mail-Authentifizierung. Die im Folgenden aufgeführten wesentlichen Einschränkungen verdeutlichen, warum sich dieser Ansatz am besten als Teil einer umfassenderen Strategie eignet.

Die Weiterleitung kann die SPF-Überprüfung weiterhin unterlaufen

Eine der größten Einschränkungen ist die Weiterleitung. Eine weitergeleitete Nachricht kann zwar weiterhin legitim sein, doch kann die SPF-Prüfung fehlschlagen, da die IP-Adresse des Weiterleitungsservers nicht im SPF-Eintrag der ursprünglichen Domain autorisiert ist. Wenn der entsprechende DNS-TXT-Eintrag diesen Pfad nicht berücksichtigt, kann die Weiterleitung dennoch zu einem Verstoß gegen die SPF-Richtlinie führen, selbst wenn die ursprüngliche Nachrichtenquelle legitim war.

SPF überprüft die Absenderadresse nicht auf ihre Gültigkeit

SPF vergleicht die Absender-IP mit der „Envelope-From“-Domäne und nicht immer mit der für den Benutzer sichtbaren „From“-Adresse. Das bedeutet, dass SPF allein die Herausforderungen hinsichtlich der Identität und der Übereinstimmung des Absenders nicht vollständig bewältigt.

SPF funktioniert am besten in Kombination mit DKIM und DMARC

Aus diesem Grund sollte SPF als eine Komponente einer umfassenderen Strategie zur Authentifizierung und zur Einhaltung der PCI-DSS-Vorgaben betrachtet werden. DKIM fügt eine kryptografische Signatur hinzu, während DMARC Konformitätsregeln und die Durchsetzung von Richtlinien vorsieht, was dazu beiträgt, das Risiko einer fehlerhaften DMARC-Konfiguration zu verringern. Zusammen bieten diese Schutzmaßnahmen einen wirksameren Schutz als der Lichtschutzfaktor (LSF) allein.

Die richtige SPF-Fehlerart mit größerer Sicherheit auswählen

Der Unterschied zwischen einem „Hard Fail“ und einem „Soft Fail“ bei der SPF-Prüfung hängt letztlich von der beabsichtigten Richtlinie, dem Vertrauen in den Absender und der Risikotoleranz ab. Ein „Soft Fail“ deutet auf eine möglicherweise unzulässige E-Mail hin und ist häufig bei der Bereinigung und Erkennung hilfreich. Ein „Hard Fail“ deutet eindeutig auf eine nicht autorisierte E-Mail hin und ist besser geeignet, sobald die SPF-Abdeckung vollständig ist und streng kontrolliert wird.

Der beste Ansatz besteht darin, zunächst Vertrauen in die SPF-Abdeckung aufzubauen, bevor auf „Hard Fail“ umgestellt wird, und diese Richtlinie anschließend durch DKIM und DMARC zu ergänzen, um eine bessere Abstimmung und einen besseren Schutz zu gewährleisten. Für Unternehmen, die einen besseren Überblick über SPF, DKIM und DMARC über alle Absenderquellen hinweg benötigen, kann Mimecast dazu beitragen, Fehlkonfigurationen zu reduzieren und den Schutz in der gesamten E-Mail-Umgebung zu stärken.