SPF steht für „Sender Policy Framework“ und bezeichnet ein Verfahren, mit dem der Inhaber einer Domain öffentlich festlegt, welche Server E-Mails unter ihrem Namen versenden dürfen. Beschrieben ist es in RFC 7208, den die Internet Engineering Task Force im April 2014 als Standard veröffentlicht hat. Die Festlegung steht als einzelner TXT-Eintrag im DNS der Domain, sodass jeder empfangende Server sie beim Eingang einer Nachricht abfragen kann.
Geprüft wird dabei die Absenderangabe, die der versendende Server während der Übertragung im Befehl „MAIL FROM“ nennt, statt der im E-Mail-Programm sichtbaren Absenderadresse. Microsoft bezeichnet diese technische Angabe als Umschlagabsender oder nach dem Übertragungsstandard RFC 5321 als 5321.MailFrom-Adresse. Ergänzend sieht RFC 7208 eine Prüfung des Namens vor, mit dem sich der versendende Server zu Beginn der Verbindung im Befehl „HELO“ vorstellt.
Aufbau eines SPF-Eintrags
Jeder SPF-Eintrag beginnt mit der Versionsangabe v=spf1, auf die eine Reihe von Mechanismen folgt, die der Empfänger von links nach rechts auswertet. Mit ip4 und ip6 stehen einzelne Adressen oder Adressbereiche im Eintrag, während include die Angaben eines anderen Dienstes übernimmt, etwa die Serverliste eines Postfachanbieters. Die Mechanismen a und mx berechtigen jene Server, auf die der Adresseintrag oder der Maileintrag der Domain zeigt, während RFC 7208 vom Veröffentlichen des Mechanismus ptr ausdrücklich abrät.
Am Ende steht in der Regel der Mechanismus all, der als ausdrückliche Vorgabe für alle übrigen Server dient. Sein vorangestelltes Zeichen bestimmt das Ergebnis, wobei -all ein eindeutiges „fail“ und ~all ein abgeschwächtes „softfail“ auslöst. Google empfiehlt in seiner Anleitung ~all, während Microsoft für Domains in Microsoft 365 wegen der dort zusätzlich empfohlenen Verfahren DKIM und DMARC zu -all rät. Die Technische Richtlinie TR-03182 des BSI lässt beide Varianten zu und verlangt, dass unberechtigte Server mindestens ein „softfail“ erhalten.
Als Beispiel ist in der TR-03182 der Eintrag v=spf1 include:_spf1.bund.de ip4:93.190.68.25 -all der Domain bsi.bund.de abgedruckt, der auf die Festlegung des übergeordneten Netzes bund.de verweist, zusätzlich eine feste IP-Adresse nennt und alle übrigen Server ausschließt. Feste Adressen bevorzugt die Richtlinie gegenüber Hostnamen, weil der Empfänger dafür auf das Auflösen weiterer Namen verzichten kann. Die Prüfung läuft dadurch nach der TR schneller und stabiler ab und bleibt leichter unter der Grenze für DNS-Abfragen, die RFC 7208 vorgibt.
Wie empfangende Server SPF auswerten
Beim Eingang einer Nachricht fragt der empfangende Server den SPF-Eintrag der Absenderdomain ab und vergleicht die IP-Adresse des einliefernden Servers mit den dort genannten Quellen. RFC 7208 kennt sieben mögliche Ergebnisse, von „pass“ für einen berechtigten Server über „fail“ und „softfail“ bis zu „none“ für eine Domain ohne Eintrag. Die Ergebnisse „temperror“ und „permerror“ melden einen vorübergehenden DNS-Fehler beziehungsweise einen unauswertbaren Eintrag, der ein Eingreifen des Domaininhabers erfordert, während ein Eintrag ohne passenden Mechanismus und ohne all zum Ergebnis „neutral“ führt.
Über die Behandlung einer Nachricht entscheidet der Empfänger nach eigenen Regeln, da der Standard die Behandlung der einzelnen Ergebnisse der jeweiligen lokalen Richtlinie überlässt. Für „softfail“ hält RFC 7208 fest, dass eine Nachricht allein aufgrund dieses Ergebnisses nicht abgewiesen, wohl aber genauer geprüft werden soll. Google verlangt seit dem 1. Februar 2024 von allen Absendern an Gmail-Konten mindestens SPF oder DKIM und kann Nachrichten ohne Authentifizierung als Spam markieren oder mit dem Fehler 5.7.26 ablehnen. Dienste von Drittanbietern, die im Eintrag fehlen, führen nach Angaben von Google ebenfalls dazu, dass deren Nachrichten eher im Spam-Ordner erscheinen.
Grenzen und Fehlerquellen bei SPF
Je Domain ist ein einziger SPF-Eintrag zulässig, denn bei mehreren Einträgen liefert die Prüfung nach RFC 7208 das Ergebnis „permerror“. Nach Beobachtung des BSI in der Empfehlung „Upgrade für die E-Mail-Sicherheit“ (BSI-CS 155) entstehen solche Doppelungen, wenn die Anleitung eines externen Dienstes einen eigenen Eintrag nahelegt, obwohl dessen Angaben in den bestehenden Eintrag gehören. Als weitere Ursachen ungültiger Angaben nennt das BSI Anführungszeichen um den gesamten Eintrag sowie Tippfehler wie „inlcude“ anstelle von „include“.
Für die Auswertung gilt zudem eine Obergrenze von zehn Angaben mit DNS-Abfrage, zu denen nach RFC 7208 unter anderem die Mechanismen include, a und mx zählen. Wird diese Grenze überschritten, lautet das Ergebnis ebenfalls „permerror“, wobei Microsoft darauf hinweist, dass ein einzelnes include durch verschachtelte Verweise mehrere Abfragen verursachen kann. Feste Adressen nach ip4 und ip6 bleiben bei dieser Grenze unberücksichtigt, und Abfragen ohne verwertbare Antwort, im Standard „void lookups“ genannt, sollen Prüfprogramme nach RFC 7208 auf zwei begrenzen.
Eine Grenze anderer Art zeigt sich bei weitergeleiteten Nachrichten, weil SPF nach RFC 7208 die IP-Adresse des zuletzt einliefernden Servers bewertet und damit die Adresse des weiterleitenden Dienstes statt jener des ursprünglichen Absenders. Der Standard widmet diesen sogenannten Mediatoren deshalb einen eigenen Anhang mit möglichen Gegenmaßnahmen. Da SPF außerdem allein den Umschlagabsender prüft, stellt erst DMARC den Bezug zur sichtbaren Absenderadresse her, die laut Google mit der SPF- oder der DKIM-Domain übereinstimmen muss, damit eine Nachricht die DMARC-Prüfung besteht.
SPF für Subdomains und Domains ohne E-Mail-Versand
Der Eintrag der Hauptdomain erstreckt sich nach Angaben von Microsoft allein auf diese selbst, sodass etwa eine Subdomain für Marketing-E-Mails einen eigenen SPF-Eintrag benötigt. Bei Änderungen an den berechtigten Servern empfiehlt RFC 7208 eine Übergangszeit, in der die alte Festlegung gültig bleibt, bis alle zuvor verschickten Nachrichten geprüft sein dürften. Die Einrichtung in der DNS-Verwaltung des Hosters und die Kontrolle mit einer Testnachricht beschreibt der Ratgeber zu SPF, DKIM und DMARC, der auch das Kontaktformular der Webseite als eigene Versandquelle aufführt.
Auch eine Domain ohne E-Mail-Versand lässt sich mit SPF gegen Missbrauch absichern, indem der Eintrag v=spf1 -all sämtlichen Servern die Berechtigung abspricht. Microsoft beschreibt diesen Eintrag ausdrücklich für sogenannte geparkte Domains, die zwar registriert sind, aber weder für E-Mails noch für eine Webseite genutzt werden. Die TR-03182 verlangt für solche Domains zusätzlich einen Null-MX-Eintrag und eine DMARC-Richtlinie mit der Stufe „reject“. Am besten legen Sie diese Einträge gleich bei der Registrierung von Namensvarianten an, wie sie der Ratgeber Die passende Domain finden behandelt.