SPF (Sender Policy Framework)
SPF ist ein DNS-basiertes E-Mail-Authentifizierungsprotokoll, das festlegt, welche Mailserver im Namen einer Domain E-Mails versenden dürfen.
SPF (Sender Policy Framework) ist ein DNS-basiertes E-Mail-Authentifizierungsprotokoll (RFC 7208), das Domain-Inhabern erlaubt, explizit festzulegen, welche Mailserver berechtigt sind, E-Mails im Namen ihrer Domain zu versenden. Empfangende Mailserver können anhand des SPF-Records prüfen, ob eine eingehende E-Mail von einem autorisierten Server stammt.
Wie funktioniert SPF
SPF arbeitet ausschließlich auf DNS-Ebene und prüft den technischen Absender einer E-Mail (den sogenannten Envelope-Sender oder Return-Path), nicht den sichtbaren From:-Header.
SPF-Prüfablauf:
1. E-Mail trifft beim empfangenden Mailserver ein
Envelope-From (MAIL FROM): absender@beispiel.de
2. Empfangender Server extrahiert die Domain aus dem Envelope-From
→ Domain: beispiel.de
3. DNS-Lookup:
beispiel.de IN TXT "v=spf1 ip4:203.0.113.0/24 include:spf.mailprovider.com -all"
4. Vergleich: Sendet die IP-Adresse des eingehenden Servers?
→ Steht die IP im SPF-Record? → SPF pass
→ Steht die IP nicht im SPF-Record und Qualifier ist -all? → SPF fail
5. Ergebnis im Received-SPF-Header der E-Mail:
Received-SPF: pass (beispiel.de: IP 203.0.113.42 is permitted sender)SPF-Record Syntax
Ein SPF-Record ist ein DNS TXT-Record unter der Domain, die im Envelope-From erscheint.
Grundstruktur:
v=spf1 [mechanismen] [qualifier]all
Qualifier (Präfix vor jedem Mechanismus):
+ (pass) Sender ist autorisiert (Standard wenn kein Qualifier)
- (fail) Sender ist NICHT autorisiert → ablehnen
~ (softfail) Sender wahrscheinlich nicht autorisiert → akzeptieren, markieren
? (neutral) Keine Aussage → akzeptieren
Gängige Kombination: -all am Ende (hardfail für alle nicht genannten Server)Mechanismen im Detail
ip4: - IPv4-Adresse oder Netzwerk
v=spf1 ip4:203.0.113.42 -all
v=spf1 ip4:203.0.113.0/24 -all (ganzes /24-Netz)
ip6: - IPv6-Adresse oder Netzwerk
v=spf1 ip6:2001:db8::1 -all
v=spf1 ip6:2001:db8::/32 -all
a - A/AAAA-Record der Domain
v=spf1 a -all
(autorisiert die IP-Adresse, auf die beispiel.de zeigt)
v=spf1 a:mail.beispiel.de -all (expliziter Hostname)
mx - MX-Records der Domain
v=spf1 mx -all
(autorisiert alle Server aus den MX-Records)
include: - SPF-Record einer anderen Domain einbinden
v=spf1 include:spf.protection.outlook.com -all
(Microsoft 365: alle MS-Server autorisieren)
v=spf1 include:_spf.google.com -all
(Google Workspace)
exists: - Domain-Existenzprüfung (selten verwendet)
v=spf1 exists:%{i}.authorize.beispiel.de -all
redirect= - Verweis auf anderen SPF-Record (ersetzt -all)
v=spf1 redirect=spf.parent-domain.de
(keine eigenen Mechanismen, komplett delegiert)
all - Catch-All (immer letzter Mechanismus)
-all Hardfail: alles andere ablehnen (empfohlen)
~all Softfail: alles andere als verdächtig markieren
?all Neutral: keine Aussage (schwacher Schutz)
+all Pass: alles erlaubt (sinnlos, nicht verwenden!)Praxisbeispiele
Einfache Domain mit eigenem Mailserver:
v=spf1 ip4:203.0.113.42 -all
Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all
Google Workspace:
v=spf1 include:_spf.google.com -all
Kombination: eigener Server + Microsoft 365 + Marketing-Tool:
v=spf1 ip4:203.0.113.42 include:spf.protection.outlook.com include:em.sparkpostmail.com -all
Domain die selbst keine E-Mails versendet (z.B. Subdomain):
v=spf1 -all
(explizit: niemand darf für diese Domain mailen)Das SPF-Lookup-Limit
SPF erlaubt maximal 10 DNS-Lookups pro Validierung. Jeder include:, a, mx, exists: und redirect= Mechanismus verbraucht einen Lookup. ip4: und ip6: verbrauchen keinen.
Lookup-Limit Probleme:
Zählung (Beispiel):
v=spf1
include:spf.protection.outlook.com → +1 Lookup (+ Lookups im MS-Record!)
include:_spf.google.com → +1 Lookup (+ Lookups im Google-Record!)
include:em.sparkpostmail.com → +1 Lookup
include:mail.zendesk.com → +1 Lookup
a:webserver.beispiel.de → +1 Lookup
mx → +1 Lookup
-all
→ Summe: 6 direkte + verschachtelte Lookups → schnell über 10!
Folge eines Überschreitens:
→ SPF-Prüfung endet mit "permerror" (permanenter Fehler)
→ Viele Mailserver behandeln permerror wie softfail oder fail
→ Legitime E-Mails können im Spam landen!
Lösung: SPF-Flattening
→ Alle IP-Adressen aus include:-Ketten auflösen
→ Direkte ip4:/ip6:-Einträge verwenden
→ Nachteil: Bei IP-Änderungen des Providers muss SPF-Record manuell aktualisiert werden
→ Tools: mxtoolbox.com/spf, dmarcian SPF Surveyor
Alternativ: SPF-Makros für dynamische Prüfungen (fortgeschritten)SPF Alignment
Für DMARC ist nicht nur das SPF-Ergebnis relevant, sondern auch das SPF-Alignment: Die Domain im Return-Path (Envelope-From) muss mit der Domain im sichtbaren From:-Header übereinstimmen.
SPF Alignment Beispiele:
Relaxed Alignment (Standard):
From: absender@beispiel.de
Return-Path: bounce@mail.beispiel.de → PASS (gleiche Org-Domain)
Return-Path: bounce@anderedomain.de → FAIL
Strict Alignment:
From: absender@beispiel.de
Return-Path: bounce@beispiel.de → PASS (exakt gleich)
Return-Path: bounce@mail.beispiel.de → FAIL (Subdomain reicht nicht)
Typisches Alignment-Problem mit E-Mail-Marketing:
From: newsletter@beispiel.de
Return-Path: bounce-123@em.mailchimp.com
→ SPF pass für mailchimp.com, aber DMARC-Alignment FAIL für beispiel.de!
Lösung: Custom Return-Path beim Anbieter konfigurieren
→ Return-Path: bounce@bounces.beispiel.de (CNAME auf Mailchimp)Grenzen von SPF
Was SPF NICHT schützt:
Weiterleitungen (Forwarding):
→ Wenn Server A eine E-Mail an Server B weiterleitet,
ändert sich der Envelope-Sender (Return-Path)
→ SPF-Prüfung bei Server B schlägt fehl (falsche IP für Return-Path-Domain)
→ Typisches Problem bei Mailing-Listen und E-Mail-Weiterleitungen
→ DKIM ist hier deutlich robuster
Display-Name-Spoofing:
→ SPF prüft den technischen Absender (Envelope-From), NICHT den From:-Header
→ Angreifer kann From: ceo@beispiel.de setzen, während SPF für eine
andere Domain (z.B. attackerdomain.com) besteht
→ SPF-Pass bedeutet nicht: "Der From:-Header ist legitim"
→ Lösung: DMARC mit Alignment-Check
Kompromittierter autorisierter Server:
→ Wenn ein autorisierter Server gehackt wird, können Angreifer
valide SPF-passing E-Mails versenden
→ SPF beweist nur: "Diese IP ist autorisiert" - nicht: "Kein Missbrauch"
Keine Integritätsprüfung:
→ SPF prüft nicht, ob die E-Mail auf dem Transportweg verändert wurde
→ DKIM bietet diese kryptographische IntegritätsprüfungSPF und der vollständige Authentifizierungsstack
SPF ist die Grundlage der E-Mail-Authentifizierung, entfaltet seinen vollen Schutz aber erst in Kombination mit DKIM und DMARC:
Empfohlene Reihenfolge bei der Implementierung:
Schritt 1: SPF-Record erstellen
→ Alle sendenden Server und Dienste inventarisieren
→ SPF-Record mit -all veröffentlichen
→ Lookup-Count prüfen (maximal 10!)
Schritt 2: DKIM aktivieren
→ Auf allen sendenden Mailservern DKIM-Signierung einrichten
→ DNS TXT-Records für alle Selektoren veröffentlichen
Schritt 3: DMARC einführen
→ Zuerst p=none (nur Reporting, keine Ablehnung)
→ Reports auswerten (rua=mailto:dmarc@beispiel.de)
→ Schrittweise zu p=quarantine, dann p=rejectEin fehlender oder falsch konfigurierter SPF-Record ist eine der häufigsten Ursachen dafür, dass legitime E-Mails im Spam-Ordner landen oder dass die eigene Domain für Phishing-Angriffe missbraucht wird. Laut DMARC.org haben über 50% aller Domains weltweit entweder keinen oder einen fehlerhaften SPF-Record.
