SPF – Was ist das und wie funktioniert es

Die moderne E-Mail-Authentifizierung basiert auf einer Kombination von drei Standards: SPF, DKIM und DMARC. Mit diesen Standards wird sichergestellt, dass eine Nachricht von einem Server stammt, der dazu berechtigt ist, Nachrichten im Namen der Domäne zu versenden. Dies ist ein Einzelbeitrag aus der mehrteiligen Beitragsreihe: E-Mail-Sicherheit und E-Mail Reputation mit DKIM, SPF und DMARC

  1. DKIM - Was ist das und warum es beim Versand von E-Mails wichtig ist
  2. SPF - Was ist das und wie funktioniert es
  3. DMARC - Was ist das und warum wird es mehr und mehr unabkömmlicher?
  4. Statistken, Reports und Auswertungen

Definition: SPF (Sender Policy Framework)

Im endlosen Kampf gegen Spam und E-Mail-Betrug haben sich mehrere Standards etabliert, um die Flut an Nachrichten einzudämmen. Das Sender Policy Framework - RFC 7208[1] ist einer dieser Standards. Dieser Beitrag untersucht, wie die Reputation einer Domain geschützt und die Zustellbarkeit versendeter E-Mails verbessert werden kann.

SPF ist ein E-Mail-Mechanismus, der Absender und Empfänger vor Spam, Spoofing und Phishing schützen kann. Durch Hinzufügen eines SPF-Records im DNS (Domain Name System)[3] der Domain, kann eine öffentliche Liste von Absender-Server bereitgestellt werden, die zum Senden von E-Mails im Namen der jeweiligen Domäne zugelassen sind. Empfangende Server prüfen, ob eingehende E-Mails von einem Server stammen, der in dieser Liste geführt wird und dadurch zum Versand von Nachrichten dieser Domäne berechtigt ist.

Somit ist SPF ein Mechanismus, der es einem empfangenden E-Mail-Server ermöglicht, zu überprüfen, ob die eingehende E-Mail von einer IP-Adresse, die durch eine im DNS vordefinierte IP-Adressen-Whitelist (SPF-Eintrag), stammt.

Was ist ein SPF-Record?

SPF TXT-Record im DNS der Domain ©by WDNS.at

Ein SPF-Record ist ein DNS TXT-Eintrag im Stammverzeichnis einer Domäne oder Unterdomäne (Sub-Domain), der mit v=spf1 beginnt. Von dort aus werden sog. Mechanismen verwendet, die beschreiben, dass E-Mail-Server Nachrichten im Namen dieser Domäne oder Subdomäne senden dürfen, oder nicht.

Eine Domäne bzw. jede Unterdomäne kann nur über einen SPF-Eintrag verfügen.

Einige dieser Mechanismen wie z.B. a, mx, include und redirect benötigen für die Bereitstellung der Informationen zusätzliche DNS-Lookups. SPF hat, einschließlich aller enthaltenen Einträge, ein maximales DNS-Lookup-Limit von 10. Jeder SPF-Eintrag, der mehr als 10 DNS-Lookups zum Auflösen erfordern würde, wäre demnach ungültig! Dies ist ein häufiger Fehler bei der Bereitstellung von SPF.

