SPF (Sender Policy Framework): E-Mail-Authentifizierung gegen Spoofing

SPF (Sender Policy Framework) ist ein DNS-basiertes E-Mail-Authentifizierungsprotokoll, das seit RFC 7208 (2014) standardisiert ist. Es erlaubt Domain-Inhabern, in einem DNS TXT-Record explizit festzulegen, welche Mailserver berechtigt sind, E-Mails im Namen ihrer Domain zu versenden. Empfangende Mailserver prüfen diesen Record und können unautorisierte Absender erkennen und ablehnen.

SPF ist, zusammen mit DKIM und DMARC, eine der drei grundlegenden Säulen moderner E-Mail-Authentifizierung und der erste Schritt gegen E-Mail-Spoofing.

Das Grundproblem: Warum SPF nötig ist

Das SMTP-Protokoll wurde 1982 ohne Authentifizierungsmechanismen entworfen. Jeder Mailserver kann technisch eine E-Mail mit einer beliebigen Absenderdomain versenden - es gibt keinen eingebauten Mechanismus, der prüft, ob der sendende Server dazu berechtigt ist. Diesen Konstruktionsfehler nutzen Angreifer systematisch aus:

Phishing-Kampagnen: E-Mails scheinbar von info@ihre-bank.de oder support@microsoft.com
CEO-Fraud: Aufforderungen zu Überweisungen im Namen des Geschäftsführers
Marken-Missbrauch: Spam und Malware im Namen legitimer Unternehmen
Spear-Phishing: Gezielte Angriffe auf Mitarbeiter mit bekannten Absenderadressen

SPF adressiert dieses Problem, indem es dem DNS eine vertrauenswürdige Liste autorisierter Mailserver hinzufügt.

Wie SPF funktioniert

Der Prüfablauf Schritt für Schritt

SPF arbeitet auf DNS-Ebene und prüft den technischen Absender einer E-Mail - den sogenannten Envelope-From (auch MAIL FROM oder Return-Path genannt), nicht den sichtbaren From:-Header, den der Empfänger im Postfach sieht.

Die E-Mail trifft beim empfangenden Mailserver ein. Der Envelope-From (MAIL FROM) lautet absender@beispiel.de, die sendende IP-Adresse ist 203.0.113.42.
Der empfangende Server extrahiert die Domain aus dem Envelope-From: beispiel.de.
DNS-Abfrage (TXT-Record): beispiel.de IN TXT "v=spf1 ip4:203.0.113.0/24 include:spf.mailprovider.com -all"
Vergleich: IP 203.0.113.42 liegt in 203.0.113.0/24 — SPF pass.
Das Ergebnis wird im Received-SPF-Header vermerkt: Received-SPF: pass (beispiel.de: IP 203.0.113.42 is permitted sender)

Das Ergebnis der SPF-Prüfung ist eines von: pass, fail, softfail, neutral, none, temperror oder permerror.

Der SPF-Record im DNS

Ein SPF-Record ist ein gewöhnlicher DNS TXT-Record, der direkt unter der Domain veröffentlicht wird, die im Envelope-From erscheint. Pro Domain darf es nur einen einzigen SPF-Record geben - mehrere Records führen zu einem permerror.

beispiel.de.  3600  IN  TXT  "v=spf1 ip4:203.0.113.42 include:spf.protection.outlook.com ~all"

Jeder SPF-Record beginnt mit v=spf1 (Versionskennzeichnung) und endet mit einem all-Mechanismus, der definiert, wie mit allen nicht explizit autorisierten Absendern umgegangen werden soll.

SPF-Syntax im Detail

Qualifier: Was passiert bei einer Übereinstimmung?

Jeder Mechanismus kann mit einem Qualifier versehen werden, der das Ergebnis bei einer Übereinstimmung steuert:

Qualifier	Symbol	Ergebnis	Bedeutung
Pass	`+`	pass	Absender ist autorisiert (Standard, wenn kein Qualifier angegeben)
Fail	`-`	fail	Absender ist nicht autorisiert - E-Mail ablehnen
Softfail	`~`	softfail	Absender wahrscheinlich nicht autorisiert - akzeptieren, aber markieren
Neutral	`?`	neutral	Keine Aussage - akzeptieren

Der Qualifier + ist der Standard und wird in der Praxis meist weggelassen: +mx ist identisch mit mx. Am Ende des Records steht fast immer -all (hardfail) oder ~all (softfail).

