SPF (Sender Policy Framework)

Definition: Das Sender Policy Framework (SPF) ist ein E-Mail-Authentifizierungsprotokoll, das Domaininhaber in die Lage versetzt, per DNS-TXT-Eintrag festzulegen, welche Mail-Server autorisiert sind, E-Mails im Namen ihrer Domain zu versenden. Empfangende Mailserver können anhand dieses Eintrags überprüfen, ob eine eingehende E-Mail tatsächlich von einem autorisierten Server stammt oder ob es sich um einen Fälschungsversuch handelt. SPF ist damit eine der grundlegenden Schutzmaßnahmen gegen E-Mail-Spoofing, Phishing und Domain-Missbrauch. Im E-Mail-Marketing ist ein korrekt konfigurierter SPF-Eintrag keine optionale Zusatzmaßnahme, sondern eine absolute Grundvoraussetzung für gute Zustellbarkeit. Die großen E-Mail-Anbieter wie Google, Microsoft und Yahoo haben die Anforderungen an E-Mail-Authentifizierung in den vergangenen Jahren deutlich verschärft: Seit Anfang 2024 verlangen Google und Yahoo für Massenversender explizit das Vorhandensein gültiger SPF-, DKIM- und DMARC-Einträge. Fehlt der SPF-Eintrag oder ist er fehlerhaft konfiguriert, riskiert der Absender erhöhte Spam-Filterquoten bis hin zur vollständigen Blockierung seiner E-Mails. SPF wurde im RFC 7208 standardisiert und ist mittlerweile ein universell unterstütztes Protokoll in der E-Mail-Infrastruktur. Es arbeitet auf der Ebene des sogenannten "Envelope From" (Return-Path), also der technischen Absenderadresse, nicht der sichtbaren "From"-Adresse des E-Mail-Clients. Diese Unterscheidung ist für das Verständnis der Grenzen des SPF-Protokolls wichtig: Angreifer können die sichtbare Absenderadresse weiterhin fälschen, auch wenn SPF korrekt implementiert ist – weshalb DKIM und DMARC als ergänzende Protokolle zwingend notwendig sind. Zusammen bilden SPF, DKIM und DMARC das Fundament moderner E-Mail-Authentifizierung, das sowohl die Zustellbarkeit legitimer E-Mails verbessert als auch den Missbrauch der eigenen Domain durch Dritte wirksam einschränkt.

Erläuterung

Der SPF-Mechanismus funktioniert über das Domain Name System (DNS). Der Domaininhaber hinterlegt in der DNS-Zone seiner Domain einen TXT-Eintrag, der eine Liste autorisierter Mailserver enthält. Diese Liste kann IP-Adressen, IP-Adressbereiche in CIDR-Notation oder Verweise auf die SPF-Einträge anderer Domains über den include-Mechanismus umfassen. Wenn ein empfangender Mailserver eine E-Mail erhält, führt er einen DNS-Lookup durch, um den SPF-Eintrag der versendenden Domain abzurufen. Er prüft dann, ob die IP-Adresse des sendenden Servers in der autorisierten Liste enthalten ist. Das Ergebnis dieser Prüfung lautet entweder "Pass" (autorisiert), "Fail" (nicht autorisiert), "SoftFail" (wahrscheinlich nicht autorisiert), "Neutral" (keine Aussage) oder "TempError"/"PermError" bei technischen Problemen. Ein "Fail"-Ergebnis allein führt nicht automatisch zur Ablehnung der E-Mail – die endgültige Entscheidung liegt beim empfangenden Mailserver und wird durch seine Konfiguration sowie durch DMARC-Richtlinien beeinflusst. Im praktischen E-Mail-Marketing entsteht die größte Fehlerquelle beim SPF durch den Einsatz mehrerer Drittanbieter-Dienste: Neben dem primären ESP nutzen viele Unternehmen separate Tools für Transaktions-E-Mails, CRM-Benachrichtigungen oder Marketing-Automation. Jeder dieser Dienste muss im SPF-Eintrag explizit als autorisierter Absender hinterlegt werden. Da SPF eine maximale DNS-Lookup-Tiefe von 10 Abfragen vorschreibt, können bei zu vielen include-Mechanismen Fehler entstehen, die als "PermError" zurückgegeben werden – was dazu führt, dass der SPF-Eintrag de facto ungültig wird. Die Lösung liegt in der regelmäßigen Überprüfung und ggf. Konsolidierung der SPF-Einträge sowie im Einsatz von SPF-Flattening-Tools, die mehrere DNS-Lookups auf feste IP-Adressen reduzieren. Ein weiterer häufiger Fehler ist das Vorhandensein mehrerer SPF-TXT-Einträge für dieselbe Domain – nur ein einziger SPF-Eintrag pro Domain ist zulässig, mehrere führen zu einem PermError und damit zu Zustellungsproblemen.

