Defaults.Exposed › Behebungen › Guides

SPF PermError: wie Sie „Too Many DNS Lookups“ beheben, ohne Ihre E-Mail zu brechen (2026)

Veröffentlicht 2026-07-08

Zahlen mit Stand 2026-06-29 · Methodik v7. Aggregierte Zensusdaten über 261 Millionen bewertete Domains. Siehe wie wir bewerten.

Mindestens 797.263 Domains überschreiten SPFs 10-DNS-Lookup-Limit, laut dem Defaults.Exposed-Zensus über 261.086.232 Domains — von 139 Millionen SPF-Veröffentlichern. Über zehn Lookups hinaus stoppt ein Empfänger und liefert PermError: Ihr SPF ist ungültig, und DMARC zählt einen PermError als Fehlschlag.

Die Lösung hat eine strikte Reihenfolge, und die meisten Ratgeber drehen sie um. Zählen Sie Ihre echten, aufgelösten Lookups; löschen Sie tote und ungenutzte Includes — das allein repariert die meisten Einträge; verlegen Sie Massenversender auf Subdomains mit eigenem SPF-Budget; flatten Sie nur als letztes Mittel, und nur mit automatisiertem Re-Flattening, denn statisches Flattening verrottet und bricht die Zustellung still.

Was bedeutet „SPF PermError: too many DNS lookups“?

RFC 7208 §4.6.4 begrenzt jede SPF-Prüfung auf 10 DNS-Lookups. Über zehn hinaus stoppt der Empfänger und liefert PermError — der gesamte Eintrag gilt als kaputt, nicht nur der Teil über dem Budget. Derselbe Abschnitt fügt eine weniger bekannte zweite Obergrenze hinzu: höchstens 2 „void lookups“ (Abfragen ohne Antwort oder NXDOMAIN), sodass ein paar tote include:-Einträge für gekündigte Dienste Ihr SPF allein schon ungültig machen können.

Die Konsequenz ist schlimmer als „kein SPF“: DMARC behandelt einen PermError als SPF-Fehlschlag, also ist eine Domain, die ihr eigenes SPF bricht, auf dem SPF-Bein jeder DMARC-Bewertung unauthentifiziert. Ist DKIM nicht eingerichtet oder bricht unterwegs, scheitert diese Mail jetzt komplett an DMARC.

Eine Zensuszahl zeigt, wie grausam dieser Fehlermodus ist: 112.215 Domains veröffentlichen einen strikten -all-Eintrag, der wegen Lookup-Überlaufs ungültig ist — von den 54.655.923 Domains, die überhaupt -all veröffentlichen. Ihre Inhaber haben den schweren Teil erledigt — die strikte Endung gewählt — und ein Include zu viel hat den ganzen Eintrag abgeschaltet. Sie sehen strikt aus; sie sind kaputt. Für das vollständige Datenbild siehe den SPF-PermError-Bericht.

Warum ist mein SPF kaputtgegangen, obwohl ich nichts geändert habe?

Weil das Budget größtenteils von den Einträgen anderer Leute verbraucht wird. Jeder include: wird rekursiv ausgewertet, und jeder Lookup-Mechanismus darin zählt gegen Ihre zehn. Eine Zeile in Ihrem DNS-Panel kann aufgelöst vier oder fünf Lookups kosten. Ein Anbieter verschachtelt einen weiteren Include, und Ihr SPF stirbt, ohne dass sich eine einzige Zeile in Ihrer Zone geändert hat.

Die großen Plattformen sind nicht das Problem: Google und Microsoft haben beide ihr eigenes SPF geflacht — _spf.google.com und spf.protection.outlook.com expandieren zu reinen IP-Listen, die null interne Lookups kosten (verifiziert gegen Live-DNS, Juli 2026). Reale Ausfälle stammen von Include-Ketten von Hosting-Panels, die mehrere Ebenen tief verschachtelt sind, und von ehrlichem SaaS-Stapeln — Mailbox plus Newsletter plus CRM plus Helpdesk, jedes „nur ein Include“. Niemand fügt den elften Lookup absichtlich hinzu; er entsteht als Summe vernünftiger Entscheidungen. Deshalb ist der Rand des Abgrunds so überfüllt: 2.119.539 Domains stehen bei genau 9–10 aufgelösten Lookups — etwa 1 von 66 aller SPF-Veröffentlicher, heute in Ordnung, ungültig an dem Tag, an dem jemand einen weiteren Include einfügt. Der SPF-Eintrag am 99. Perzentil löst bereits zu 9 Lookups auf. Ist Ihr Stack SaaS-lastig, behandelt der Leitfaden „SPF scheitert bei SaaS-Tools“ die Version je Anbieter.

Welche Teile eines SPF-Eintrags zählen als DNS-Lookups?

Zählen Sie die aufgelöste Gesamtzahl, nicht die sichtbaren Zeilen. Vier Includes können vier Lookups sein oder vierzehn.

Wie behebe ich „too many DNS lookups“, ohne E-Mail zu brechen?