Mechanismen: Wer darf senden?

Mechanismen definieren, welche Server autorisiert sind:

ip4: und ip6: - direkte IP-Angabe (ohne DNS-Lookup)

v=spf1 ip4:203.0.113.42 -all          (einzelne IPv4-Adresse)
v=spf1 ip4:203.0.113.0/24 -all        (ganzes /24-Subnetz)
v=spf1 ip6:2001:db8::1 -all           (einzelne IPv6-Adresse)
v=spf1 ip6:2001:db8::/32 -all         (IPv6-Subnetz)

ip4: und ip6: sind die effizientesten Mechanismen, da sie keinen DNS-Lookup verbrauchen.

include: - SPF-Record eines externen Dienstes einbinden

v=spf1 include:spf.protection.outlook.com -all    (Microsoft 365)
v=spf1 include:_spf.google.com -all               (Google Workspace)
v=spf1 include:sendgrid.net -all                  (SendGrid)

Jedes include: verbraucht einen DNS-Lookup und bindet den gesamten SPF-Record des angegebenen Dienstes ein.

a - A/AAAA-Record der Domain

v=spf1 a -all                         (IP der eigenen Domain autorisieren)
v=spf1 a:mail.beispiel.de -all        (IP eines bestimmten Hostnamens)

Autorisiert die IP-Adresse, auf die der A-Record der Domain (oder eines angegebenen Hostnamens) zeigt. Verbraucht einen DNS-Lookup.

mx - MX-Records der Domain

v=spf1 mx -all                        (alle eingehenden Mailserver auch zum Senden erlauben)
v=spf1 mx:mail.beispiel.de -all       (MX eines bestimmten Hostnamens)

Autorisiert alle in den MX-Records eingetragenen Mailserver. Verbraucht einen DNS-Lookup (plus je einen weiteren pro MX-Eintrag).

all - Catch-All (immer letzter Mechanismus)

-all Hardfail: alle nicht genannten Server ablehnen (empfohlen)
~all Softfail: alle nicht genannten Server als verdächtig markieren
?all Neutral: keine Aussage (sehr schwacher Schutz)
+all Pass: alles erlaubt (nie verwenden!)

Praxisbeispiele vollständiger SPF-Records

Eigener Mailserver (eine IP): v=spf1 ip4:203.0.113.42 -all
Microsoft 365 ohne eigene Server: v=spf1 include:spf.protection.outlook.com -all
Google Workspace ohne eigene Server: v=spf1 include:_spf.google.com -all
Eigener Server + Microsoft 365 + Newsletterdienst: v=spf1 ip4:203.0.113.42 include:spf.protection.outlook.com include:sendgrid.net -all
Domain, die selbst keine E-Mails versendet (z.B. Subdomain oder Parking-Domain): v=spf1 -all

SPF einrichten: Schritt für Schritt

Schritt 1: Sendende Systeme inventarisieren

Bevor ein SPF-Record gesetzt wird, müssen alle Systeme und Dienste erfasst werden, die E-Mails im Namen der Domain versenden:

Eigene Mailserver (mit ihren IP-Adressen)
Cloud-Mail-Anbieter (Microsoft 365, Google Workspace)
Newsletterdienste (Mailchimp, HubSpot, Brevo/Sendinblue)
CRM- und ERP-Systeme mit E-Mail-Funktion
Monitoring- und Alerting-Systeme
Webserver (Kontaktformulare, Bestellbestätigungen)

Schritt 2: SPF-Record formulieren

Aus der Inventarliste wird der Record zusammengestellt. Als all-Qualifier empfiehlt sich zunächst ~all (Softfail), um legitime E-Mails nicht versehentlich zu blockieren. Nach einem Testlauf kann auf -all (Hardfail) umgestellt werden.

Schritt 3: DNS TXT-Record setzen

Im DNS-Verwaltungsinterface des Domain-Registrars oder des DNS-Providers wird ein TXT-Record direkt unter der Apex-Domain erstellt:

Name:  @  (oder die eigene Domain)
Typ:   TXT
Wert:  v=spf1 [mechanismen] -all
TTL:   3600 (1 Stunde, bei der Ersteinrichtung kleiner wählen)

Schritt 4: Record verifizieren

Nach der Veröffentlichung (Propagation kann bis zu 48 Stunden dauern, bei niedriger TTL meist Minuten) lässt sich der Record prüfen:

