Das Problem
Im Standard-E-Mail-Protokoll kann jeder beliebige Server behaupten, er versende Mails für ihre-firma.at. Empfänger haben ohne Zusatzinformation keine Möglichkeit zu prüfen, ob die Absenderadresse echt ist. Das ist die Grundlage von Phishing und CEO-Fraud.
Wie SPF funktioniert
SPF löst das Problem per DNS-Eintrag. In einem TXT-Record veröffentlichen Sie eine Liste der Server, die für Ihre Domain senden dürfen. Der empfangende Mailserver fragt diese Liste ab und vergleicht sie mit der IP-Adresse, von der die E-Mail gerade kommt.
Beispiel-Record
So sieht ein typischer SPF-Eintrag im DNS aus — hier für eine Domain, die Google Workspace und Mailgun nutzt:
; TXT-Record für @ (Root-Domain) "v=spf1 include:_spf.google.com include:mailgun.org ~all"
Die wichtigen Bestandteile:
v=spf1— kennzeichnet den Record als SPF Version 1.include:…— übernimmt die erlaubten Server eines Anbieters.~all— alles andere ist „Softfail": Mail kommt vermutlich durch, wird aber markiert.
Die vier Policy-Endungen
| Endung | Bedeutung | Empfehlung |
|---|---|---|
-all | Hard-Fail — alles außerhalb der Liste wird abgelehnt. | Ideal |
~all | Soft-Fail — verdächtig, aber nicht blockiert. | Gut |
?all | Neutral — keine Aussage. | Schwach |
+all | Alles erlaubt. | Nie |
Die häufigsten Stolperfallen
- Mehr als 10 DNS-Lookups — SPF hat ein hartes Limit von 10 Abfragen. Viele
include:-Einträge können dieses Limit sprengen und den Record ungültig machen. - Zwei SPF-Records auf einer Domain — ist technisch verboten, wird von Empfängern ignoriert. Es darf nur einen TXT-Record mit
v=spf1geben. - Weiterleitungen — wenn Mails von einer Adresse automatisch weitergeleitet werden, schlägt SPF beim neuen Empfänger fehl. DKIM löst das.