Sender Policy Framework (SPF): Wie es funktioniert und wann man es nicht nutzen sollte

Wie funktioniert SPF

SPF (Sender Policy Framework) ist eine einfache Methode um gefälschte Absender zu identifizieren und als SPAM zu blocken.

Die Funktionsweise ist einfach: Der Domaininhaber (Bsp. Ich mit der Domain frankysweb.de) veröffentlicht im DNS einen TXT Record (SPF Record) der die Mailserver enthält, von denen ich Mails sende. Wenn zum Beispiel mein Mailserver die IP 81.169.145.159 hat und der einzige Mailserver ist der unter der Domain frankysweb.de Mails versendet, dann kann ich in meiner DNS-Zone den folgenden TXT-Record als SPF Eintrag setzen:

v=spf1 ip4:81.169.145.159 -all

Damit gebe ich als Domaininhaber an das nur die IP 81.169.145.159 unter der Domain frankysweb.de Mails verschicken darf.

Der Empfänger einer Mail kann nun diesen öffentlichen Eintrag abfragen und somit prüfen ob der Mailserver der gerade eine Mail von frankysweb.de übermitteln möchte auch wirklich dazu berechtigt ist. Dazu muss er nur noch die IP-Adresse des einliefernden Mailservers mit dem SPF-Eintrag vergleichen. Soweit, so einfach.

SPF steht allerdings auch nicht ganz zu unrecht in der Kritik, dafür gibt es verschiedene Gründe. Auf einen dieser Gründe möchte ich näher eingehen, weil er mir in letzter Zeit häufiger untergekommen ist:

Umleitungen (Relays, Smarthosts)

Ein empfangener Mailserver prüft also mittels SPF die IP-Adresse des sendenden Mailservers gegen den SPF Eintrag im DNS. Hier kommt es darauf an, wie der Mailserver und vor allem von wem der Mailserver die Mails tatsächlich erhält und wer den SPF Eintrag prüft. Ich habe dazu mal eine kleine Zeichnung angefertigt:

1

Nehmen wir also mal an, dass frank@frankysweb.de eine Mail an hans.dampf@gehtjagarnicht.de schicken möchte. Der Admin von gehtagarnicht.de hat beispielsweise einen lokalen Exchange Server und weil er keine SPAM-Mails haben möchte, auch einen SPAM-Filter vor den Exchange Server geschaltet (Oder irgendeine Software auf dem Exchange Server installiert). Der Admin von gehtjagarnicht.de hat sich vieleicht auch folgendes gedacht (nur als Beispiel):

Hey, ich hab keine feste IP an meinem DSL Anschluss, also lasse ich doch einen Relay (smtp.rzone.de) die Mails einfach an meinen DynDNS Account weiterleiten. Daher lautet mein MX-Eintrag auf smtp.rzone.de und der leitet einfach alles stumpf auf meinen DynDNS weiter

Richtig, kann man machen, aber: Nicht mit SPF.Denn in diesem Fall sieht der SPAM-Filter auf dem lokalen Mailserver immer nur die IP-Adresse des Relays/Smarthosts. In diesem Beispiel alsp die IP von smtp.r-zone.de. Wenn der lokale Mailserver jetzt einen SPF-Check versucht, passt die einliefernde IP nicht zu der IP im SPF-Record und die Prüfung schlägt fehl.

Man kann also entweder auf dem Relay SPF Checks durchführen und die auf dem lokalen Server abschalten, oder man verzichtet komplett auf SPF.Whitelisten der Relay-IPs am lokalen Spamfilter ist auch keine Lösung, da der Relay alle Mails einliefert, laufen alle Mails am SPF Check vorbei.

Das gleiche Spiel, tritt häufig bei umgeleiteten Domains auf, als Beispiel: gehtjagarnicht.de nutzt auch noch gehtjagarnicht.com und leitet alle Mails von .com an .de weiter. Wird nun eine Mail an hans.dampf@gahtjagarnicht.com geschickt und diese vom Provider an hans.dampf@gehtjagarnicht.de um- oder weitergelietet, ist wieder die IP des Providers die einliefernde IP, nicht aber der ursprünglich Mailserver. Ergo SPF-Check schlägt fehl.

7 Gedanken zu „Sender Policy Framework (SPF): Wie es funktioniert und wann man es nicht nutzen sollte“

  1. Hallo Franky… ich habe mal ne dumme Frage….

    Eigentlich habe ich mir dieses Thread gesucht, weil ich ein Problem habe (hatte)…
    2 Kunden hatten Stress mit Spoofing-Mails von sich selbst – eigentlich hätte das nicht sein dürfen, weil ich da mal vor Jahren das Sender-ID Verfahren eingerichtet habe…

    Nun habe ich 2 Tage gesucht, um zu sehen was falsch ist… einen Unterschied habe ich zu den funktionierenden Systemen gefunden… einen MX auch in IPV6

    Nun meine Frage: Kann es sein, dass dieser Dienst nicht funktioniert, wenn man eine IP-V6 Konfiguration hat – also die externen Mails auch über IPV6 auf dem Exchange-Server (2019) landen ?

    Nachdem ich diesen Eintrag gelöscht habe, und ein wenig gewartet, ging es plötzlich wieder…

    Viele Grüße aus Berlin
    Jens

    Antworten
  2. Ist dafür nicht der include-Mechanismus gedacht? Die Relay Pools haben ja entsprechend in deren SFP Einträgen alle IPs gelistet, welche Mails versenden dürfen.

    Die IP des Relay Pools hat man doch nur, wenn im eigenen SPF der Pool als A-Mechanismus angelegt ist. Also z.B. a:relaypool.provider.de, während include:relaypool.provider.de den SPF von provider.de checkt und entsprechend alle erlaubten Sender-IPs erhält.

    Oder habe ich da was falsch verstanden?

    Antworten

Schreibe einen Kommentar