# Manuell per DNS-Abfrage:
dig TXT beispiel.de
nslookup -type=TXT beispiel.de

# Online-Tools:
# mxtoolbox.com/spf
# dmarcian.com/spf-survey/
# spf-record.de

Schritt 5: Test-E-Mail senden und Header auswerten

Eine Test-E-Mail an ein Konto senden und die E-Mail-Header prüfen. Im Header sollte erscheinen:

Received-SPF: pass (beispiel.de: ...)
Authentication-Results: spf=pass smtp.mailfrom=beispiel.de

Das 10-DNS-Lookup-Limit

Eine der wichtigsten Einschränkungen von SPF ist das strikte Limit von maximal 10 DNS-Lookups pro SPF-Prüfung. Dieses Limit ist in RFC 7208 festgelegt und soll verhindern, dass SPF-Prüfungen Mailserver durch exzessive DNS-Abfragen überlasten.

Was verbraucht einen Lookup:

Jedes include:
a und a:
mx und mx:
exists:
redirect=

Was keinen Lookup verbraucht:

ip4:
ip6:
all

Das tückische: Verschachtelte include:-Mechanismen zählen mit. Microsoft 365 (include:spf.protection.outlook.com) verbraucht intern selbst mehrere Lookups. Wer also Microsoft 365, Google Workspace und zwei weitere Dienste kombiniert, überschreitet das Limit schnell.

Folgen bei Überschreitung:

Ein SPF-Record, der das 10-Lookup-Limit überschreitet, endet mit dem Fehler permerror (permanent error). Viele Mailserver behandeln permerror wie fail oder softfail - legitime E-Mails können im Spam-Ordner landen oder abgelehnt werden.

Lösung: SPF-Flattening

Beim SPF-Flattening werden alle include:-Ketten aufgelöst und die resultierenden IP-Adressen direkt als ip4:/ip6:-Einträge eingetragen. Das reduziert die Lookup-Anzahl auf null bis zwei. Nachteil: Ändert ein Anbieter seine IP-Adressen, muss der SPF-Record manuell nachgezogen werden. Tools wie der dmarcian SPF Surveyor oder mxtoolbox.com helfen dabei, den Lookup-Count im Blick zu behalten.

Grenzen von SPF

SPF ist ein wichtiger Baustein der E-Mail-Sicherheit, hat aber strukturell bedingte Grenzen, die verstanden werden müssen:

SPF prüft nicht den sichtbaren From:-Header

Dies ist die bedeutendste Einschränkung. SPF prüft ausschließlich den Envelope-From (Return-Path/MAIL FROM) - also die technische Absenderadresse, die bei der SMTP-Verbindung übertragen wird. Der sichtbare From:-Header im Postfach des Empfängers bleibt unkontrolliert.

Ein Angreifer kann daher eine eigene, SPF-konforme Domain als Envelope-Sender nutzen (SPF pass) und gleichzeitig From: geschaeftsfuehrer@ihr-unternehmen.de im sichtbaren Header anzeigen. Gegen diesen Display-Name-Spoofing-Angriff schützt erst DMARC mit seinem Alignment-Check.

SPF versagt bei E-Mail-Weiterleitungen

Wenn ein Mailserver eine eingehende E-Mail direkt an eine andere Adresse weiterleitet (klassisches Server-Side-Forwarding), ändert sich die sendende IP-Adresse, aber der Envelope-From bleibt typischerweise erhalten. Der empfangende Server sieht dann eine IP, die nicht im SPF-Record der ursprünglichen Domain steht - SPF schlägt fehl, obwohl die E-Mail legitim war.

Dieses Problem betrifft vor allem Mailing-Listen und automatische E-Mail-Weiterleitungen. DKIM ist bei Weiterleitungen deutlich robuster, da die kryptografische Signatur den Transport überdauert.

SPF prüft keine Integrität der Nachricht

SPF stellt nur fest, ob der sendende Mailserver autorisiert ist - nicht, ob der Inhalt der E-Mail auf dem Transportweg verändert wurde. Diese kryptografische Integritätsprüfung leistet ausschließlich DKIM.

Kompromittierte autorisierte Server

Ein erfolgreicher SPF-Pass bedeutet lediglich: "Diese IP ist autorisiert, für die Domain zu senden." Wenn ein autorisierter Mailserver kompromittiert wird, können Angreifer darüber SPF-konforme E-Mails versenden. SPF ist kein Schutz gegen den Missbrauch legitimierter Infrastruktur.

