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:

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.