SPF und die Grenze von zehn Lookups

Es gibt einen Fehler, der einen SPF-Eintrag komplett wirkungslos macht, obwohl er richtig aussieht, sich richtig liest und von jedem Beteiligten für richtig gehalten wird. Er hat keine Fehlermeldung, keinen Warnhinweis und keinen Zeitpunkt, an dem er auffällt.

Er entsteht dadurch, dass jemand einen Dienst hinzufügt.

Die kurze Antwort

Beim Auswerten eines SPF-Eintrags darf ein Empfänger höchstens zehn DNS-Abfragen machen. Wer darüber liegt, dessen Eintrag gilt als fehlerhaft und wird behandelt, als gäbe es ihn nicht. Festgelegt in RFC 7208, Abschnitt 4.6.4.

Der Empfänger meldet das als permerror. Bei DMARC zählt es als nicht bestanden, und wenn eure Richtlinie scharf steht, gehen eigene Mails verloren.

Was überhaupt zählt

Nicht jeder Bestandteil kostet eine Abfrage. Die Unterscheidung ist der ganze Trick:

Und die Zählung ist rekursiv. Was hinter einem include: steht, ist selbst ein SPF-Eintrag und bringt seine eigenen include: mit. Genau deshalb verschätzt sich fast jeder: Man sieht vier Einträge in der eigenen Zeile und liegt tatsächlich bei zwölf.

Ein Beispiel, das harmlos aussieht:

v=spf1 include:spf.protection.outlook.com include:_spf.mailjet.com
       include:servers.mcsv.net include:_spf.google.com ~all

Vier include: in der sichtbaren Zeile. Aufgelöst sind es je nach Anbieter schnell zehn bis fünfzehn Abfragen, weil Microsoft, Google und die Newsletter-Dienste intern weiter verzweigen. Der Eintrag ist damit ungültig, und niemand sieht es ihm an.

So zählt ihr selbst nach

Ihr braucht kein Werkzeug, nur Geduld und nslookup oder dig:

nslookup -type=TXT spf.protection.outlook.com

In der Antwort steht wieder ein SPF-Eintrag. Jedes include: darin zählt erneut, und dessen Inhalt ebenfalls. So arbeitet man den Baum von oben nach unten ab und addiert.

Wer es schneller mag: Unser DMARC-Check löst die Kette automatisch auf und nennt die Zahl. Er warnt außerdem, wenn ihr bei acht oder neun steht, denn dann kippt der nächste hinzugefügte Dienst den Eintrag.

Die zweite Grenze, die kaum jemand kennt

Im selben Abschnitt des RFC steht eine weitere Obergrenze: Höchstens zwei der Abfragen dürfen ins Leere laufen. Gemeint sind Abfragen, die nichts zurückliefern, weil der Name nicht mehr existiert oder keinen passenden Eintrag hat.

Der typische Fall ist ein include, das auf einen Dienst zeigt, den es längst nicht mehr gibt. Der Eintrag sieht unauffällig aus, kostet weiterhin eine Abfrage, und ab der dritten toten Verzweigung gilt derselbe permerror wie beim Überschreiten der Zehn.

Dazu kommen zwei Längengrenzen, die im DNS selbst stecken:

• Eine einzelne Zeichenkette in einem TXT-Eintrag darf 255 Zeichen lang sein. Längere Einträge werden in mehrere Ketten aufgeteilt, die der Empfänger wieder zusammensetzt. Das ist erlaubt, aber nicht jede DNS-Oberfläche macht es richtig.
• Passt die gesamte Antwort nicht mehr in ein UDP-Paket, muss der Empfänger über TCP nachfragen. Die meisten tun das, manche Firewalls lassen es nicht zu.

Beide Längengrenzen trifft vor allem, wer seinen Eintrag künstlich aufbläht. Womit wir beim nächsten Punkt wären.

Warum „SPF-Flattening“ die falsche Antwort ist

