Eine E-Mail zur Passwortzurücksetzung wird versendet. Sie kommt jedoch nie an. Keine Fehlermeldung seitens des Absenders, kein Bounce, keine Warnung im Versand-Tool. Nur Stille. In einigen Fällen besteht die Ursache in einem SPF-Eintrag, der seine Grenze von 10 DNS-Abfragen überschritten hat, ohne dass jemand in der Organisation dies bemerkt. Dies wird als PermError bezeichnet. Er tritt häufiger auf, als man denkt, besonders in Unternehmen, die mehrere SaaS-Dienste für den Versand nutzen.
Was die SPF-Grenze ist und warum sie existiert
Der SPF (Sender Policy Framework) ist ein E-Mail-Authentifizierungsprotokoll, das es einer Domäne ermöglicht, festzulegen, welche Server im Namen der Domäne senden dürfen. Die Grenze von 10 DNS-Abfragen pro SPF-Überprüfung ist in der RFC 7208 (IETF, 2014), der offiziellen Spezifikation des Protokolls, festgelegt. Sie ist nicht optional: Die RFC legt fest, dass eine SPF-Implementierung einen dauerhaften Fehler zurückgeben muss, wenn diese Grenze überschritten wird.
Der technische Grund ist greifbar. Jeder SPF-Mechanismus vom Typ include:, a, mx, ptr oder exists löst eine zusätzliche DNS-Anfrage aus. Ohne Obergrenze könnte eine böswillige oder fehlerhafte SPF-Regel dazu führen, dass Empfangsserver Dutzende von DNS-Anfragen nacheinander ausführen müssen, was eine übermäßige Belastung der rekursiven Resolver darstellt und DDoS-Angriffen eine Tür öffnet. Die Mechanismen ip4:, ip6: und all lösen keine Anfragen aus und zählen nicht zur Grenze.
Diese Obergrenze stammt aus einer Zeit, als ein Unternehmen selten mehr als einen oder zwei E-Mail-Dienstleister hatte. Im Jahr 2014 existierte Microsoft 365 noch nicht unter diesem Namen, Salesforce Marketing Cloud hieß noch Exact Target und HubSpot war nur ein Bruchteil seiner heutigen Größe. Die Grenze wurde für eine Welt konzipiert, die nicht mehr unsere ist.
Warum heutige SaaS-Unternehmen diese Grenze erreichen, ohne es zu merken
Das Problem liegt in der Art und Weise, wie moderne E-Mail-Dienste ihre eigenen SPF-Einträge veröffentlichen. Ein include:-Verweis auf einen Dienstleister kostet nicht nur eine einzelne Abfrage: er kostet so viele, wie der Dienstleister in seinem eigenen Eintrag festgelegt hat, einschließlich verschachtelter Inklusionen. Google Workspace (_spf.google.com) alleine verbraucht zwischen 3 und 5 Abfragen. Microsoft 365 (spf.protection.outlook.com) verbraucht 3 bis 5, je nach regionaler Konfiguration. Hinzu kommen SendGrid (1 bis 3), Salesforce (1 bis 3) und HubSpot (1 bis 2): Die Summe übersteigt 10, noch bevor der Abrechnungsservice, die HR-Plattform oder das Support-Tool hinzugefügt werden.
Das verschlimmert sich noch dadurch, dass die Dienstleister ihre DNS-Infrastruktur ändern können, ohne den Kunden zu informieren. Der Dienst, für den man vor sechs Monaten ein include: erteilt hat, könnte inzwischen neue Server hinzugefügt haben, was den Abfragezähler von 9 auf 12 erhöht, ohne dass man selbst etwas unternommen hat. Laut Daten von dmarcchecker.app für die Top 1 Million Domains (2024) haben 2% der Domains mit einem gültigen SPF-Eintrag bereits eine ungültige Konfiguration, die einen PermError verursacht. Diese Zahl erscheint gering, repräsentiert jedoch Tausende von Organisationen, deren legitime E-Mails dauerhaft beeinträchtigt sind, oft ohne das Wissen der IT-Teams.
Was konkret passiert, wenn die Grenze überschritten wird
Wenn eine SPF-Überprüfung 11 DNS-Abfragen erreicht, gibt der Empfangsserver ein permerror-Ergebnis zurück, einen dauerhaften, nicht wiederherstellbaren Fehler. Was dann mit der E-Mail geschieht, hängt von der konfigurierten DMARC-Richtlinie der Absender-Domäne ab.
Mit p=none wird die E-Mail in der Regel trotz des PermErrors zugestellt. Die Domäne wird als nicht authentifiziert behandelt. Das gibt eine falsche Sicherheit: Die E-Mails kommen an. Der Schutz gegen die Nachahmung der Domäne existiert nicht. Mit p=quarantine landen die E-Mails im Spam, ohne Alarm auf der Absenderseite. Mit p=reject, der strengsten Richtlinie, die Google und Yahoo seit Februar 2024 für Absender von mehr als 5000 Nachrichten pro Tag fordern, werden die E-Mails abgelehnt. Bestellbestätigungen, Passwortzurücksetzungen, Sicherheitswarnungen und interne Kommunikation verschwinden ohne Spur in den Versand-Tools.
Das ist das schwerste Szenario zur Diagnose. Die E-Mail geht hinaus. Sie kommt nicht zurück. Sie kommt nicht an.
SPF-Flattening: Warum die schnelle Lösung die Dinge verschlimmert
Die häufigste Reaktion auf dieses Problem ist das SPF-Flattening: alle include:-Mechanismen werden durch die entsprechenden IP-Adressen ersetzt, was die Anzahl der Abfragen auf null oder fast null reduziert. Das unmittelbare Ergebnis ist positiv. Die mittelfristigen Effekte sind jedoch problematischer.
Der CTO von dmarcian fasst das Grundproblem gut zusammen: Die meisten geflatteten Einträge erlauben schließlich viel zu breite IP-Adressbereiche, die zu großen Cloud-Hostern gehören, von denen ein Teil nicht zu einem tatsächlichen Sendeserver des Dienstleisters gehört. Böswillige Akteure können diese erlaubten Bereiche ausnutzen, um von Ihrer Domäne zu senden. Man löst ein Lieferbarkeitsproblem und schafft ein Sicherheitsproblem.
Ein weiteres Problem ist die Wartung. E-Mail-Dienstleister ändern ihre IP-Pools regelmäßig und ohne Vorankündigung. Ein geflatteter Eintrag muss bei jeder Änderung manuell aktualisiert werden, sonst werden die neuen Server des Dienstleisters ausgeschlossen und die von ihnen bearbeiteten E-Mails bestehen die SPF-Authentifizierung nicht. Das Flattening verwandelt ein Konfigurationsproblem in eine dauerhafte operative Last.
Nachhaltige Ansätze
Der erste Schritt ist ein Audit zur tatsächlichen Zählung. Werkzeuge wie MXToolbox und der SPF Record Checker von dmarcian analysieren Ihren SPF-Eintrag und zählen die lookups und eingeschlossenen Sub-Inklusionen. Ohne dieses Audit ist es unmöglich zu wissen, wo die Zählung steht.
Die Segmentierung durch Sub-Domains ist der zuverlässigste Architekturenansatz. Wenn Sie Marketing-E-Mails auf marketing.ihreDomain.com und Transaktions-E-Mails auf benachrichtigungen.ihreDomain.com verschieben, erhält jede Sub-Domain ihr eigenes Kontingent von 10 Abfragen. Diese Trennung hat einen zusätzlichen Vorteil: Ein Reputationsproblem bei Marketing-Kampagnen wirkt sich nicht auf kritische Transaktions-E-Mails aus.
Für Domains, die nicht leicht segmentierbar sind, sind SPF-Makros eine ernsthafte Alternative. Sie verschieben die Bewertung aus der Standard-Lookup-Kette durch das Verschieben der Verifikation an einen externen Dienst via einer einzigartigen DNS-Abfrage. Lösungen funktionieren auf diesem Prinzip. Der Nachteil ist real: Wenn die Infrastruktur des Dienstleisters ausfällt, fällt auch die SPF-Authentifikation der Domäne.
Die am häufigsten vernachlässigte Maßnahme bleibt die Entfernung unnötig gewordener Einträge. Viele SPF-Einträge sammeln include:s von Dienstleistern, die das Unternehmen seit Monaten nicht mehr nutzt oder a und mx-Mechanismen aus einer alten Konfiguration. Ein jährliches Audit gewinnt oft mehrere Abfragen zurück, ohne die Versandarchitektur zu verändern.
Langfristige Überwachung, nicht nur einmalige Korrektur
Ein heute konformer SPF-Eintrag kann morgen die Grenze überschreiten, wenn ein Dienstleister seine Infrastruktur ändert. Die aggregierten DMARC-Berichte (RUA-Format) sind der zugänglichste Indikator: Sie zeigen den Prozentsatz der E-Mails, die die SPF-Authentifizierung pro deklarierte Absenderdomäne bestehen oder scheitern. Jede plötzliche Spitze von SPF-Fehlschlägen verdient eine sofortige Untersuchung der Anzahl der Abfragen.
Die Begrenzung von 10 SPF-Lookups ist eine Einschränkung von 2014, die seit der RFC 7208 nicht revidiert wurde. Organisationen, die zu DMARC im Erzwingungsmodus wechseln, wie Google es seit 2024 für Massenversender verlangt, entdecken sie manchmal im ungünstigsten Moment: Wenn ihre kritischen E-Mails nicht mehr ankommen und niemand weiß, warum.
Was ist ein PermError SPF?
Ein PermError SPF ist ein permanenter Fehler, der vom Empfangsserver zurückgegeben wird, wenn die SPF-Überprüfung nicht abgeschlossen werden kann, insbesondere weil die Anzahl der DNS-Abfragen 10 übersteigt. Im Gegensatz zu einem TempError (wiederherstellbarer temporärer Fehler) bleibt ein PermError bestehen, bis der SPF-Eintrag korrigiert wird. DMARC behandelt einen PermError als vollständigen SPF-Fehler.
Zählen die Mechanismen ip4 und ip6 in die Grenze von 10 Lookups?
Nein. Die Mechanismen ip4:, ip6: und all lösen keine DNS-Abfrage aus und zählen nicht zur Grenze. Nur Mechanismen, die eine DNS- Auflösung erfordern, werden gezählt: include:, a, mx, ptr, exists und der redirect-Modifikator.
Wie weiß ich, ob mein SPF-Eintrag die Grenze überschreitet?
Werkzeuge wie der MXToolbox SPF Checker und der Domänenprüfer von dmarcian analysieren den SPF-Eintrag und zählen die kaskadierenden DNS-Abfragen, einschließlich verschachtelter Inklusionen. Ein Ergebnis über 10 bestätigt, dass der Eintrag bei jeder Überprüfung einen PermError zurückgibt, unabhängig von der bestehenden DMARC-Richtlinie.
