Sender Policy Framework

Grundidee und Funktionsweise

Das Sender Policy Framework (SPF; früher „Sender Permitted From“) soll verhindern, dass E-Mails über nicht legitimierte Mail Transfer Agents (MTAs, also versendende Mailserver) unter dem Namen einer fremden Domain verschickt werden. Dazu veröffentlicht der Domaininhaber im Domain Name System (DNS) die IP-Adressen der MTAs, die E-Mails für seine Domain senden dürfen. SPF entstand zur Abwehr von Spam und kann auch Phishing erschweren. Es bekämpft Spam jedoch nicht unmittelbar, sondern schützt vor bestimmten Fälschungen der Absenderadresse und erleichtert die Nachverfolgung.

Der Administrator hinterlegt die SPF-Regeln als Resource Record vom Typ TXT in der DNS-Zone. Der besondere SPF-Resource-Record wurde durch RFC 7208 für obsolet erklärt. Beim Empfang einer E-Mail ermittelt das Empfängersystem die Domain, die während der SMTP-Verbindung in MAIL FROM beziehungsweise HELO angegeben wurde. Es ruft deren SPF-Informationen aus dem DNS ab und vergleicht die IP-Adresse des sendenden MTA mit den erlaubten Adressen. Bei Übereinstimmung gilt der Sender als autorisiert; andernfalls kann die Nachricht verworfen oder negativ bewertet werden.

SPF ähnelt damit einem „Reverse-MX“: Ein MX-Eintrag gibt an, welcher Server E-Mails für eine Domain empfangen soll; ein SPF-Eintrag beschreibt, welche Server für sie senden dürfen. Geprüft wird allerdings die Umschlag-Absenderadresse aus MAIL FROM, nicht die normalerweise im E-Mail-Programm sichtbare From-Kopfzeile. Betrüger können diese sichtbare Angabe weiterhin fälschen. SPF verhindert daher nicht jede Täuschung, kann aber bei ihrer Erkennung helfen.

Nur das Empfängersystem muss die Prüfung unterstützen; am Übertragungsprotokoll SMTP ändert sich nichts. Die Veröffentlichung eines SPF-Records ist freiwillig. Nachrichten von Domains ohne SPF-Record sollen nach RFC 4408 nicht allein deshalb negativ eingestuft werden, doch die Domain bleibt dann gegen Fälschungen ihrer Umschlag-Absenderadresse ungeschützt.

Regeln eines SPF-Records

Ein SPF-Record beginnt mit der Versionsangabe „v=spf1“. Danach folgen Ausdrücke, die von links nach rechts ausgewertet werden. Die meisten sind Direktiven aus einem optionalen Qualifikator und einem Mechanismus. Der Mechanismus prüft, ob eine bestimmte Bedingung für die IP-Adresse des Senders erfüllt ist. Der erste passende Mechanismus bestimmt das Gesamtergebnis.

Die Qualifikatoren sind:

• „+“ bedeutet Pass und kennzeichnet autorisierte Sender. Es ist der Standard und wird angenommen, wenn kein Qualifikator angegeben ist.
• „-“ bedeutet Fail und kennzeichnet nicht autorisierte Sender.
• „~“ bedeutet Softfail: Der Sender ist nicht autorisiert, der Empfänger soll den Fehlschlag aber großzügig behandeln.
• „?“ bedeutet Neutral: Über die Legitimität des Senders wird keine Aussage getroffen; er muss so behandelt werden, als wäre kein Qualifikator angegeben.

Wichtige Mechanismen sind „all“ (trifft immer zu), „a“ (ein A- oder AAAA-Record der geprüften oder ausdrücklich angegebenen Domain enthält die Sender-IP), „mx“ (ein MX-Record enthält die Sender-IP), „ip4“ beziehungsweise „ip6“ (eine angegebene IPv4- oder IPv6-Adresse beziehungsweise ein Subnetz enthält die Sender-IP) und „include“ (eine zusätzliche SPF-Abfrage für eine andere Domain autorisiert die Sender-IP).

