Sender Policy Framework

Das Sender Policy Framework (SPF; früher Sender Permitted From) ist ein Verfahren, mit dem das Fälschen der Absenderadresse einer E-Mail verhindert werden soll, genauer das Versenden von E-Mail über nicht legitimierte Mail Transfer Agents (MTAs) unterbindet. Es entstand als Verfahren zur Abwehr von Spam. Bei SPF trägt der Inhaber einer Domain in das Domain Name System ein, welche Adressen von MTAs zum Versand von E-Mails für diese Domain berechtigt sind.

Der Administrator einer Domain hinterlegt in der DNS-Zone einen Resource Record vom Typ TXT (der SPF Resource Record wurde durch RFC 7208 obsolet^[1]). In diesen Resource Records sind die IP-Adressen der Mail Transfer Agents (MTA) enthalten, die für die Domain E-Mails versenden dürfen. Der Empfänger prüft, ob der Absender zum Versand berechtigt ist. Hierzu prüft der Empfänger, welche Domain der Absender in den Feldern „MAIL FROM“ und „HELO“ in der SMTP-Verbindung angegeben hat. Für die angegebene Domain ruft der Empfänger die SPF-Information über das Domain Name System ab und vergleicht die IP-Adresse des sendenden MTAs mit den erlaubten Adressen. Stimmt die IP-Adresse überein, so ist der Absender authentisch, andernfalls kann die E-Mail verworfen werden.

Zu beachten ist, dass diese Überprüfung sich nicht auf die Kopfzeile "From" bezieht, welche normalerweise von E-Mail-Programmen als Absender angezeigt wird und zusätzlich auch einen Namen enthalten kann. SPF kann somit nicht davor schützen, dass Betrüger versuchen Verbraucher zu täuschen. Es kann jedoch helfen, diese zu ermitteln.

Im DNS-Eintrag einer Domäne sind bislang schon normale MX-Einträge vorhanden, die SMTP-Servern sagen, an welchen Host sie E-Mails für diese Domäne senden sollen. Wenn also ein SMTP-Server eine E-Mail an test@example.org schicken soll, sieht er im MX-Record von example.org nach, an welchen Server er die Mail schicken soll. Mit SPF wird nun ein Record im Stil eines Reverse-MX den DNS-Einträgen einer Domäne hinzugefügt. Empfängt ein Mailserver eine E-Mail mit einem Absender von example.org, sieht er im SPF-Record von example.org nach, ob der zustellende Mailserver laut SPF-Record dazu berechtigt ist, Mails für diese Domain zu versenden.

SPF kann so durch die leichtere Nachverfolgbarkeit von E-Mails auch zur Bekämpfung von Spam und zur Erschwerung von Phishing beitragen. SPF erhebt jedoch lediglich den Anspruch, Absenderadressfälschungen zu verhindern, nicht aber, direkt Spam zu bekämpfen.

SPF muss nur vom Empfängersystem unterstützt werden – am Protokoll der Mailübertragung (SMTP) ändert sich nichts. Die Veröffentlichung von SPF-Records ist für eine Domäne freiwillig, Mails von Domains ohne SPF-Records sollen laut SPF-Spezifikation (RFC 4408) von Empfängern nicht negativ eingestuft werden; allerdings bleiben solche Domänen naturgemäß wie bisher gegen Umschlag-Adressfälschungen ungeschützt.

Jeder SPF-Record beginnt mit einer Versionsnummer – für die aktuelle SPF-Version "v=spf1". Es folgen beliebig viele Ausdrücke, die in der Reihenfolge von vorne nach hinten ausgewertet werden. Die meisten Ausdrücke sind dabei sog. Direktiven, die die Autorisierung des Versenders definieren, und bestehen aus einem optionalen Qualifikator und einem sog. Mechanismus, der für eine gegebene Situation (IP-Adresse) entweder einen Treffer oder keinen Treffer ergibt. Der erste Mechanismus, der einen Treffer darstellt, bestimmt das Ergebnis der gesamten Auswertung des SPF-Records.

Es gibt folgende Qualifikatoren:

Folgende Tabelle zeigt einige gängige Mechanismen:

Einen Überblick über alle erlaubten Ausdrücke gibt die Unterseite der SPF-Website.^[2]