1. Führen Sie den kostenlosen Scan durch, bevor Sie DNS anfassen. Er löst Ihre vollständige Include-Kette auf und zeigt Ihre echte Lookup-Anzahl, damit Sie das tatsächliche Problem reparieren — nicht den Eintrag, wie er in Ihrem Panel erscheint. (Sagt er, Sie hätten überhaupt kein SPF, ist das ein anderer Fehler — siehe „SPF record not found“.)
2. Löschen Sie zuerst tote und ungenutzte Includes. Das Tool, das Sie 2023 aufgegeben haben, der Include des alten Hosters, der eine Migration überlebt hat, Duplikate, jeder ptr-Mechanismus. Tote Includes sind doppelt toxisch: Sie verbrennen Lookup-Budget und sie sind die übliche Quelle für Void-Lookups. Die meisten Einträge über Budget kommen allein durch diesen Schritt wieder unter 10. Trägt Ihr Eintrag noch Mechanismen eines früheren Anbieters, folgen Sie dem Migrations-Aufräum-Leitfaden.
3. Prüfen Sie, ob jeder verbleibende Include etwas bewirkt. Empfänger bewerten SPF gegen die Return-Path-Domain (RFC5321.MailFrom), nicht den From-Header — und viele SaaS-Tools setzen ihre eigene Bounce-Domain in den Return-Path, sodass ihr Include in Ihrem Eintrag nichts bewirkt außer Budget zu verbrauchen. Behalten Sie Includes nur für Dienste, die Ihre Domain als Return-Path nutzen; aktivieren Sie für den Rest stattdessen das Custom-Domain-DKIM des Anbieters.
4. Verlegen Sie Massenversender auf Subdomains. Newsletter von news.ihredomain.com, transaktionale Mail von mail.ihredomain.com. Jede Subdomain bekommt ihren eigenen SPF-Eintrag mit frischem 10-Lookup-Budget, und ein Problem in einem Strom blutet nicht mehr in die anderen über.
5. Erst dann Flattening in Betracht ziehen — und nur automatisiertes Flattening. Siehe unten.
6. Erneut scannen, um zu bestätigen, dass Sie komfortabel unter 10 liegen — zielen Sie auf Spielraum, nicht genau auf 10, sonst gehören Sie wieder zu den 2,1 Millionen Domains am Rand des Abgrunds. Arbeiten Sie dann alles Weitere ab, was der Scan auf der Seite SPF reparieren markiert.

Sollte ich meinen SPF-Eintrag flatten?

Flattening ersetzt Includes durch ihre zugrundeliegenden ip4:/ip6:-Blöcke, die null Lookups kosten. Es funktioniert — und von Hand gemacht, ist es ein Zustellungsausfall mit Zeitzünder.

Anbieter rotieren sendende IPs routinemäßig und kündigen es niemandem an. Eine statische IP-Liste ist an dem Tag korrekt, an dem Sie sie einfügen, und wird innerhalb von Monaten still falsch — und weil sich der Fehler dadurch zeigt, dass andere Leute Ihre Mail nicht erhalten, erfahren Sie es spät. Bringen Sie Ausdünnen und Subdomains Sie unter das Limit, hören Sie dort auf; kopieren Sie nie die IP-Blöcke eines Drittanbieters von Hand als dauerhafte Lösung in Ihren Eintrag.

Häufig gestellte Fragen

Bedeutet ein SPF-PermError, dass meine E-Mail nicht mehr zugestellt wird? Nicht sofort — das macht es gefährlich. DMARC zählt einen PermError als SPF-Fehlschlag, also hängt die Zustellung vollständig an DKIM; fehlt DKIM oder bricht es unterwegs, scheitern Sie an DMARC. Von 139 Millionen SPF-Veröffentlichern in unserem Zensus (Stand 2026-06-29) befinden sich mindestens 797.263 in diesem Zustand — die meisten, ohne es zu wissen.

Mein Eintrag hat nur vier Includes — wie kann er über 10 Lookups liegen? Includes werden rekursiv gezählt: alles darin (und in ihren Includes) wird Ihrem Budget angelastet, sodass vier sichtbare Zeilen zu vierzehn Lookups auflösen können. Zählen Sie mit einem auflösenden Tool, nicht nach Augenmaß — das Auflösen der Ketten ist, wie unser PermError-Bericht ~100× mehr kaputte Domains fand, als Oberflächenzählungen zeigen.

Ich beende meinen Eintrag mit -all — bin ich damit nicht geschützt? Nur, wenn der Eintrag ausgewertet wird. Unser Zensus (Stand 2026-06-29) fand 112.215 Domains, deren strikte -all-Einträge durch Lookup-Überlauf ungültig sind. Ein strikter Qualifier auf einem PermError-Eintrag schützt nichts.

Gilt das Limit von 10 Lookups pro Include oder für den ganzen Eintrag? Für die gesamte Auswertung: RFC 7208 §4.6.4 begrenzt die vollständige Prüfung auf 10, plus höchstens 2 Void-Lookups. Jede Subdomain hat ihren eigenen Eintrag und ihr eigenes Budget — weshalb Schritt 4 funktioniert.

Zählen ip4- und ip6-Einträge zum Limit? Nein — IP-Mechanismen kosten nichts, genau deshalb reduziert Flattening die Anzahl.

Senden Sie dem Inhaber den Bericht

Wenn Sie das für einen Kunden oder Ihren Arbeitgeber reparieren, schließen Sie den Job mit einem Beleg ab. Führen Sie den kostenlosen Scan nach Ihren Änderungen erneut durch und leiten Sie den bewerteten Bericht an den Geschäftsinhaber weiter: klare Sprache, datiert, PermError verschwunden. Das ist das Artefakt, das er für die Cyberversicherungs-Verlängerung und den nächsten Kunden-Sicherheitsfragebogen braucht — der Unterschied zwischen „ich habe ein paar DNS-Einträge geändert“ und einem dokumentierten Vorher-Nachher.

Prüfen Sie Ihre Domain kostenlos

Sehen Sie Ihre echte, aufgelöste Lookup-Anzahl — und alles Weitere zu SPF, DKIM und DMARC — privat und nur für den Inhaber.

Prüfen Sie Ihre Domain → · SPF reparieren → · SPF scheitert bei SaaS-Tools → · SPF bei GoDaddy einrichten → · Wie wir bewerten → · Nur aggregierte Daten. Daten werden in der EU gespeichert und verarbeitet.