SPF-Eintrag prüfen und richtig lesen

Ein SPF-Eintrag lässt sich in fünf Sekunden abfragen und in fünf Minuten falsch verstehen. Er ist ein gewöhnlicher TXT-Eintrag, festgelegt in RFC 7208, und er beantwortet genau eine Frage: welche Server im Namen dieser Domain Mails einliefern dürfen.

Den Eintrag auslesen#

SPF hat keinen eigenen Satztyp. Gesucht ist der TXT-Eintrag der Domain, der mit v=spf1 beginnt:

dig beispiel.de TXT +short nslookup -type=TXT beispiel.de

Zwischen den Ergebnissen stehen üblicherweise Bestätigungscodes fremder Dienste. Relevant ist allein die Zeile mit v=spf1 am Anfang. Steht dort nichts, existiert keine SPF-Regel für diese Domain, und jeder beliebige Server darf in ihrem Namen einliefern, ohne dass die Prüfung anschlägt.

Wichtig ist außerdem, welche Domain man abfragt. SPF wird auf der Domain des Envelope-Absenders ausgewertet. Versendet ein System mit rechnung@sub.beispiel.de als Envelope-Adresse, ist der Eintrag von sub.beispiel.de maßgeblich — Unterdomains erben nichts von der Hauptdomain.

Wie ein SPF-Eintrag zu lesen ist#

Ein typischer Eintrag sieht so aus:

v=spf1 include:_spf.beispielanbieter.de ip4:198.51.100.25 ~all

Die Mechanismen werden von links nach rechts geprüft, und die erste Übereinstimmung entscheidet. Was danach steht, wird nicht mehr betrachtet.

ip4 und ip6 nennen einzelne Adressen oder Netzbereiche direkt. a trifft auf die Adressen aus dem A- oder AAAA-Eintrag der Domain zu, mx auf die Adressen der eingetragenen Mailserver. include übernimmt die Regel einer fremden Domain: Passt der einliefernde Server dort, gilt er auch hier als erlaubt. Ein Nichttreffer im include führt dagegen nicht zum Fehlschlag, sondern nur zur nächsten Regel. ptr gilt als überholt und sollte nicht mehr verwendet werden.

Der letzte Mechanismus ist all, und er trifft immer zu. Entscheidend ist sein Vorzeichen: ~all bedeutet softfail, -all bedeutet fail, ?all bedeutet neutral, +all erlaubt jedem alles. Ein Eintrag, der auf ?all oder +all endet, ist praktisch wirkungslos, auch wenn davor eine lange, saubere Liste steht.

Der zweite häufig übersehene Punkt betrifft die Reichweite: SPF prüft den Envelope-Absender aus dem SMTP-Befehl MAIL FROM, nicht den From-Header, den der Empfänger im Postfach sieht. Beide dürfen völlig verschiedene Domains nennen. Ein sauberes spf=pass sagt deshalb nichts darüber aus, ob der sichtbare Absender echt ist. Genau diese Lücke schließt erst DMARC, indem es eine Übereinstimmung zwischen der geprüften und der angezeigten Domain verlangt.

Wie eine echte Zustellung ausgegangen ist, zeigt der Kopfzeilenbereich einer empfangenen Mail. Dort steht in Authentication-Results das Ergebnis samt der Domain, auf die es sich bezieht.

Die Grenze von zehn DNS-Abfragen#

RFC 7208 begrenzt die Zahl der DNS-Abfragen, die bei der Auswertung eines Eintrags anfallen dürfen, auf zehn — nicht auf zehn include. Mit: include, a, mx, ptr, exists und redirect. Ohne: ip4, ip6 und all, denn die kosten keine Abfrage.

Die Falle steckt in der Rekursion. Ein einziges include kann intern mehrere weitere Abfragen auslösen, weil die eingebundene Domain ihrerseits include verwendet. Vier eingebundene Dienste reichen regelmäßig aus, um über die Grenze zu kommen.

Zählen lässt sich das nur, indem man jede eingebundene Domain selbst abfragt und weiterverfolgt:

dig _spf.beispielanbieter.de TXT +short

Wird die Grenze überschritten, ist das Ergebnis PermError. Das ist kein Pass mit Schönheitsfehler, sondern ein Auswertungsfehler: Die Prüfung liefert kein verwertbares Ergebnis, und der Schutz fällt aus. Abhilfe schaffen das Entfernen ungenutzter Dienste sowie das Ersetzen von a und mx durch feste ip4-Angaben, wo die Adressen stabil sind.

Die häufigsten Fehler#

1. Zwei SPF-Einträge. Je Domain darf nur ein TXT-Eintrag mit v=spf1 existieren. Sind es zwei, gewinnt nicht der bessere, sondern die Auswertung endet in einem PermError. Der Fall entsteht fast immer beim Hinzufügen eines zweiten Dienstes, der seine eigene Zeile mitbringt. Richtig ist ein Eintrag mit mehreren include.

2. Ein Versandweg fehlt. Newsletter-Werkzeug, CRM, Shop, Rechnungsprogramm, Ticketsystem, Formularversand vom Webserver: Jedes System, das im Namen der Domain einliefert, muss abgedeckt sein. Welche Quellen tatsächlich versenden, verraten die aggregierten DMARC-Berichte, nicht das Gedächtnis der Beteiligten.

3. Zu scharf gestellt, ohne die Liste zu kennen. -all lässt Empfänger ablehnen. Fehlt ein legitimer Dienst, verschwinden dessen Mails, und zwar leise.

4. Ein zerschnittener Eintrag. Eine einzelne Zeichenkette im TXT-Eintrag darf höchstens 255 Zeichen lang sein; längere Einträge bestehen aus mehreren Teilen, die der Resolver wieder zusammensetzt. Manche Verwaltungsoberflächen machen daraus zwei getrennte Einträge, und damit ist Fehler eins wieder da.

5. Keine Regel für Domains ohne Mailversand. Wer eine Domain nur geparkt hat, sollte dort v=spf1 -all hinterlegen. Sonst bleibt sie eine bequeme Absenderadresse für Fremde.

Weiterlesen#

Wer noch keinen Eintrag hat oder ihn neu aufbauen will, findet den Weg dorthin unter SPF-Eintrag erstellen. Warum verschiedene Resolver beim Nachsehen abweichende Antworten liefern, erklärt DNS-Eintrag prüfen — und den Rest der Konfiguration einer Domain deckt der Security-Scan ab.