SPF Mechanismen:

  • ip4 - Beschreibt eine IPv4-Adresse oder einen CIDR-Adressblock.
  • ip6 - Beschreibt eine IPv6-Adresse oder einen Adressblock.
  • mx - Die im MX-Eintrag der Domäne aufgeführten Server. DNS-Lookup-Limit!
    • mx - Die Server, die in den MX-Einträgen der eigenen Domäne aufgelistet sind (kein Parameter)
    • mx mx:deferrals.example.com - Möglicherweise sendet eine Domäne E-Mails über ihre MX-Server und eine andere Gruppe von Servern, deren Aufgabe es ist, E-Mails zum Zurückstellen von Domänen zu wiederholen.
  • a - Beschreibt die Server, die in den A- und/oder AAAA-Einträgen der Domäne aufgeführt sind. DNS-Lookup-Limit!
    • a - Die IP-Adressen, die in den eigenen A/AAAA-Datensätzen der Domains aufgeführt sind
    • a:example.com - Die IP-Adressen, die in den A/AAA-Datensätzen von example.com aufgeführt sind.
      Äquivalent, wenn die aktuelle Domäne example.com ist; wäre syntaktisch überflüssig.
    • a:mailers.example.com - example.com hat sich dafür entschieden, alle ausgehenden Mailer explizit in einem speziellen A-Datensatz
      unter mailers.example.com aufzulisten.
    • a/24 a:offsite.example.com/24 - Wenn example.com in 192.0.2.1 aufgelöst wird, wird die gesamte Klasse C von 192.0.2.0/24 nach der Client-IP durchsucht. Ähnlich verhält es sich mit offsite.example.com. Wenn mehr als ein A-Datensatz zurückgegeben wird, wird jeder zu einem CIDR-Subnetz erweitert.
  • include - Enthält den SPF-Eintrag aus der Domäne nach dem Doppelpunkt (ggf. nicht den All-Modifikator). DNS-Lookup-Limit!
  • redirect - Beendet die Verarbeitung des SPF-Eintrags und fährt mit dem SPF-Eintrag der angegebenen Domäne fort (einschließlich des gesamten Modifizierers!). DNS-Lookup-Limit!
  • exists - exists = “exists” “:” domain-spec RFC 7208 Abschnitt 7[2]. Dieser Mechanismus wird verwendet, um einen beliebigen Domänennamen zu erstellen, der für eine DNS-A-Abfrage verwendet wird. Es ermöglicht komplizierte Schemata mit beliebigen Teilen des Envelope-Headers, um zu bestimmen, was zulässig ist. Der resultierende Domänenname wird für eine DNS A RR-Suche verwendet (auch wenn der Verbindungstyp IPv6 ist). Wenn ein A-Datensatz zurückgegeben wird, stimmt dieser Mechanismus überein. Dadurch werden granulare Entscheidungen auf der Ebene des Benutzers und der Client-IP-Adresse möglich. DNS-Lookup-Limit!

SPF Qualifier:

Mechanismen, die im SPF-Datensatz aufgelistet sind, haben einen impliziten Pass-Qualifizierer vor sich. Die meisten SPF-Einträge (mit Ausnahme derjenigen, die für die Aufnahme in andere SPF-Datensätze ausgelegt sind) enden mit einem all-Modifikator. Der all-Modifikator besteht aus dem Wort "all" mit einem Qualifizierer davor. Der all-Modifikator gibt an, wie E-Mails behandelt werden sollen, die keinem der aufgeführten Mechanismen entsprechen. Mögliche Qualifizierer sind:

  • + pass - Ein "pass"-Ergebnis bedeutet, dass der Client berechtigt ist, E-Mails mit der angegebenen Identität zu injizieren. Die Domain kann nun im Sinne der Reputation als verantwortlich für das Versenden der Nachricht angesehen werden. Weitere Richtlinienprüfungen können nun mit Vertrauen in die legitime Verwendung der Identität durchgeführt werden.
  • ? neutral - Ein "neutrales" Ergebnis zeigt an, dass, obwohl eine Richtlinie für die Identität gesetzt wurde, es keine eindeutige Aussage (positiv oder negativ) über den Client gibt. Ein "neutrales" Ergebnis MUSS genau wie das "keine" Ergebnis behandelt werden; Die Unterscheidung dient nur zu Informationszwecken. Eine härtere Behandlung von "neutral" als "keine" würde Domänenmanager davon abhalten, die Verwendung von SPF-Einträgen zu testen. Bei einem "keinen" Ergebnis hat der SPF-Verifizierer überhaupt keine Informationen über die Autorisierung oder das Fehlen einer solchen des Clients zur Verwendung der überprüften Identität oder Identitäten. Die check_host()-Funktion wurde fehlerfrei abgeschlossen, konnte aber zu keinem Ergebnis kommen.
  • ~ softfail - Ein "softfail"-Ergebnis sollte als irgendwo zwischen "fail" und "neutral"/"none" behandelt werden. Der Domänenmanager glaubt, dass der Host nicht autorisiert ist, ist aber nicht bereit, eine starke Richtlinienerklärung abzugeben. Empfangende Software SOLLTE die Nachricht NICHT allein aufgrund dieses Ergebnisses ablehnen, sondern KANN die Nachricht einer genaueren Prüfung als normal unterziehen.
  • - fail - Ein "fail"-Ergebnis ist eine explizite Aussage, dass der Client nicht berechtigt ist, die Domäne in der angegebenen Identität zu verwenden. Die Disposition von SPF-Fehlermeldungen ist eine Frage der lokalen Politik.