Die Lösung, die man online am häufigsten liest, heißt Flattening: Man löst alle include: einmal auf und schreibt die gefundenen IP-Adressen direkt als ip4:-Bereiche in den Eintrag. Danach kostet nichts mehr eine Abfrage, und das Problem ist weg.

Für eine Woche.

Die IP-Bereiche der großen Anbieter ändern sich, ohne dass euch jemand Bescheid sagt. Genau dafür ist das include: da: Es zeigt auf eine Liste, die der Anbieter pflegt. Wer sie einfriert, übernimmt diese Pflege selbst, ohne es zu wissen. Wenn Microsoft einen Ausgangsserver umzieht, fällt eure Mail von diesem Server durch, und der Eintrag sieht weiter tadellos aus.

Es gibt Dienste, die das Flattening automatisch nachziehen. Damit hängt eure Mailzustellung an der Verfügbarkeit eines weiteren Anbieters, den ihr für ein Problem eingekauft habt, das sich meist anders lösen lässt.

Flattening ist vertretbar für eigene, feste Server, deren Adressen ihr selbst kontrolliert. Für fremde Dienste ist es eine Wette.

Was stattdessen hilft

Erstens: aufräumen. In fast jedem Eintrag, den wir uns ansehen, stehen Dienste, die seit Jahren nichts mehr verschicken. Der Newsletter-Anbieter von davor, ein Bewerbungsportal, eine Testphase. Jeder davon kostet dauerhaft Abfragen. Das ist der billigste Gewinn und kostet zwanzig Minuten.

Zweitens: ptr streichen. Der Term ist langsam, unzuverlässig und laut RFC ausdrücklich unerwünscht. Er kommt trotzdem in alten Einträgen vor.

Drittens: Subdomains für einzelne Dienste. Der wirksamste Schritt, und der am seltensten gegangene. Der Newsletter geht nicht von firma.de raus, sondern von news.firma.de, mit eigenem SPF-Eintrag und eigenem Budget von zehn Abfragen. Die Hauptdomain behält nur das, was aus dem Haus kommt.

Das hat einen zweiten Vorteil: Fällt der Newsletter-Anbieter durch eine Sperrliste, betrifft das den Ruf der Subdomain, nicht den eurer Rechnungsadresse.

Viertens: a und mx prüfen. Beide stehen oft aus Gewohnheit im Eintrag, obwohl der Webserver gar keine Mail verschickt und die MX-Server nur empfangen. Zwei Abfragen, die niemand braucht.

Der Zusammenhang mit DMARC

Solange DMARC auf p=none steht, merkt ihr von einem permerror gar nichts. Die Mail wird zugestellt, im Kopf steht ein Prüfvermerk, den kein Mensch liest, und in den Aggregatberichten taucht sie als durchgefallen auf.

Deshalb gehört das Zählen an den Anfang und nicht ans Ende. Die Reihenfolge ist immer dieselbe: erst SPF vollständig und unter der Grenze, dann DKIM überall, dann DMARC mit Berichtsadresse, dann beobachten, dann verschärfen. Nachzulesen in SPF, DKIM und DMARC: was die drei wirklich tun und, für den Schritt danach, in DMARC-Berichte auswerten.

Ein Trost bleibt: Selbst wenn SPF an der Grenze scheitert, rettet ein funktionierendes DKIM die Zustellung. Das ist kein Argument dafür, den Eintrag verkommen zu lassen, aber es erklärt, warum viele Firmen jahrelang mit einem ungültigen SPF leben, ohne etwas zu merken.

Wo ihr steht

Der kostenlose DMARC-Check zeigt die Zahl der Abfragen, die euer Eintrag auslöst, dazu SPF, DKIM, DMARC, MTA-STS und TLS-RPT. Ohne Anmeldung, ohne E-Mail-Adresse.

Wenn dabei zwölf herauskommen und jemand es geradeziehen soll: Wir räumen solche Einträge auf, ohne dass unterwegs Mail verloren geht, und behalten sie bei laufender Wartung im Blick.