SPF 10-Lookup-Limit: Was zählt und wie Sie darunter bleiben

Ein empfangender Mailserver prüft SPF, indem er Ihren Record auswertet, und die Auswertung kostet DNS-Abfragen. Damit dieser Aufwand begrenzt bleibt, legt RFC 7208 fest, wie viele abfrageauslösende Terme eine einzelne Prüfung auswerten darf. Wird die Grenze überschritten, lautet das Ergebnis permerror, ein dauerhafter Fehler, der nicht als pass gilt. Prüftools melden ihn häufig als „too many DNS lookups“, und er tritt meist direkt auf, nachdem dem Record ein weiterer Versanddienst hinzugefügt wurde.

Was die Spezifikation zählt

Abschnitt 4.6.4 von RFC 7208 listet die Terme auf, die DNS-Abfragen auslösen: die Mechanismen include, a, mx, ptr und exists sowie den Modifier redirect. Implementierungen müssen die Gesamtzahl dieser Terme bei einer Auswertung auf 10 begrenzen und bei Überschreitung permerror zurückgeben. Die Mechanismen all, ip4 und ip6 brauchen keine Abfrage und werden nicht gezählt, ebenso wenig der Modifier exp, der erst später nach einem Fehlschlag abgerufen wird.

Zwei Details sind wichtig. Erstens kopiert include keinen anderen Record in Ihren: Nur sein Ergebnis wird verwendet, und der RFC räumt ein, dass der Name schlecht gewählt war. Ein -all in einem eingebundenen Record beendet die Gesamtauswertung nicht. Zweitens werden Mechanismen von links nach rechts ausgewertet, und die Verarbeitung endet bei dem ersten, der zutrifft. Das Limit gilt für Terme, die bei einer Prüfung tatsächlich ausgewertet werden, nicht für die Größe des Records auf dem Papier.

Einen Record von Hand zählen

Hier ein hypothetischer Record für ein Unternehmen, das zwei Mailplattformen, ein CRM, einen Helpdesk und einen eigenen Mailserver nutzt:

v=spf1 include:mailer-a.example include:mailer-b.example include:crm.example include:helpdesk.example mx a ~all

Angenommen, die eingebundenen Records enthalten die folgenden Terme. Sie sind zur Veranschaulichung erfunden; die Records echter Anbieter sehen anders aus und ändern sich im Lauf der Zeit.

Mail, die über die erste Plattform läuft, trifft früh zu und besteht die Prüfung. Mail von dem Server, den nur das letzte a autorisiert, braucht einen elften Lookup, sodass die Prüfung permerror statt eines Treffers liefert. Diese Asymmetrie ist der Grund, warum der Fehler sporadisch wirkt: Er hängt davon ab, wessen Mail gerade geprüft wird.

Weitere Limits in derselben Spezifikation

• Void Lookups. Eine Abfrage, die keine Records oder einen Namensfehler liefert, ist ein Void Lookup. RFC 7208 empfiehlt, sie auf zwei zu begrenzen; eine Überschreitung führt zu permerror. Davon getrennt gilt: Ein include:, dessen Ziel keinen SPF-Record hat, einschließlich eines Namens, der nicht mehr existiert, liefert none, und der include-Mechanismus macht daraus sofort permerror, sodass ein veralteter Include einen Record für sich allein kaputt machen kann.
• Fan-out. Ein mx-Mechanismus darf nicht mehr als 10 Adress-Lookups auslösen. Bei ptr werden Namen jenseits der ersten 10 ignoriert.
• Nur ein Record. Veröffentlicht eine Domain mehr als einen Record, dessen Version genau v=spf1 lautet, ist das Ergebnis permerror.
• Größe. Der RFC rät, den veröffentlichten Record so klein zu halten, dass die Antwort in 512 Oktette passt und damit ohne EDNS(0) in einem einzigen UDP-Paket übertragen wird.
• Record-Typ. SPF muss als TXT-Record veröffentlicht werden. Der eigene SPF-Record-Typ aus der experimentellen Phase wurde eingestellt.
• Zeit. Empfänger sollten die Zeit für eine Auswertung begrenzen, aber mindestens 20 Sekunden zulassen. Wird dieses Zeitlimit überschritten, sollte das Ergebnis temperror lauten, ein temporärer Fehler, nicht permerror.

So kommen Sie wieder unter das Limit

1. Löschen Sie, was Sie nicht mehr nutzen. Ein gekündigter Dienst kostet weiterhin einen Lookup, sobald die Auswertung sein include erreicht. Tote Includes zu entfernen ist die günstigste Lösung.
2. Verlagern Sie Absender auf Subdomains. Jeder Name hat seinen eigenen Record und sein eigenes Budget von 10. Mail, deren Envelope-Sender auf news.example.com liegt, wird gegen den Record dieses Namens geprüft, nicht gegen den der Root-Domain. Bei relaxed Alignment ordnet DMARC die Subdomain weiterhin der Organisationsdomain zu.
3. Ersetzen Sie a und mx durch Literale, wenn die Server Ihnen gehören und sich selten ändern. ip4 und ip6 kosten nichts.
4. Flattening mit Vorsicht. Flattening ersetzt ein include durch die Adressen, in die es sich aktuell auflöst. Das besteht heute und scheitert lautlos, wenn der Anbieter seine Adressbereiche ändert.
5. Verzichten Sie auf ptr. Der RFC sagt, er sollte nicht veröffentlicht werden. redirect durch include zu ersetzen spart nichts, da beide einen Lookup zählen.
6. Nach Volumen ordnen, sich aber nicht darauf verlassen. Da die Auswertung beim ersten Treffer endet, verbrauchen die meisten Mails weniger Lookups, wenn Literale und Ihre volumenstärksten Absender zuerst stehen. Das verringert, wie oft das Limit zuschlägt; es macht einen Record über dem Limit nicht gültig und kann den Fehler verbergen, bis ein selten genutzter Absender sendet.

Ein permerror ist nicht nur für SPF selbst von Bedeutung. DMARC (RFC 7489) besteht, wenn SPF oder DKIM für eine übereinstimmende Domain (Alignment) besteht, und permerror ist kein pass, sodass SPF nichts mehr beitragen kann. Fehlt auch DKIM oder stimmt es nicht überein, besteht die Nachricht DMARC nicht. Um Ihre eigene Zählung zu sehen, folgt der SPF-Checker jedem Include und Redirect und zählt die Lookups über den gesamten Baum gegen das Limit von 10. Das ist eine Worst-Case-Zählung der Terme und nicht nur derjenigen, die eine bestimmte Nachricht auslösen würde. Wenn Sie den Record ändern, senken Sie zuvor seine TTL, damit sich ein Fehler schnell zurücknehmen lässt; siehe DNS-TTL erklärt. Das größere Bild finden Sie in SPF, DKIM und DMARC erklärt.

Quellen und weiterführende Literatur

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (Kitterman, 2014)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Kucherawy and Zwicky, 2015)