SPF (Sender Policy Framework)
DNS-basierter Mechanismus, der festlegt, welche Mailserver berechtigt sind, E-Mails im Namen einer Domain zu versenden.
SPF (Sender Policy Framework) ist ein DNS-basiertes Authentifizierungsverfahren, das festlegt, welche Mailserver berechtigt sind, E-Mails im Namen einer bestimmten Domain zu versenden. Empfänger-Server können anhand des SPF-Records prüfen, ob eine eingehende E-Mail von einem autorisierten Server stammt. Ohne SPF kann jeder beliebige Server E-Mails mit einer gefälschten Absenderadresse verschicken — eine Grundlage für Phishing und Spoofing.
Wie SPF funktioniert
Der Domaininhaber veröffentlicht einen TXT-Record im DNS, der alle autorisierten Mailserver auflistet. Wenn ein Empfänger-Server eine E-Mail erhält, extrahiert er die Domain aus dem MAIL FROM-Envelope (Return-Path) und fragt den SPF-Record dieser Domain ab. Anschließend prüft er, ob die IP-Adresse des sendenden Servers in der Liste der autorisierten Server enthalten ist.
Wichtig zu verstehen: SPF prüft den Envelope-Absender, nicht den From:-Header, den der Empfänger sieht. Diese Lücke schließt erst DMARC mit der Alignment-Prüfung.
SPF-Record Syntax
Ein SPF-Record beginnt immer mit v=spf1 und endet mit einem Qualifier. Dazwischen stehen die Mechanismen, die autorisierte Absender definieren:
| Mechanismus | Bedeutung | Beispiel |
|---|---|---|
ip4 |
Einzelne IPv4-Adresse oder CIDR-Block | ip4:203.0.113.0/24 |
ip6 |
Einzelne IPv6-Adresse oder Präfix | ip6:2001:db8::/32 |
a |
A-Record der Domain | a |
mx |
MX-Server der Domain | mx |
include |
SPF-Record einer anderen Domain einbinden | include:_spf.google.com |
redirect |
Gesamten SPF-Record einer anderen Domain verwenden | redirect=_spf.example.de |
Der abschließende Qualifier bestimmt, wie mit nicht gelisteten Servern umgegangen wird:
| Qualifier | Bedeutung | Empfehlung |
|---|---|---|
-all |
Hard Fail — alle anderen Server ablehnen | Empfohlen für Produktionsdomains |
~all |
Soft Fail — markieren, aber zustellen | Geeignet für die Übergangsphase |
?all |
Neutral — keine Aussage | Bietet keinen Schutz |
+all |
Alle Server erlauben | Niemals verwenden |
Ein typischer SPF-Record für ein Unternehmen, das Microsoft 365 und einen Newsletter-Dienst nutzt, sieht so aus:
v=spf1 include:spf.protection.outlook.com include:mail.newsletter.example.com -all
Das 10-DNS-Lookup-Limit
SPF hat ein hartes Limit von maximal zehn DNS-Lookups pro Prüfung. Jedes include, a, mx und redirect zählt als ein Lookup — verschachtelte include-Einträge ebenfalls. Wird das Limit überschritten, liefert die SPF-Prüfung ein PermError und gilt als fehlgeschlagen.
In der Praxis wird dieses Limit schnell erreicht, wenn ein Unternehmen mehrere Drittanbieter für den E-Mail-Versand nutzt (CRM, Newsletter, Helpdesk, Transaktionsmails). Lösungsansätze sind SPF-Flattening (Auflösen der include-Ketten in IP-Adressen) oder dedizierte Subdomains für verschiedene Absender. Der SPF-Flattener analysiert Ihren Record, zählt die Lookups und erzeugt einen optimierten Record ohne überflüssige Verschachtelungen.
Häufige Fehler
Mehrere SPF-Records für dieselbe Domain sind der häufigste Konfigurationsfehler. Der RFC schreibt vor, dass pro Domain nur ein einziger SPF-Record existieren darf. Bei mehreren Records liefert die Prüfung ein PermError. Stattdessen müssen alle Mechanismen in einem einzigen Record zusammengefasst werden.
Ein weiterer verbreiteter Fehler ist die Verwendung von ~all statt -all im Produktivbetrieb. Der Soft Fail bietet nur eingeschränkten Schutz, da viele Empfänger-Server Soft-Fail-Nachrichten trotzdem zustellen. Erst in Kombination mit einer strikten DMARC-Policy (p=reject) wird auch ~all effektiv durchgesetzt.
Auch die Verwendung des ptr-Mechanismus ist ein Fehler, den man gelegentlich antrifft. Der RFC rät ausdrücklich von ptr ab, da er langsam und unzuverlässig ist. Manche Empfänger-Server ignorieren ptr-Einträge vollständig.
SPF und Weiterleitungen
Eine bekannte Schwäche von SPF betrifft Weiterleitungen. Wenn ein Empfänger eine E-Mail an eine andere Adresse weiterleitet, ändert sich der sendende Server — die IP-Adresse des weiterleitenden Servers ist in der Regel nicht im SPF-Record der Ursprungsdomain gelistet. Die SPF-Prüfung schlägt dann fehl.
Dieses Problem wird durch SRS (Sender Rewriting Scheme) gemildert, bei dem der weiterleitende Server den Envelope-Absender umschreibt. Zuverlässiger ist jedoch der Rückgriff auf DKIM, das bei Weiterleitungen intakt bleibt, solange der E-Mail-Body nicht modifiziert wird. Deshalb ist es entscheidend, SPF nicht isoliert einzusetzen, sondern immer zusammen mit DKIM und DMARC als Teil einer vollständigen E-Mail-Authentifizierung.
SPF prüfen
Ob der SPF-Record Ihrer Domain korrekt konfiguriert ist, können Sie mit dem E-Mail Security Check kostenlos prüfen. Das Tool analysiert den SPF-Record, prüft die Syntax und zeigt potenzielle Probleme wie überschrittene Lookup-Limits oder fehlende Qualifier auf. SPF bildet zusammen mit DKIM und DMARC die Grundlage der E-Mail-Authentifizierung.