SPF - Sender Policy Framework

SPF (Sender Policy Framework) ist ein DNS-TXT-Eintrag, der autorisierte Mailserver für eine Domain auflistet. Empfangende Mailserver prüfen, ob eine eingehende E-Mail von einem in diesem Eintrag aufgeführten Server gesendet wurde - und können sie andernfalls ablehnen oder als Spam markieren.

SPF ist einer der drei Bausteine der E-Mail-Authentifizierung. Die anderen beiden sind DKIM (kryptografische Signatur) und DMARC (Policy und Reporting). Alle drei gemeinsam sind nötig für vollständigen E-Mail-Schutz.

Wie SPF funktioniert

1. Absender sendet E-Mail von info@beispiel.de über Server 203.0.113.10
2. Empfangendes Mailsystem fragt DNS nach TXT beispiel.de
3. SPF-Eintrag lautet: v=spf1 ip4:203.0.113.0/24 -all
4. IP 203.0.113.10 liegt im erlaubten Bereich → SPF pass
5. Liegt sie nicht im erlaubten Bereich → SPF fail

Wichtig: SPF prüft die Envelope-From-Adresse (technischer SMTP-MAIL FROM), nicht den sichtbaren From:-Header in der E-Mail. Ein Angreifer kann SPF bestehen und trotzdem einen falschen From:-Header zeigen - deshalb ist DMARC (Alignment-Check) zwingend nötig.

SPF-Record-Syntax

v=spf1 [mechanisms] [modifier]

Mechanismen

Mechanismus	Bedeutung
ip4:203.0.113.0/24	IPv4-Adresse oder -Bereich
ip6:2001:db8::/32	IPv6-Adresse oder -Bereich
include:_spf.google.com	Einbindung des SPF-Records einer anderen Domain
a	Der A-Record der eigenen Domain
mx	Alle MX-Records der Domain
all	Passt auf alle nicht zuvor gematchten Quellen

Qualifier (vor dem Mechanismus)

Qualifier	Bedeutung	Empfehlung
+ (default)	Pass - Quelle ist autorisiert	Für erlaubte Quellen
-	Fail (Hardfail) - Quelle ist nicht autorisiert, Ablehnung	Für all am Ende
~	Softfail - nicht autorisiert, aber nicht strikt ablehnen	Nur übergangsweise
?	Neutral - keine Aussage	Vermeiden

Empfohlenes Muster:

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all

Das 10-DNS-Lookup-Limit

SPF erlaubt maximal 10 DNS-Lookups pro SPF-Prüfung. Jeder include:, a, mx-Mechanismus kostet einen Lookup. Bei vielen Cloud-Diensten (Google Workspace, Microsoft 365, Salesforce, HubSpot, Zendesk...) wird das Limit schnell erreicht - und SPF bricht mit PermerError ab, was zu Zustellproblemen führt.

Lösung: SPF-Flattening (Auflösung aller Includes in direkte IP-Adressen) oder Verwendung von SPF-Makros. Regelmäßige Überprüfung mit Tools wie MXToolbox oder dmarcian.

Häufige SPF-Fehler

Fehlender -all am Ende: Ohne abschließenden Qualifier ist jeder Server implizit neutral - der SPF-Eintrag schützt nicht.

~all statt -all: Softfail bedeutet, dass Empfänger die E-Mail trotzdem zustellen (wenn auch mit Spam-Markierung). Nur für die Übergangsphase sinnvoll.

Unbekannte Mailquellen vergessen: Marketing-Automation, CRM, ERP, Ticketsysteme - alle versenden E-Mails im Firmennamen und müssen im SPF-Record stehen.

Subdomains: SPF-Records gelten nicht automatisch für Subdomains. mail.beispiel.de braucht einen eigenen SPF-Record.

SPF im Zusammenspiel mit DMARC

SPF allein reicht nicht aus, weil:

1. SPF prüft die Envelope-From, nicht den sichtbaren From-Header
2. Bei E-Mail-Weiterleitungen (z.B. Alumni-Adressen) schlägt SPF oft fehl

DMARC löst beides: Es fordert SPF-Alignment (Envelope-From und From-Header müssen zur gleichen Domain gehören) und legt fest, was bei Scheitern des Alignments passieren soll.

Empfohlener Implementierungspfad:

1. SPF mit -all einrichten
2. DKIM für alle Mailquellen aktivieren
3. DMARC mit p=none einschalten und Reports sammeln
4. DMARC schrittweise zu p=quarantine → p=reject verschärfen

Weiterführende Informationen: DMARC Wiki-Artikel | DKIM Wiki-Artikel