SPF-Record einrichten: Syntax, Beispiele, 10-Lookup-Limit

Die meisten SPF-Probleme entstehen nicht beim ersten Einrichten. Sie entstehen zwei Jahre später, wenn jemand ein Newsletter-Tool anbindet und einfach einen zweiten TXT-Record mit v=spf1 anlegt. Ab diesem Moment ist SPF für die ganze Domain kaputt, und niemand merkt es, bis Rechnungen im Spam landen.

Was ein SPF-Record tut und was nicht

Wer einen SPF-Record einrichten will, sollte zuerst wissen, was genau geprüft wird. SPF (Sender Policy Framework, RFC 7208) beantwortet eine Frage: Darf die IP-Adresse, die gerade einliefert, Mails für diese Domain verschicken? Der empfangende Server schaut dazu in den TXT-Records der Domain aus dem SMTP-Envelope (MAIL FROM, auch Return-Path genannt).

Das ist nicht unbedingt die Adresse, die im Mailprogramm als Absender erscheint. Ein Newsletter-Dienst verschickt oft mit einem eigenen Return-Path wie bounces.dienst.com, während oben [email protected] steht. SPF besteht dann für die Domain des Dienstes, nicht für deine. Genau deshalb gibt es DMARC einrichten als nächsten Schritt: DMARC verlangt, dass SPF- oder DKIM-Domain zur sichtbaren From-Domain passen.

Aufbau eines SPF-Eintrags

Ein SPF-Record ist ein gewöhnlicher TXT-Eintrag. Er beginnt immer mit v=spf1, danach folgen Mechanismen, die von links nach rechts geprüft werden. Der erste Treffer gewinnt.

beispiel.de.  3600  IN  TXT  "v=spf1 mx include:_spf.google.com include:servers.mcsv.net ~all"

Vor jedem Mechanismus kann ein Qualifier stehen: + (pass, Standard), - (fail), ~ (softfail), ? (neutral).

~all oder -all: was am Ende stehen sollte

Der Streit um das letzte Wort im Record ist älter als DMARC. -all sagt: Alles, was nicht aufgelistet ist, ist ein Fehlschlag. ~all sagt: verdächtig, aber nicht hart ablehnen.

Meine Empfehlung für Domains, die DMARC nutzen: ~all. Der Grund ist unspektakulär. Manche Empfänger lehnen eine Mail bei SPF fail schon während der SMTP-Sitzung ab, bevor DKIM und DMARC überhaupt ausgewertet werden. Wird eine Mail weitergeleitet, scheitert SPF fast immer, DKIM bleibt aber oft gültig. Mit -all kann so eine legitime, DKIM-signierte Mail verloren gehen, die DMARC eigentlich durchgelassen hätte. Die eigentliche Durchsetzung übernimmt dann DMARC mit p=reject.

Für Domains, die nie Mails verschicken, ist -all dagegen genau richtig. IANA macht es bei example.com selbst so:

$ dig +short TXT example.com
"_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"
"v=spf1 -all"

Das Limit von 10 DNS-Lookups

Hier scheitern die meisten Setups. RFC 7208 begrenzt die Zahl der Mechanismen, die eine DNS-Abfrage auslösen, auf 10. Gezählt werden include, a, mx, ptr, exists und redirect, und zwar rekursiv: Ein include auf einen Dienst, der selbst drei weitere include enthält, kostet vier Lookups. Wird das Limit überschritten, liefert der Empfänger permerror, und SPF gilt als nicht bestanden.

Eine typische Rechnung für einen kleinen Onlineshop:

Ein weiterer Dienst, und es ist vorbei. Zusätzlich erlaubt der Standard höchstens zwei sogenannte Void Lookups, also Abfragen, die gar keine Antwort liefern. Ein include auf einen Dienst, den es nicht mehr gibt, zählt dazu.

Wege aus der Klemme:

• Dienste, die du nicht mehr nutzt, rauswerfen. Das ist fast immer der größte Hebel.
• mx und a durch ip4:/ip6: ersetzen, wenn sich die Adressen selten ändern.
• Newsletter- und Transaktionsmails über eine Subdomain wie mail.beispiel.de schicken. Die hat ihren eigenen SPF-Record mit eigenem Budget.
• Sogenanntes SPF-Flattening (alle includes in IP-Listen auflösen) nur mit Automatik, die regelmäßig neu auflöst. Ändert ein Anbieter seine IP-Bereiche, sendest du sonst plötzlich von nicht freigegebenen Adressen.

