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:

  1. 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).
  2. Der empfangende Server führt eine DNS-TXT-Abfrage für den SPF-Record an dieser Domain durch, zum Beispiel _spf.example.com oder direkt bei example.com.
  3. Der Server wertet die Mechanismen im SPF-Record der Reihe nach aus – ip4, ip6, include, a, mx usw. – und prüft, ob die sendende IP-Adresse mit einem davon übereinstimmt.
  4. Sobald eine Übereinstimmung gefunden wird, bestimmt der zugehörige Qualifier (+, -, ~ oder ?) das Ergebnis: pass, fail, softfail oder neutral. Falls kein Mechanismus übereinstimmt, liefert der all-Mechanismus am Ende das Standardergebnis.
  5. 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 aligniert bounce.example.com mit example.com.
  • Strict Alignment (aspf=s) – die Domains müssen identisch sein. bounce.example.com aligniert nicht mit example.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 ~all verwenden, 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 permerror zurü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.
Ist Ihr SPF korrekt mit DMARC aligniert?
Führen Sie einen kostenlosen Scan durch und sehen Sie Ihre SPF-Ergebnisse, den Alignment-Status und Ihren Security Score in Sekunden.
SPF prüfen

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.