SPF im Zusammenspiel mit DKIM und DMARC

SPF allein reicht nicht aus, um E-Mail-Spoofing vollständig zu verhindern. Erst das Zusammenspiel der drei Protokolle schafft einen robusten Schutz:

Protokoll	Was es prüft	Was es nicht prüft
SPF	Ob die sendende IP autorisiert ist (Envelope-From)	Sichtbaren From:-Header, Nachrichteninhalt
DKIM	Kryptografische Signatur (Integrität, signing domain)	Welche IPs senden dürfen
DMARC	Alignment von SPF/DKIM mit dem From:-Header + Policy	Transportverschlüsselung

DMARC als Klammer: DMARC verwendet SPF und DKIM als Prüfmechanismen und fügt das entscheidende Alignment hinzu: Die Domain im From:-Header muss mit der SPF-geprüften Domain (Return-Path) oder der DKIM-signierten Domain (d=-Tag) übereinstimmen. Erst durch diesen Alignment-Check wird verhindert, dass Angreifer SPF-pass-Ergebnisse einer eigenen Domain nutzen, um fremde From:-Header zu fälschen.

Empfohlene Implementierungsreihenfolge:

SPF-Record erstellen: Alle sendenden Systeme eintragen, Lookup-Anzahl prüfen (maximal 10), mit ~all (Softfail) beginnen und nach Tests auf -all wechseln.
DKIM aktivieren: Auf allen sendenden Mailservern einrichten, DNS TXT-Records für alle Selektoren veröffentlichen, Schlüssellänge mindestens 2048 Bit.
DMARC einführen: Mit p=none starten (nur Monitoring, keine Ablehnungen), rua= und ruf= für Reports konfigurieren, Reports auswerten und Fehlkonfigurationen beheben, dann schrittweise zu p=quarantine und p=reject wechseln.

Häufige Fehler bei SPF

Mehrere SPF-Records für eine Domain

Pro Domain darf es genau einen SPF-Record geben. Zwei oder mehr TXT-Records mit v=spf1 führen laut RFC zu permerror. Beim Wechsel des Mailproviders muss der alte Record gelöscht werden, bevor der neue gesetzt wird.

Das 10-Lookup-Limit ignorieren

Der häufigste Konfigurationsfehler in wachsenden Unternehmen: Über Jahre werden immer neue Dienste mit include: hinzugefügt, bis das Limit überschritten ist. Regelmäßige Überprüfung mit Tools wie mxtoolbox.com verhindert das Problem.

+all oder ?all am Ende

Ein Record mit +all autorisiert jeden Mailserver der Welt und macht SPF wirkungslos. Auch ?all bietet kaum Schutz. Für eine Domain, die E-Mails versendet, ist -all (Hardfail) die richtige Wahl.

SPF für Subdomains vergessen

Subdomains erben keinen SPF-Record der Apex-Domain. Eine Domain mail.beispiel.de, die E-Mails versendet, braucht einen eigenen SPF-Record unter mail.beispiel.de. Parking-Domains und ungenutzte Subdomains sollten explizit mit v=spf1 -all gesichert werden, um Missbrauch zu verhindern.

SPF ohne DMARC

SPF ohne DMARC ist unvollständig. Ohne DMARC gibt es keinen Mechanismus, der sicherstellt, dass der SPF-Envelope-From mit dem sichtbaren From:-Header übereinstimmt. Angreifer können SPF-pass-Ergebnisse einer eigenen Domain nutzen, um trotzdem mit fremden From:-Adressen zu phishen.

Transaktionsmails und Newsletterdienste vergessen

E-Commerce-Plattformen, CRM-Systeme und Newsletter-Tools versenden oft E-Mails im Namen der Unternehmensdomain. Fehlen diese im SPF-Record, werden die E-Mails als Softfail oder Fail eingestuft und landen im Spam. Vor der Aktivierung eines neuen Dienstes immer prüfen, ob dessen SPF-Einträge in den Record aufgenommen werden müssen.

SPF ist der erste und einfachste Schritt zur E-Mail-Authentifizierung - ein DNS-Record, der in wenigen Minuten gesetzt ist und sofortigen Schutz vor den gröbsten Spoofing-Angriffen bietet. Für einen vollständigen Schutz sollte SPF immer in Kombination mit DKIM und DMARC eingesetzt werden.