Welche SPF-Lookups wirklich zählen (und welche nicht)
Das 10-Lookup-Limit aus RFC 7208 ist das am häufigsten missverstandene Thema bei SPF. Fast alle zählen ihre
include:-Anweisungen, sehen, dass sie unter 10 liegen, und gehen davon aus, dass alles in Ordnung ist.
Wahrscheinlich ist es das nicht. Das Limit zählt weit mehr als include:-Zeilen, und wer falsch zählt, verwandelt den SPF-Eintrag
unbemerkt in einen PermError. Das ist nicht dasselbe wie SPF-Fail, aber viele Empfänger behandeln ihn so streng, dass die
E-Mail-Zustellbarkeit leidet (manche verhalten sich praktisch so, als gäbe es keinen brauchbaren SPF-Eintrag).
Hier die genaue Aufschlüsselung: was zum 10-Lookup-Limit zählt und was nichts kostet.
Die Regel, die alle zitieren
"An SPF implementation MUST limit the total number of DNS lookups to 10."
Das steht in RFC 7208, Abschnitt 4.6.4. Das Wort, über das viele stolpern, ist total. Es sind nicht 10
include:-Direktiven, sondern 10 DNS-Lookups, und mehrere Dinge erzeugen mehr als einen.
Was zum Limit zählt
Jeder include:, plus das, was dahinter steckt
Jeder include: zählt als einer der 10, nämlich für den SPF-Eintrag der eingebundenen Domain selbst. Wenn
dieser Eintrag weitere include:-, mx-, a-, ptr- oder exists-Terme nutzt,
zählen auch diese, und sie verstecken sich meist über mehrere Ebenen.
Die Zahlen der Anbieter ändern sich. include:spf.protection.outlook.com ist derzeit eine flache ip4:/ip6:-Liste
(1 Lookup). SendGrid und Mailgun verschachteln weiterhin. Prüfen Sie die aktuelle Kette, statt sich auf eine Tabelle aus einem
Blogartikel zu verlassen.
Der mx-Mechanismus (ein Term, nicht einer pro MX-Host)
mx zählt als genau ein Term zum 10-Term-Limit, auch wenn die Domain mehrere MX-Hosts veröffentlicht. Der Empfänger
muss trotzdem die A/AAAA-Einträge dieser Hosts auflösen (zusätzliche DNS-Arbeit), aber diese Adress-Lookups unterliegen einem
separaten Limit aus RFC 7208: höchstens 10 Adress-Einträge pro mx-Auswertung. Sie verbrauchen
nicht jeweils einen weiteren der 10 Plätze. Das Gegenteil ist ein verbreiteter Irrtum, der zu falschen Zählungen führt.
Der a-Mechanismus
a zählt als ein Term. Ein Adress-Lookup kann mehrere A/AAAA-Einträge zurückgeben; mehrere Adressen in dieser
Antwort multiplizieren den Zähler nicht. Dasselbe gilt für ptr und exists: Jeder ausgewertete Term zählt einmal,
mit eigenen zusätzlichen Verarbeitungsregeln im RFC.
redirect (dasselbe Limit wie include)
Ein redirect=-Modifier wird gegen dasselbe 10-Term-Limit ausgewertet, nicht gegen ein neues. Ein Redirect, der selbst Includes
nutzt, verbraucht Ihr Lookup-Budget genauso wie ein Include.
Was NICHT zählt
ip4:- und ip6:-Mechanismen: immer kostenlos
Direkte IP-Mechanismen sind nie DNS-Lookups. Darauf beruht SPF-Flattening: Lookup-intensive include:-Ketten durch
flache ip4:/ip6:-Listen ersetzen, und Ihr Eintrag kommt insgesamt mit 1 Lookup aus.
Ein include:, dessen Domain keinen SPF-Eintrag hat
Wenn die eingebundene Domain keinen SPF-Eintrag veröffentlicht, kostet der include: trotzdem einen Ihrer 10
Lookups, nämlich den, der das leere Ergebnis festgestellt hat. Eine Ausnahme gibt es nicht. Leere oder NXDOMAIN-Antworten speisen außerdem das
separate Void-Lookup-Limit (Implementierungen SOLLEN nach zwei abbrechen), sodass fehlerhafte Includes einen Fehlschlag auslösen können, bevor Sie 10
Terme erreichen.
exp: der Erklärungs-Modifier
exp= verweist auf einen Makro-String in einem TXT-Eintrag, der erst nach einem Fail-Ergebnis nachgeschlagen wird. Er
zählt während der Auswertung nicht zum 10-Term-Limit. Dasselbe gilt für all.
Der versteckte Stolperstein: verschachtelte Includes
Das Unangenehme: Anbieter verschachteln Includes. Ein „einfacher“ Eintrag wie dieser:
v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:mailgun.org ~all
sieht nach 3 Lookups aus, verbraucht derzeit aber etwa 8, sobald die Ketten aufgelöst sind: Outlook ist flach
(1), SendGrid bindet ab.sendgrid.net ein (2), und Mailgun fächert über US- und EU-SPF-Bäume
auf (5). Fügen Sie ein mx oder einen weiteren Anbieter-Include hinzu, und Sie stehen unbemerkt am Limit.
include:-Zeilen in Ihrem TXT-Eintrag ist fast nie die Zahl,
die ein Empfänger auswertet.
Der praktische Weg zur Prüfung
Per Augenmaß lässt sich das nicht zuverlässig zählen. Die korrekte Zahl ist die ausgewertete DNS-Lookup-Anzahl, und dafür brauchen Sie ein Tool, das die volle Kette durchläuft.
Nutzen Sie das kostenlose Lookup-Tool auf spflat.cloud: Geben Sie Ihre Domain ein, und das Tool meldet die echte Lookup-Anzahl, ob Sie am oder über dem 10-Lookup-Limit liegen und ob gerade ein PermError auftritt. Kein Konto nötig.
Wenn „unter 10“ nicht reicht
Selbst bei 8 oder 9 Lookups sind Sie eine Anbieter-Änderung von einem PermError entfernt. E-Mail-Anbieter fügen routinemäßig CIDR-Bereiche
hinzu oder entfernen sie; sobald ein verschachtelter Include um eine Ebene wächst, kippt Ihr Eintrag in permerror und Empfänger
behandeln ihn als fehlend.
Deshalb ist korrektes Zählen wichtig. Und deshalb ist automatisches Flattening (das die ganze Kette in direkte IPs auflöst und sie aktualisiert, wenn Anbieter-Bereiche sich ändern) der einzige Weg ist, langfristig gut unter dem Limit zu bleiben, ohne ständig nachzupflegen.
Wichtigste Erkenntnisse
- Zählen Sie die ausgewerteten Lookups, nicht Ihre
include:-Zeilen. mxundakosten Lookups;ip4:/ip6:kosten nichts.- Verschachtelte Includes verstecken die echte Zahl.
- Prüfen Sie die tatsächliche Anzahl mit einem Tool, nicht mit Kopfrechnen.
Prüfen Sie Ihre echte SPF-Lookup-Anzahl
Kostenlos, ohne Anmeldung. Sehen Sie die ausgewertete DNS-Lookup-Anzahl (inklusive verschachtelter Includes) und ob Sie am oder über dem 10-Lookup-Limit liegen.
Prüfen Sie Ihren SPF-EintragOder starten Sie Ihre kostenlose 14-Tage-Testversion →