SPF-Record prüfen mit dig

Nach dem Anlegen fragst du den Eintrag direkt ab:

$ dig +short TXT beispiel.de
"v=spf1 mx include:spf.protection.outlook.com ~all"

Steht dort mehr als eine Zeile mit v=spf1, hast du ein Problem. Die includes kannst du einzeln weiterverfolgen, um die Lookups zu zählen:

$ dig +short TXT spf.protection.outlook.com
"v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ... -all"

Microsofts Record enthält nur IP-Bereiche, kostet also genau einen Lookup. Bei anderen Diensten sieht das anders aus.

Lange Records stoßen an eine zweite Grenze: Ein einzelner String in einem TXT-Record darf maximal 255 Zeichen haben. Längere Einträge werden in mehrere Strings in Anführungszeichen aufgeteilt, die der Empfänger ohne Leerzeichen zusammensetzt. Die meisten DNS-Oberflächen machen das automatisch.

Häufige Fehler beim SPF-Eintrag

• Zwei Records. Siehe oben, das Ergebnis ist permerror.
• Tippfehler im Präfix. Ein Leerzeichen vor v=spf1 oder ein vergessenes Anführungszeichen beim Kopieren, und der Record wird nicht mehr als SPF erkannt.
• Der alte Typ SPF (Typ 99). Den gibt es seit RFC 7208 nicht mehr. Nur TXT zählt.
• +all am Ende. Damit erlaubst du jedem Server der Welt, als deine Domain zu senden. Das ist schlimmer als gar kein Record.
• Webserver vergessen. Das Kontaktformular auf dem Hosting-Paket verschickt per PHP mail() vom Webserver aus. Dessen IP fehlt oft im Record.

Wenn das alles steht, ist der nächste Baustein die Signatur: Wie du DKIM einrichten kannst, erklärt der Artikel dazu. Warum SPF allein gefälschte Absender nicht stoppt, zeigt der Beitrag zu E-Mail-Spoofing verhindern.

Wo du den Record anlegst

SPF gehört in die DNS-Zone der Domain, nicht in das Postfach-Backend. Wer Domain und Mail beim selben Hoster hat, findet die Zone meist in dessen Kundenmenü. Liegt die Domain bei einem reinen Registrar, bearbeitest du die Records dort. Bei betadomain bearbeitest du die Records in der DNS-Verwaltung direkt an der Domain, DNSSEC lässt sich dort ebenfalls einschalten. Eine .de-Domain mit DNS-Verwaltung kostet 2,99 € im Jahr, und zwar auch bei jeder Verlängerung.

Falls du gerade erst überlegst, eine eigene Domain für E-Mail zu registrieren, lohnt es sich, SPF, DKIM und DMARC gleich am ersten Tag zu setzen. Später nachzurüsten ist mühsamer, weil dann schon Dienste laufen, die niemand mehr auf dem Zettel hat. Die Endungen im Preisvergleich zeigen dir, was eine zweite Domain nur für Newsletter kosten würde.

Schritt für Schritt

1. Alle Versender auflistenNotiere jeden Dienst, der Mails mit deiner Domain verschickt: Postfach-Anbieter, Newsletter-Tool, Shop-System, Ticket-System, Kontaktformular auf dem Webserver.
2. Include-Angaben der Dienste sammelnSchlage in der Doku jedes Dienstes den SPF-Mechanismus nach, etwa include:_spf.google.com für Google Workspace oder include:spf.protection.outlook.com für Microsoft 365.
3. Record zusammenbauen und Lookups zählenSetze alles in einen Eintrag: v=spf1, die Mechanismen, am Ende ~all. Zähle include, a, mx, exists und redirect, auch die verschachtelten. Mehr als 10 führen zu permerror.
4. TXT-Record im DNS anlegenLege beim DNS-Anbieter einen TXT-Record auf der Hauptdomain (Host @ oder leer) an und lösche alte SPF-Einträge, damit nur einer übrig bleibt.
5. Mit dig und einer Testmail prüfenFrage den Record mit dig +short TXT beispiel.de ab und schicke eine Mail an ein Gmail-Konto. Unter Original anzeigen muss SPF: PASS stehen.