Neben den Direktiven gibt es Attribute (Modifier), die nur einmalig vorkommen können und zusätzliche Informationen bereitstellen:

$ host -t TXT gmx.de
gmx.de descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"

Die Firma GMX legt also fest, dass alle Hosts mit der IPv4-Adresse 213.165.64.0 bis 213.165.65.255, sowie 74.208.5.64 bis 74.208.5.127 und einige weitere Adressbereiche E-Mails von der Domäne gmx.de verschicken dürfen. Alle anderen Server sind laut diesem SPF-Record nicht für die Benutzung dieser Domäne in der Umschlag-Absenderadresse autorisiert.

SPF besteht in der Version 1 schon seit Ende 2003 größtenteils unverändert als informelle Spezifikation. Am 28. April 2006 wurde SPFv1 von der IETF als RFC 4408 veröffentlicht. Das RFC hat den Status „Experimental“, da die im Vorlauf eingestellte IETF-Arbeitsgruppe „marid“ („MTA Authorization Records in DNS“) mehrere zur Debatte stehende Verfahren bearbeitete, sich jedoch nicht auf eines der Verfahren einigen konnte. Im September 2014 veröffentlichte die IETF-Arbeitsgruppe „spfbis“ mit RFC 7372 eine überarbeitete Spezifikation als „Proposed Standard“.

Zu den bekanntesten Unterstützern von SPF gehören unter anderem (Stand 2020):

GMX setzt SPF bereits seit April 2004 produktiv ein. Andere große Provider wie zum Beispiel T-Online veröffentlichen keinen SPF-Record (Stand: Oktober 2019).

Spamfilter wie beispielsweise AMaViS nutzen SPF-Verifizierung zur Bewertung eingehender E-Mails.

Viele Mail-Betreiber informieren über eine erfolgte SPF-Verifikation im Mailheader, zum Beispiel durch das Einfügen einer Zeile

Received-SPF: pass (gmail.com: domain of foo@example.org designates 127.0.0.1 as permitted sender)

oder

X-Warning: SPF records of example.org exclude 127.0.0.2

Der Einsatz von SPF kann Probleme verursachen, wenn der Empfänger seine E-Mails an ein Postfach unterhalb einer anderen Domäne umleiten lässt: Das empfangende System sieht in diesem Fall die Domain des Absenders in Verbindung mit der IP-Adresse des umleitenden Systems. Letzteres wird jedoch typischerweise nicht von den SPF-Regeln erfasst sein, sodass eine solche Mail bei einer SPF-Prüfung als unautorisiert eingestuft wird.

Zu diesem Problem existieren drei Lösungsansätze:

1. Das empfangende System verzichtet auf die SPF-Prüfung von Mails der umleitenden Domains, sofern sie ihm bekannt sind – beispielsweise durch ein Whitelisting. Sinnvollerweise sollten in diesem Fall die weiterleitenden Systeme die SPF-Prüfung übernehmen. Ein Nachteil dieses Verfahrens ist, dass im Falle eines Zustellungsfehlers die Fehlermeldung (Bounce) direkt an den Absender gesandt wird. Dieser könnte so von der Zieladresse der Umleitung erfahren, was u. U. vom Empfänger unerwünscht ist.
2. Dieses Problem wird vermieden, wenn das Weiterleitungssystem die Umschlag-Absenderadressen der umgeleiteten Mails auf seine eigene Domäne umschreibt und so die Verantwortung für die Gültigkeit der ursprünglichen Absenderadresse und für die Zustellung eventueller Bounces übernimmt. Ein solches Verfahren ist z. B. das Sender Rewriting Scheme (SRS). Es muss allerdings sichergestellt sein, dass das weiterleitende System eine wirksame SPF-Prüfung vornimmt, was z. Zt. nicht immer der Fall ist.
3. Der sendende Server sendet die Daten erst an den erlaubten Mailserver weiter (relaying). Im Internet kann man hierzu sog. Satelliten-Mailserver nutzen, welche dann autorisiert sind Daten vom Webserver zu empfangen und diese an den eigenen Mailserver weiterzuleiten.