Daneben gibt es Modifier, also nur einmal erlaubte Attribute mit Zusatzinformationen. „redirect“ verweist zur vollständigen Auswertung auf den SPF-Record einer anderen Domain. „exp“ verweist auf eine Domain, deren TXT-Record dem Nutzer eine Erklärung für die Zurückweisung liefern kann.

Typisches Prüfbeispiel

In einem vereinfachten Fall sendet Mallory Spam an Bob und gibt „info@alice“ als gefälschte Absenderadresse an. Bob fragt den SPF-Eintrag der Domain von Alice ab. Dieser erlaubt ausschließlich die Alice zugeordnete IP-Adresse. Da Mallorys sendender Server nicht damit übereinstimmt, erkennt Bob den SPF-Verstoß und kann die Nachricht verwerfen.

Ein realer SPF-Record von GMX beginnt beispielsweise mit „v=spf1“ und nennt mehrere IPv4-Netze, darunter „ip4:213.165.64.0/23“ und „ip4:74.208.5.64/26“. Der erste Bereich umfasst 213.165.64.0 bis 213.165.65.255, der zweite 74.208.5.64 bis 74.208.5.127. Weitere Adressbereiche folgen. Der abschließende Ausdruck „-all“ erklärt alle anderen Server für nicht autorisiert, die Domain gmx.de in der Umschlag-Absenderadresse zu verwenden.

Einsatz und Standardisierung

SPF Version 1 besteht seit Ende 2003 größtenteils unverändert und war zunächst eine informelle Spezifikation. Am 28. April 2006 veröffentlichte die IETF SPFv1 als RFC 4408 mit dem Status „Experimental“. Die zuvor eingestellte IETF-Arbeitsgruppe „marid“ (MTA Authorization Records in DNS) hatte mehrere Verfahren behandelt, sich aber auf keines einigen können. Im April 2014 erschien RFC 7208 „Sender Policy Framework (SPF)“ als „Proposed Standard“. Im September 2014 ergänzte die IETF-Arbeitsgruppe „spfbis“ ihn durch RFC 7372, ebenfalls einen „Proposed Standard“.

Zu den bekannten unterstützenden E-Mail-Diensten gehörten 2020 unter anderem GMX und Web.de mit dem Qualifikator Fail, Arcor/Vodafone, AOL, Gmail, O₂ sowie Microsoft mit Hotmail und Outlook.com mit Softfail und Yahoo mit Neutral. GMX setzt SPF seit April 2004 produktiv ein. Nach dem Stand von 2020 nutzten außerdem alle Top-10-Websites in Deutschland SPF.

Auch Unternehmen können damit festlegen, wie Empfänger Nachrichten behandeln sollen, die zwar ihre Absender-Domain verwenden, aber von nicht autorisierten IP-Adressen stammen. Spamfilter wie SpamAssassin beziehen SPF-Prüfungen in ihre Bewertung ein. Eine erfolgreiche Prüfung hat in dessen Standardkonfiguration keinen Effekt, weil Spam-Versender dies nach Aussage der Entwickler ausnutzen könnten. Fehlgeschlagene Prüfungen können abhängig vom Fehlergrund die Bewertung beeinflussen. Viele Mailserver dokumentieren das Ergebnis im Mailheader, etwa mit „Received-SPF: pass“ oder einer Warnung über eine ausgeschlossene IP-Adresse.

Weiterleitungen und Webformulare

Bei einer E-Mail-Weiterleitung kann SPF eine legitime Nachricht fälschlich als unautorisiert einstufen. Das endgültige Empfängersystem sieht die ursprüngliche Absender-Domain zusammen mit der IP-Adresse des weiterleitenden Servers. Dieser steht gewöhnlich nicht im SPF-Record der ursprünglichen Domain.

Dafür werden drei Lösungswege genannt:

