Täglich werden Millionen von E-Mails mit gefälschten Absenderadressen verschickt. Cyberkriminelle geben sich als Ihre Domain aus, um Ihre Kunden, Mitarbeiter und Partner zu täuschen. Sender Policy Framework – kurz SPF – ist eine der ältesten und am weitesten verbreiteten Schutzmaßnahmen dagegen. Zu verstehen, wie SPF funktioniert, was es kann und was nicht, und warum es besonders im Kontext von DMARC eine entscheidende Rolle spielt, ist für jede Organisation, die ihre E-Mail-Sicherheit ernst nimmt, unverzichtbar.
Was ist SPF?
Sender Policy Framework ist ein E-Mail-Authentifizierungsstandard, der in RFC 7208 beschrieben ist. Er ermöglicht es dem Inhaber einer Domain, im DNS eine Liste von Mailservern und IP-Adressen zu veröffentlichen, die berechtigt sind, E-Mails im Namen dieser Domain zu versenden. Wenn ein empfangender Mailserver eine E-Mail erhält, kann er diese Liste abfragen und prüfen, ob der sendende Server darauf steht.
SPF arbeitet auf Umschlagebene – genauer gesagt an der MAIL FROM-Adresse (auch als Return-Path oder Envelope-Sender bezeichnet). Das ist die Adresse, die der sendende Server bei der SMTP-Transaktion verwendet – sie entspricht nicht zwingend der Adresse, die Sie im E-Mail-Client im „Von"-Feld sehen. Dieser Unterschied ist entscheidend und wird relevant, wenn wir weiter unten DMARC-Alignment besprechen.
Allein für sich ist SPF ein nützlicher erster Filter. Er hat jedoch bekannte Grenzen, weshalb er am besten in Kombination mit DKIM und unter der Kontrolle von DMARC eingesetzt wird.
Wie SPF funktioniert – Schritt für Schritt
Wenn ein Mailserver eine eingehende Nachricht empfängt, läuft die SPF-Prüfung wie folgt ab:
- Der empfangende Server extrahiert die Domain aus der MAIL FROM-Adresse (Envelope-Sender) der SMTP-Transaktion. Falls MAIL FROM leer ist – was bei Zustellstatusbenachrichtigungen vorkommen kann – wird stattdessen die HELO/EHLO-Domain verwendet (HELO-Scope).
- Der empfangende Server führt eine DNS-TXT-Abfrage für den SPF-Record an dieser Domain durch,
zum Beispiel
_spf.example.comoder direkt beiexample.com. - Der Server wertet die Mechanismen im SPF-Record der Reihe nach aus –
ip4,ip6,include,a,mxusw. – und prüft, ob die sendende IP-Adresse mit einem davon übereinstimmt. - Sobald eine Übereinstimmung gefunden wird, bestimmt der zugehörige Qualifier (
+,-,~oder?) das Ergebnis: pass, fail, softfail oder neutral. Falls kein Mechanismus übereinstimmt, liefert derall-Mechanismus am Ende das Standardergebnis. - Das Ergebnis wird in die E-Mail-Header aufgenommen und kann vom empfangenden Server genutzt werden, um die Nachricht zuzustellen, zu quarantänisieren oder abzulehnen.
Aufbau eines SPF-Records
Ein SPF-Record ist ein DNS-TXT-Eintrag, der an Ihrer Domain veröffentlicht wird. Er beginnt immer
mit v=spf1 und endet mit einem all-Mechanismus. Ein typisches
Beispiel:
v=spf1 include:_spf.google.com include:mailgun.org ip4:203.0.113.10 ~all
Die wichtigsten Bestandteile sind:
| Mechanismus / Modifier | Funktion | Beispiel |
|---|---|---|
v=spf1 |
Deklariert den Eintrag als SPF Version 1. Pflicht als erster Tag. | v=spf1 |
ip4 / ip6 |
Autorisiert eine bestimmte IPv4- oder IPv6-Adresse oder CIDR-Range. | ip4:203.0.113.0/24 |
include |
Importiert den SPF-Record einer anderen Domain (z. B. eines ESPs oder Cloud-Dienstes). | include:_spf.google.com |
a |
Gleicht die A- (oder AAAA-) Adresse der Domain ab – also die IP des Webservers. | a |
mx |
Gleicht die IPs der MX-Records der Domain ab – die eingehenden Mailserver. | mx |
redirect |
Ersetzt den aktuellen Record vollständig durch den SPF-Record einer anderen Domain. | redirect=_spf.example.com |
all |
Catch-All am Ende. Der Qualifier bestimmt das Ergebnis für alles, was zuvor nicht gematcht wurde. | -all (fail), ~all (softfail) |
Die Qualifier vor jedem Mechanismus bedeuten:
+(Standard, pass) – die sendende IP ist autorisiert.-(fail) – die sendende IP ist ausdrücklich nicht autorisiert.~(softfail) – die sendende IP ist wahrscheinlich nicht autorisiert; als weiche Warnung gedacht.?(neutral) – es wird keine Aussage über die sendende IP gemacht.
SPF-Ergebnisse erklärt: pass, fail, softfail, neutral und mehr
Die SPF-Prüfung liefert eines der folgenden Ergebnisse:
| Ergebnis | Bedeutung | Typische Ursache |
|---|---|---|
pass |
Die sendende IP ist durch den SPF-Record autorisiert. | Alle legitimen Absender korrekt konfiguriert. |
fail |
Die sendende IP ist ausdrücklich nicht autorisiert (-all). |
Gefälschte E-Mail oder ein legitimer Absender fehlt im SPF. |
softfail |
Die sendende IP ist wahrscheinlich nicht autorisiert (~all). Zustellung
kann trotzdem erfolgen.
|
Übergangsphase oder fehlender Absender. |
neutral |
Die Domain macht keine Aussage über die sendende IP (?all). |
Bewusst unverbindlicher Record – selten in Produktion. |
none |
Kein SPF-Record für die Domain gefunden. | SPF noch nicht eingerichtet oder keine TXT-Einträge vorhanden. |
temperror |
Vorübergehender DNS-Fehler während der Auswertung. | DNS-Ausfall, Timeout oder temporäres Resolver-Problem. |
permerror |
Dauerhafter Fehler im SPF-Record (Syntaxfehler, zu viele DNS-Lookups). | Falsch konfigurierter Record oder das 10-Lookup-Limit überschritten. |
Nur ein pass-Ergebnis kann SPF für DMARC-Zwecke erfüllen – aber das ist nur die
halbe Wahrheit. Die Domain muss auch aligniert sein.
SPF und DMARC – Alignment ist entscheidend
Hier entsteht bei vielen Administratoren Verwirrung. SPF kann einwandfrei bestehen – die sendende IP steht im SPF-Record – und trotzdem kann DMARC fehlschlagen. Der Grund: SPF-Alignment.
DMARC prüft, ob die durch SPF authentifizierte Domain (die MAIL FROM / Envelope-From-Domain) mit der Domain in der sichtbaren Header-From-Adresse übereinstimmt – also der Adresse, die Ihre Empfänger im Posteingang sehen. Zwei Modi stehen zur Verfügung:
- Relaxed Alignment (
aspf=r, Standard) – die organisatorischen Domains müssen übereinstimmen. Zum Beispiel aligniertbounce.example.commitexample.com. - Strict Alignment (
aspf=s) – die Domains müssen identisch sein.bounce.example.comaligniert nicht mitexample.com.
Viele E-Mail-Dienstleister (ESPs) und Cloud-Plattformen verwenden beim Versand in Ihrem Namen ihre eigene Domain als MAIL FROM-Adresse. Google Workspace, Amazon SES, Mailchimp, HubSpot – sie alle verhalten sich unterschiedlich. In manchen Fällen erfolgt der SPF-Pass für deren Domain, die nicht mit Ihrer Header-From-Domain übereinstimmt, und DMARC-SPF schlägt fehl, obwohl roh-SPF besteht.
Wie DMARCFlow SPF-Alignment in DMARC-Reports erklärt
DMARC-XML-Reports zu lesen ist mühsam. Die Rohdaten sagen Ihnen, ob SPF bestanden hat oder nicht, aber nicht warum das für DMARC relevant ist. DMARCFlow analysiert jeden Datensatz in jedem DMARC-Aggregate-Report und führt eine dedizierte SPF-Insight-Analyse durch, die das Rohergebnis in verständliche Sprache übersetzt. Es gibt fünf mögliche Szenarien:
| Szenario | Bedeutung |
|---|---|
| MAIL FROM aligniert bestanden | SPF hat im MAIL FROM-Scope bestanden und die authentifizierte Domain aligniert mit Ihrer Header-From. Das ist das ideale Ergebnis — DMARC-SPF ist erfüllt. |
| MAIL FROM bestanden, nicht aligniert | SPF hat für eine MAIL FROM-Domain bestanden, aber diese Domain entspricht nicht der Header-From unter dem konfigurierten Alignment-Modus. DMARC-SPF schlägt trotz des SPF-Pass fehl. |
| Nur HELO bestanden | Nur die HELO/EHLO-Domain hat einen SPF-Pass geliefert. DMARC wertet HELO nicht für Alignment aus, daher kann dies DMARC-SPF nicht erfüllen. |
| MAIL FROM-Ergebnis kein Pass | Ein MAIL FROM-SPF-Ergebnis war vorhanden, aber es war fail,
softfail, neutral, none, temperror
oder permerror. Keines davon erfüllt DMARC.
|
| Keine relevanten SPF-Ergebnisse | Es wurden keinerlei MAIL FROM- oder HELO-SPF-Ergebnisse gefunden. Ohne SPF-Auswertung kann DMARC-SPF nicht erfüllt werden. |
Statt sich durch kryptisches XML zu kämpfen, zeigt Ihnen DMARCFlow für jede sendende Quelle in Ihren Reports genau, welches Szenario zutrifft — inklusive der authentifizierten Domain, der Header-From-Domain und ob das Alignment erfolgreich war. So lassen sich falsch konfigurierte Absender schnell identifizieren und gezielt beheben.
Häufige SPF-Probleme und wie man sie behebt
Die meisten SPF-Probleme fallen in einige wiederkehrende Kategorien:
- Fehlende Absender. Sie haben einen neuen E-Mail-Dienst hinzugefügt (CRM, Marketingplattform oder transaktionaler E-Mail-Anbieter), aber vergessen, ihn in Ihren SPF-Record aufzunehmen. E-Mails von diesem Dienst scheitern an SPF für Ihre Domain.
- Alignment-Mismatch. Ihr ESP verwendet seine eigene Domain im MAIL FROM-Feld. SPF besteht für die ESP-Domain, aber DMARC-SPF schlägt fehl, weil die ESP-Domain nicht mit Ihrer Header-From aligniert. Die Lösung besteht meist darin, beim ESP eine eigene MAIL FROM- (Return-Path-)Domain zu konfigurieren, die Ihrer eigenen Domain entspricht.
- Weitergeleitete E-Mails. Wenn E-Mails von Dritten weitergeleitet werden, ändert sich die sendende IP. Der neue sendende Server steht nicht in Ihrem SPF-Record, daher schlägt SPF fehl. Das ist eine grundlegende Einschränkung von SPF — DKIM geht mit Weiterleitungen besser um, da es auf einer kryptografischen Signatur statt auf der sendenden IP basiert.
- Softfail statt Fail. Wenn Sie am Ende Ihres SPF-Records
~allverwenden, liefern unauthentifizierte Nachrichten einen Softfail statt einen Hard-Fail. Das ist bei der Ersteinrichtung sicherer, erzwingt aber keine strikte Ablehnung. Wechseln Sie zu-all, sobald Sie sicher sind, dass alle legitimen Absender erfasst sind. - Mehrere SPF-Records. Eine Domain darf genau einen SPF-TXT-Record haben. Bei
zwei Records geben auswertende Mailserver einen
permerrorzurück und SPF schlägt fehl. Fassen Sie alle Mechanismen in einem einzigen Record zusammen. - Überschreitung des 10-Lookup-Limits. Siehe nächsten Abschnitt.
SPF-Grenzen: Die 10-Lookup-Falle
SPF hat ein hartes Limit: Die Auswertung eines einzelnen Records darf nicht mehr als 10
DNS-Lookups auslösen. Mechanismen, die Lookups verursachen, sind include,
a, mx, ptr und exists. Wird dieses Limit
überschritten, ergibt sich ein permerror, was für DMARC-Zwecke einem SPF-Fehler
entspricht.
Das ist ein verbreitetes Problem für Organisationen, die viele Drittanbieterdienste nutzen. Jedes
include zählt als ein Lookup, aber auch die verschachtelten Includes
innerhalb dieser Domain zählen. Google Workspace hat beispielsweise eigene verschachtelte
Includes in _spf.google.com. Fügen Sie drei oder vier große ESPs hinzu, nähern Sie
sich schnell dem Limit oder überschreiten es.
Die Lösung besteht darin, Ihren SPF-Record zu flattenen – also include-Referenzen
durch die tatsächlichen IP-Ranges zu ersetzen, auf die sie zeigen – oder einen verwalteten
SPF-Dienst zu nutzen, der einen geflatteneten Record automatisch aktuell hält. DMARCFlow erkennt
permerror-Ergebnisse in Reports und identifiziert, wenn das Lookup-Limit die
Ursache ist.
Wie DMARCFlow SPF-Komplexität verständlich macht
SPF in der Theorie zu verstehen ist eine Sache. Im Kontext echter E-Mail-Ströme über Dutzende von Absenderdiensten und Domains darauf zu reagieren ist eine andere. Hier liefert DMARCFlow echten Mehrwert.
DMARCFlow ist eine DMARC-Monitoring- und -Reporting-Plattform, die darauf ausgerichtet ist, E-Mail-Authentifizierung verständlich und handlungsorientiert zu machen. Bei SPF bietet DMARCFlow konkret:
- SPF-Insight-Analyse je Datensatz. Jeder Datensatz in jedem DMARC-Report wird einzeln analysiert. DMARCFlow stellt nicht nur fest, ob DMARC-SPF bestanden oder versagt hat, sondern warum – und ordnet ihn einem der fünf oben beschriebenen Szenarien zu: alignierter MAIL FROM-Pass, nicht-alignierter MAIL FROM-Pass, nur HELO-Pass, nicht-bestehender MAIL FROM-Ergebnis oder keine relevanten SPF-Ergebnisse.
-
Alignment-Modus-Bewusstsein. DMARCFlow liest den
aspf-Tag aus Ihrer tatsächlichen DMARC-Richtlinie aus und bewertet jedes SPF-Ergebnis gegen den korrekten Alignment-Modus – relaxed oder strict – sodass die Analyse stets Ihre reale Konfiguration widerspiegelt. - Authentifizierungsfehler-Analyse. Wenn SPF-Fehler über mehrere Datensätze auftreten, gruppiert sie DMARCFlow, berechnet Fehlerquoten und zeigt die wichtigsten fehlschlagenden Quellen – damit Sie genau wissen, welche IP-Adressen und Absender zuerst untersucht werden müssen.
- Policy-Validierung. DMARCFlow prüft Ihre DMARC-Richtlinie auf Konsistenzprobleme – etwa ob Ihr Alignment-Modus zu Ihrer Sendeinfrastruktur passt und ob Ihre Durchsetzungsstufe (none / quarantine / reject) mit den beobachteten Pass-Raten übereinstimmt.
- Maturity Level Tracking. DMARCFlow weist Ihrer Domain einen DMARC-Reifegrad von 0 (kein Schutz) bis 5 (maximaler Schutz mit strictem Alignment und vollständiger Reject-Durchsetzung) zu. SPF-Alignment ist ein direkter Faktor: Wenn Ihr SPF nicht korrekt aligniert ist, ist das Erreichen höherer Reifegradstufen blockiert — und DMARCFlow zeigt Ihnen genau warum.
- Security Score mit Komponenten-Aufschlüsselung. Jede Domain erhält einen Security Score von 100. Die Aufschlüsselung macht transparent, wie SPF, DKIM, Policy-Durchsetzung, Abdeckung und Reporting jeweils zum Gesamtscore beitragen – oder ihn mindern.
- Empfehlungs-Engine. Basierend auf Ihren tatsächlichen Daten generiert DMARCFlow priorisierte, handlungsorientierte Empfehlungen. Wenn Ihr SPF aufgrund eines nicht-alignierten MAIL FROM bei einem bestimmten ESP fehlschlägt, erklärt DMARCFlow, was zu konfigurieren ist und wie.
- DSGVO-konform, EU-gehostet. Alle Report-Daten werden ausschließlich innerhalb der Europäischen Union verarbeitet und gespeichert. Es werden keine personenbezogenen Daten vorgehalten. Das ist entscheidend für Organisationen, die der DSGVO unterliegen oder Daten von EU-Bürgerinnen und -Bürgern verarbeiten.
Fazit
SPF ist ein fundamentaler Baustein der E-Mail-Authentifizierung. Es legt fest, welche Server berechtigt sind, E-Mails für Ihre Domain zu versenden, und gibt empfangenden Mailservern die Möglichkeit, diese Angabe zu verifizieren. Doch SPF allein reicht nicht aus — es versagt bei Weiterleitungen, es operiert nur auf Umschlagebene, und sein Wert für DMARC hängt vollständig davon ab, ob die authentifizierte Domain mit der Header-From-Adresse aligniert ist, die Ihre Empfänger tatsächlich sehen.
Die fünf SPF-Alignment-Szenarien zu verstehen — von einem sauberen, alignierten Pass bis zu einem HELO-only-Ergebnis ohne DMARC-Wert — ist das, was Organisationen unterscheidet, die lediglich einen SPF-Record haben, von solchen, die ihre E-Mails wirklich gesichert haben. Der Weg von „SPF existiert" zu „DMARC mit SPF-Alignment durchgesetzt" erfordert Einblick in das, was tatsächlich in Ihren Mail-Strömen passiert.
DMARCFlow liefert genau diesen Einblick. Es analysiert Ihre DMARC-Reports, klassifiziert jedes SPF-Ergebnis nach Alignment-Szenario, hebt Fehlermuster hervor und gibt Ihnen gezielte Empfehlungen, um die Lücken zu schließen. Ob Sie gerade erst mit E-Mail-Authentifizierung beginnen oder bereits auf Quarantine-Policy laufen und zu Reject wechseln möchten — DMARCFlow gibt Ihnen die nötige Klarheit, um sicher voranzugehen.
E-Mail-Bedrohungen immer einen Schritt voraus
Praxisnahe E-Mail-Sicherheits-Insights zu SPF, DKIM, DMARC und mehr — direkt in Ihr Postfach. Kein Spam, jederzeit abbestellbar.