Warum das Limit existiert
Jeder empfangende Server, der SPF auswertet, muss dafür DNS-Abfragen stellen. Ohne Obergrenze ließe sich das missbrauchen: Ein Record, der auf einen Record verweist, der auf zehn weitere verweist, verwandelt jede eingehende Nachricht in eine Lawine von Anfragen gegen ein fremdes Ziel. RFC 7208 zieht die Grenze deshalb bei zehn Lookups — und zwar nicht pro Record, sondern für die gesamte Auswertung einschließlich aller verschachtelten Ketten.
Das ist die Stelle, an der SPF in der Praxis am häufigsten kippt. Ein Record wie v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all sieht nach drei Lookups aus. Tatsächlich zählt jeder dieser includes den eigenen Aufruf plus alles, was in dem geholten Record wiederum steht — bei Google sind das derzeit vier weitere. Wer nur die eigene Zeile zählt, liegt regelmäßig um den Faktor drei daneben.
Was AnalyzeMy.Email prüft
- Rekursive Gesamtzahl — jeder
include:undredirect=wird tatsächlich aufgelöst und der geholte Record weiter ausgewertet, mit Schleifenschutz und Tiefenbegrenzung. - Was zählt und was nicht —
a,mx,ptr,exists,includeundredirectkosten je einen Lookup.ip4:,ip6:,allundexp=kosten keinen. - Void-Lookups — Abfragen, die mit NXDOMAIN oder leerer Antwort zurückkommen. Davon erlaubt RFC 7208 §4.6.4 nur zwei; die dritte ist ein permerror, auch wenn die Gesamtzahl weit unter zehn liegt.
- Sublimit für
mx— liefert der MX-Lookup mehr als zehn Records, ist das ebenfalls ein permerror. - Sublimit für
ptr— über zehn PTR-Records hinaus wird der Rest schlicht ignoriert, ohne Fehlermeldung. - Nicht auflösbare includes — ein include auf eine Domain ohne SPF-Record wird eigens ausgewiesen.
Der Report zeigt das Ergebnis als Aufschlüsselung: welcher Mechanismus wie viele Lookups beigesteuert hat, dazu eine Fortschrittsleiste gegen das Limit und ein eigenes Kennzeichen für Void-Lookups.
Warum die Zahl allein nicht reicht
Ein permerror ist deutlich schlimmer als ein fail. Bei fail weiß der Empfänger, dass der Absender nicht autorisiert ist — die Aussage ist gültig, nur negativ. Bei permerror ist die Auswertung abgebrochen: Es gibt gar kein Ergebnis. Für DMARC bedeutet das, dass SPF als Nachweis komplett ausfällt; die Nachricht besteht dann nur noch, wenn DKIM passt und ausgerichtet ist.
Besonders tückisch: Die Zahl ist nicht stabil. Sie hängt davon ab, was in fremden Records steht, und die ändern sich ohne Vorwarnung. Ein Record, der heute bei neun liegt, ist morgen bei elf, weil ein Dienstleister seinen eigenen include erweitert hat. Wer knapp unter dem Limit fährt, hat kein funktionierendes SPF, sondern eine Zeitbombe.
Was du tun kannst
- Puffer einplanen: Sieben oder acht Lookups sind die sinnvolle Obergrenze, nicht zehn.
- Unbenutzte includes streichen — der häufigste und mit Abstand risikoärmste Gewinn. Dienste, die vor zwei Jahren einmal getestet wurden, stehen erstaunlich oft noch drin.
- Subdomains trennen: Newsletter über
mail.example.commit eigenem SPF-Record versenden. Jede Domain hat ihr eigenes Budget. - Vorsicht beim Flattening: includes durch die dahinterliegenden
ip4:-Blöcke zu ersetzen senkt die Zahl sofort — verpflichtet dich aber darauf, die IPs deines Dienstleisters dauerhaft nachzupflegen. Ändert er sie, bricht dein Versand.