• Das Zielsystem kann bei bekannten Weiterleitungsdomains auf die SPF-Prüfung verzichten, beispielsweise durch Whitelisting. Dann sollte das weiterleitende System selbst prüfen. Bei einem Zustellungsfehler kann ein Bounce jedoch direkt an den ursprünglichen Absender gehen und ihm möglicherweise die Weiterleitungs-Zieladresse verraten.
• Das Weiterleitungssystem kann die Umschlag-Absenderadresse auf seine eigene Domain umschreiben und Verantwortung für die ursprüngliche Adresse und mögliche Bounces übernehmen. Ein entsprechendes Verfahren ist das Sender Rewriting Scheme (SRS). Voraussetzung ist eine wirksame SPF-Prüfung durch den Weiterleiter, die nicht immer erfolgt.
• Der sendende Server kann die Nachricht zunächst an einen erlaubten Server weitergeben. Dafür lassen sich sogenannte Satelliten-Mailserver einsetzen, die Daten vom Webserver an den eigenen Mailserver weiterleiten dürfen.

Ein ähnliches Problem entsteht bei Webformularen: Übernimmt ein Formular die vom Nutzer angegebene fremde E-Mail-Adresse als Umschlag-Absender, sendet der Webserver scheinbar im Namen dieser Domain. Hat sie SPF eingerichtet, kann die Nachricht gegen deren Regeln verstoßen und den Webseitenbetreiber möglicherweise nie erreichen.

Der Webserver sollte sich deshalb selbst als Absender ausweisen und seine eigene autorisierte Domain als Envelope Sender verwenden. Die Nutzeradresse kann im Nachrichtentext, im From-Header oder im Reply-To-Header stehen. SPF prüft den sichtbaren From-Header nicht. In Kombination mit DMARC würde eine fremde Adresse dort jedoch scheitern, weil DMARC den From-Header einbezieht. Der Reply-To-Header unterliegt keiner solchen Absenderprüfung und wird von gängigen E-Mail-Programmen für direkte Antworten unterstützt.

Grenzen, Kritik und ergänzende Verfahren

SPF ist besonders wegen seiner Auswirkungen auf nicht autorisierte MTAs umstritten. Endnutzer kennen häufig weder SPF noch die Notwendigkeit eines Whitelistings bei Weiterleitungen. Arbeitet ein Weiterleitungssystem ohne ausreichendes SRS, können Nachrichten aus SPF-geschützten Domains verloren gehen.

Die Beschränkung auf erlaubte Mailserver kann auch legitime Nutzung erschweren. Arbeitgeber, Universitäten und andere Netzbetreiber sperren mitunter ausgehende SMTP-Verbindungen, um Spam zu begrenzen oder den E-Mail-Verkehr zu kontrollieren. Dann kann ein Nutzer eventuell den autorisierten MTA seines privaten E-Mail-Dienstes nicht erreichen. Verwendet er stattdessen den nicht autorisierten lokalen MTA, widerspricht dies dem SPF-Record. Als mögliche Lösung nennt der Artikel einen Mail Submission Agent über einen nicht gesperrten Port oder einen anderen Zugang zum berechtigten MTA.

Gegen Spam und Schadsoftware wirkt SPF nur indirekt. Angreifer können Wegwerfdomains oder gekaperte „Zombie-Computer“ mit passenden SPF-Records verwenden. SPF ist kein allgemeiner Schutz einer E-Mail-Adresse, sondern schützt vor allem den Domaininhaber davor, dass nicht berechtigte SMTP-Relays E-Mails mit seiner Domain als Umschlag-Absender verschicken.

Rechtlich urteilte das OLG Karlsruhe, dass Teilnehmer am geschäftlichen E-Mail-Verkehr nicht berechtigt darauf vertrauen können, dass SPF eingesetzt wird. Ein fehlender SPF-Eintrag ist nach Auffassung des Gerichts kein Anscheinsbeweis für fehlende IT-Sicherheitsmaßnahmen.

Ergänzende Verfahren sind DomainKeys Identified Mail (DKIM), das eine E-Mail-Domain mithilfe kryptografischer Signaturen authentisiert, und Domain-based Message Authentication, Reporting and Conformance (DMARC). DMARC baut auf SPF und DKIM auf und ergänzt eine verbindliche Sender-Policy für den Umgang mit nicht authentischen E-Mails.