Die Schwäche von SPF: der SMTP-Header

Es ist ein weit verbreitetes Missverständnis, dass SPF das E-Mail-Spoofing gänzlich stoppt. Im besten Fall erschwert es es einen Angreifer. Beachten Sie, dass SPF nach einem SPF-Eintrag in der SMTP-Transaktion (auch als envelope from) sucht und nicht aus dem Header, die der empfangende E-Mail-Client sieht. Die SMTP-Transaktion ist für den Endclient nicht sichtbar, selbst wenn die Nachrichtenkopfzeilen angezeigt werden. Dies bedeutet, dass ein Angreifer SMTP-Header verwenden kann, um den E-Mail-Server des Ziels anzuweisen, eine vom Angreifer kontrollierte Domäne zu überprüfen, die einen Autorisierungsmechanismus für den E-Mail-Server enthält, den der Angreifer verwendet, während er eine völlig andere Domäne für das Ziel in der Nachricht vom Header vortäuscht!

Diese Art von Domänenkonflikt tritt legitim auf, wenn z.B. eine Postfachregel eine Nachricht aus einer anderen Domäne weiterleitet. Die Nachricht von der Domäne bleibt gleich, die SMTP-E-Mail Header enthalten jedoch die Domäne des weiterleitenden E-Mail-Servers.

Wie funktioniert SPF (grundsätzlich)

Flussdiagramm SPF ©by WDNS.at

Damit SPF funktioniert, müssen zwei Bedingungen erfüllt sein:

  1. Der Administrator der Domäne veröffentlicht einen SPF-Eintrag im DNS, der die Whitelist der Absender angibt, d.h. welche Hosts im Namen dieser Domäne senden dürfen.
  2. Die Prüfung erfolgt auf der Seite des E-Mail-Dienstanbieters (ESP): für jede eingehende E-Mail wird der SPF-Eintrag aus dem DNS abgerufen und überprüft, ob der Absender auf der Liste angeführt ist.

Beispiele für SPF-Einträge

  •  SPF-Eintrag für Domänen, die E-Mails von ihren eingehenden Gateways (MTA) senden und SPF-Einträge fehlen. Der dargestellte Eintrag autorisierte explizit alle Server, die im MX-Eintrag der Domäne aufgeführt sind, während alle anderen als neutral behandelt wurden. Dies ist ein allgemein gültiger, temporärer SPF-Eintrag für neue Domänen oder neu erworbene Domänen, die noch explizit keinen detailierten SPF-Eintrag gesetzt haben: v=spf1 mx ?all
  • MS Office365: v=spf1 include:spf.protection.outlook.com ?all
  • Google G-Suite: v=spf1 include:_spf.google.com ?all

 

Quellennachweis:
[1] https://tools.ietf.org/html/rfc7208
[2] https://tools.ietf.org/html/rfc7208#section-7
[3] https://de.wikipedia.org/wiki/Domain_Name_System
[4] http://www.open-spf.org/SPF_Record_Syntax/

Changelog:
04.07.2022 - erste veröffentlichte Version
19.07.2022 - einige Textpassagen überarbeitet
31.05.2023 - einige Textpassagen überarbeitet