Aufbau eines SPF-Eintrags

v=spf1: Die obligatorische Versionsangabe, die den TXT-Eintrag als SPF-Eintrag kennzeichnet. Sie muss am Anfang jedes SPF-Eintrags stehen.
ip4 / ip6: Direktes Whitelisting einer IPv4- oder IPv6-Adresse oder eines Adressbereichs als autorisierter Absender, zum Beispiel ip4:192.168.1.0/24.
include: Verweis auf den SPF-Eintrag eines Drittanbieters, zum Beispiel include:_spf.google.com für Google Workspace. Jeder include-Verweis erzeugt einen DNS-Lookup und zählt gegen das Limit von 10.
a / mx: Autorisiert die IP-Adressen, die im A-Record bzw. MX-Record der Domain hinterlegt sind, als Absender.
~all / -all: Der abschließende "all"-Mechanismus definiert, wie mit E-Mails umzugehen ist, die von keinem der gelisteten Server stammen. ~all (SoftFail) empfiehlt Ablehnung, -all (Fail) fordert strikte Ablehnung. +all sollte niemals verwendet werden.

SPF im Zusammenspiel mit DKIM und DMARC

Ergänzung durch DKIM: SPF authentifiziert den sendenden Server, DKIM authentifiziert den E-Mail-Inhalt durch eine kryptografische Signatur. Beide Protokolle zusammen bieten deutlich mehr Schutz als jedes einzeln.
DMARC-Abhängigkeit: DMARC baut auf SPF und DKIM auf. Für ein DMARC-Pass muss mindestens eines der beiden Protokolle bestehen und mit der sichtbaren "From"-Domain übereinstimmen (Alignment). Ohne funktionierendes SPF schlägt DMARC im SPF-Alignment-Check fehl.
Forwarding-Problem: SPF hat eine bekannte Schwäche bei E-Mail-Weiterleitungen: Wenn eine E-Mail weitergeleitet wird, ändert sich die sendende IP-Adresse – dadurch schlägt der SPF-Check beim Empfänger fehl. DKIM ist in solchen Szenarien robuster, da die kryptografische Signatur auch nach der Weiterleitung gültig bleibt.
Delegierung für ESPs: Viele professionelle ESPs empfehlen, ihre eigene Domain per include in den SPF-Eintrag des Kunden aufzunehmen oder eine eigene Subdomain als Absender-Domain zu verwenden, was die Kontrolle und Reputation des Kunden stärkt.

Praxistipp: Inventarisieren Sie zunächst alle Dienste, die E-Mails im Namen Ihrer Domain versenden – von ESP über CRM bis hin zu automatischen System-E-Mails – und stellen Sie sicher, dass jeder davon im SPF-Eintrag Ihrer Domain aufgeführt ist. Überprüfen Sie anschließend mit einem SPF-Check-Tool wie MXToolbox oder dmarcian, ob Ihr Eintrag gültig ist und das DNS-Lookup-Limit von 10 nicht überschreitet. Endet Ihr SPF-Eintrag mit ~all (SoftFail), erwägen Sie nach vollständiger Implementierung von DKIM und DMARC den Wechsel zu -all (Fail), da dies eine stärkere Authentifizierungsaussage darstellt und besseren Schutz gegen Missbrauch Ihrer Domain bietet.