Globaler SPF-Validation Checker
Das Sender Policy Framework (SPF) ist ein kritisches E-Mail-Authentifizierungsprotokoll, das Domain-Spoofing verhindert, indem es eine kryptografische Whitelist autorisierter Versand-IP-Adressen veröffentlicht. Während das SPF-Protokoll selbst für die moderne Zustellbarkeit unerlässlich ist, hat der dedizierte SPF-DNS-Record-Typ (Type 99) eine unglaublich chaotische Geschichte und ist offiziell obsolet.
Aufstieg und Fall von Record Type 99
Als das SPF-Protokoll ursprünglich konzipiert wurde (RFC 4408), entwickelte die IETF einen spezifischen DNS-Resource-Record (Type 99), der explizit darauf ausgelegt war, SPF-Payloads von Standard-TXT-Daten zu trennen. Die Theorie war, dass die Beibehaltung eines dedizierten Record-Typs das Parsen durch Resolver beschleunigen würde. Das Rollout war jedoch ein massiver Fehlschlag. Legacy-DNS-Server, Firewalls und Hardware-Load-Balancer erkannten die neue Type-99-Syntax nicht und verwarfen die Pakete häufig, was zu weit verbreiteten E-Mail-Ausfällen führte. In Anerkennung dieser Hardware-Inkompatibilität veröffentlichte die IETF RFC 7208, der den Type-99-Record offiziell als "deprecated" einstufte. Heute müssen alle SPF-Konfigurationen als Standard-TXT-Records veröffentlicht werden. Wenn ein Administrator weiterhin einen veralteten Type-99-SPF-Record deployt, werden moderne Plattformen wie Microsoft Exchange und Google Workspace diesen vollständig ignorieren, was zu sofortigen DMARC-Fehlern führt.
Das mechanische 10-Lookup-Limit
Der markanteste technische Fehlerpunkt für Entwickler beim Verwalten von SPF ist die strikte Grenze von 10 Lookups. Da ein SPF-Record es Administratoren erlaubt, andere Domain-Richtlinien über die include:-Direktive zu verschachteln (z. B. include:_spf.salesforce.com), muss ein empfangender Mailserver eine rekursive DNS-Abfrage durchführen, um die IPs von diesem Drittanbieter abzurufen. Um MTAs vor Endlosschleifen beim Routing und gezielten DDoS-Amplification-Angriffen zu schützen, begrenzt das Protokoll die Ausführung hart auf 10 rekursive DNS-Lookups. Wenn ein Unternehmen zu viele SaaS-Anbieter verkettet und 11 Lookups erreicht, bricht die Ausführung ab und gibt einen SPF-"PermError" zurück. Dies führt sofort dazu, dass legitime ausgehende E-Mails hart bouncen oder in der Quarantäne landen.
Flattening und Diagnostik
Um die Lookup-Beschränkungen zu umgehen, nutzen Network Engineers "SPF Flattening"-Tools. Diese Skripte laufen stündlich, expandieren alle include:-Direktiven via API, entfernen die Hostnamen und kompilieren die rohen IPv4/IPv6-Blöcke zu einem massiven, flachen TXT-Record. Die Verwendung eines globalen Diagnose-Checkers stellt sicher, dass Ihre Syntax gültig ist, Ihre verschachtelten Includes das DNS-Limit nicht stillschweigend überschritten haben und Ihre Richtlinie explizit mit einem restriktiven -all (Fail) oder ~all (Softfail) Flag endet, um gespoofte Payloads abzulehnen.