SPF kann bei einigen Webformularen mit schlechter Implementierung zu Problemen führen. So gibt es Webformulare, die den Namen und die E-Mail Adresse abfragen. Wenn das Webformular nun dem Webseitenbetreiber per Mail zugestellt wird, wird diese Mail fälschlicherweise so gestaltet, als ob sie direkt von der Person käme, die die Daten ausgefüllt hat. Es wird also als Absenderadresse die im Formular angegebene Adresse verwendet. Wenn die Domain dieser E-Mail Adresse nun mit SPF arbeitet und der Webseitenbetreiber selbst SPF-Prüfungen durchführt, wird das abgeschickte Formular möglicherweise nie beim Webseitenbetreiber eingehen. Der Webseitenbetreiber prüft in diesem Fall erfolglos seine eigene Berechtigung, im Namen der fremden Domain E-Mails zu versenden.

Dieses Problem lässt sich vermeiden, wenn sich der Webserver selbst als Absender der Mail identifiziert und seine eigene, berechtige Domain für den Versand der E-Mail nutzt. Der gewünschte Absender kann aber im From-Header der Mail hinterlegt werden. Der Effekt ist, dass Antworten auf die E-Mail automatisch an den Formularausfüller gehen und dieser auch als Absender des Mailinhalts angezeigt wird, die SPF-Prüfung aber nicht fehlschlägt, da der Webserver korrekt als tatsächlicher Absender genannt wird. Diese würde auch die Bounce-Mails erhalten.

Im Bereich der Nutzung von nicht autorisierten Mail Transfer Agents (MTAs) für die mit SPF geschützten Domain ist SPF ein kontrovers diskutiertes Verfahren.

• Endbenutzer haben im Allgemeinen keine Kenntnis von der Existenz von SPF und der Notwendigkeit, bei Umleitung Whitelisting einzuschalten. Bei der Einrichtung einer E-Mail-Umleitung an einem System, welches unzureichend ohne Sender Rewriting Scheme (SRS) arbeitet, bekommen Benutzer keine E-Mails aus SPF-geschützten Domains mehr zugestellt.
• Durch die Einschränkung der erlaubten MTA-Adressen einer Domain werden auch verschiedene Nutzungsszenarien eingeschränkt welche üblicherweise im Bereich des Spam-Versand angewendet werden und daher unterbunden werden. Im lokalen Netz des Arbeitgebers, der Universität und dergleichen können ausgehende SMTP-Verbindungen durch die Firewall unterbunden sein. Das geschieht, um Spamversand aus dem Netz heraus einzuschränken oder den ausgehenden E-Mail-Verkehr kontrollieren zu können. Möchte ein Benutzer in diesem Netz seine private E-Mail-Adresse verwenden, so kann er keine SMTP-Verbindung zum berechtigten MTA seiner privaten E-Mail-Dienstes aufbauen. Setzt der private E-Mail-Provider SPF ein und setzt der Benutzer den nicht berechtigten MTA des lokalen Netzbetreibers wie des Arbeitgeber ein, entspricht dieses Verhalten der Methode welche Spamer verwenden um über offene Mail-Relays Spam-Nachrichten zu versenden. Eine mögliche Lösung ist die Verwendung eines Mail Submission Agents, dessen Port nicht von der lokalen Firewall blockiert wird oder ein entsprechender anderer Zugang zum berechtigten MTA.
• SPF greift nur indirekt gegen Spam sowie Malware, da Spammer „Wegwerfdomains“ und die E-Mail-Systeme gekaperter „Zombie-Computer“ mit deren korrekten SPF-Records verwenden. SPF ist auch kein Adressschutz, sondern vielmehr ein Schutz des Domaininhabers, dass für das Versenden von E-Mails mit seiner Domainabsenderadresse nur die für diese Domain berechtigten MTAs verwendet werden, also ein Art Schutz vor der Verwendung von für die betreffende Domain unberechtigten SMTP-Relays.

• Website mit technischen Erläuterungen und Hinweisen für DNS-Administratoren (englisch)
• SPF-Einträge überprüfen (englisch)
• SPF Generator und deutsche Referenzseite zu SPF-Informationen
• RFC 4408: Sender Policy Framework, Version 1 (englisch)
• iPhone App (englisch)

• SPF considered harmful (englisch)
• Problems with Designated Sender (englisch)

• DomainKeys

1. ↑ RFC 7208, Abschnitt 3.1
2. ↑ SPF Record Syntax