E-Mail-Infrastruktur
SPF: zu viele DNS-Lookups, und das stille Scheitern, das es auslöst.
SPF ist auf zehn DNS-Lookups je Prüfung begrenzt. Überschreiten Sie dieses Limit, gibt Ihr Eintrag PermError zurück, der die Authentifizierung jeder Nachricht scheitern lässt, die Sie senden — still, ohne Bounce, sichtbar nur als verschwindende Mail und scheiternde DMARC-Berichte. Die Mechanismen, die einen Lookup kosten, sind include, a, mx, ptr, exists und redirect; ip4, ip6 und all sind kostenlos. Die ehrliche Lösung ist selten ein Flattening-Werkzeug: entfernen Sie ungenutzte Includes, werfen Sie das veraltete ptr hinaus und delegieren Sie SPF an eine Subdomain, damit Ihr Root-Eintrag bei einem einzigen Lookup bleibt.
Kurz gefasst
- Die Grenze ist 10 Lookups, plus 2 Void. Definiert in RFC 7208 §4.6.4; überschreiten Sie eine, gibt es PermError.
- PermError lässt Ihre gesamte Mail scheitern, still. Nicht nur den Zusatzdienst — jede Nachricht, ohne Bounce zur Warnung.
- include, a, mx, ptr, exists, redirect kosten Lookups. ip4, ip6 und all sind kostenlos.
- Nur ein SPF-Eintrag. Zwei v=spf1-Einträge verursachen PermError, egal wie hoch die Lookup-Zahl ist.
- Delegation schlägt Flattening. Eine delegierte _spf-Subdomain ist statisch; Flattening veraltet, wenn Anbieter-IPs sich ändern.
Warum bricht SPF in dem Moment, in dem Sie einen Dienst mehr hinzufügen?
Das Sender Policy Framework lässt einen Domain-Inhaber die Server auflisten, die in seinem Namen Mail senden dürfen, und ein empfangender Server prüft diese Liste, bevor er entscheidet, wie er eine Nachricht behandelt. Um sie auszuwerten, löst der Empfänger die Mechanismen Ihres Eintrags per DNS auf — und RFC 7208 §4.6.4 begrenzt diese Arbeit auf 10 DNS-querying mechanism lookups, plus a separate cap of 2 void lookups, per check. Die Grenze besteht aus gutem Grund: ohne sie könnte ein bösartiger Eintrag Verweise verketten, um Hunderte DNS-Abfragen auszulösen und jeden Empfänger zu einem Denial-of-Service-Verstärker zu machen.
Das Problem ist, dass das Limit sich anschleicht. Ein Eintrag mit drei Versendern läuft perfekt. Über ein paar Jahre fügt ein Team ein CRM, einen Helpdesk, eine Marketing-Plattform hinzu — jeweils ein harmlos aussehender Include — und eines Tages kippt der sechste die Zahl über zehn. Google Workspace alone consumes 3–4 lookups; a few more services and you hit the cap. Von diesem Moment an ist der Eintrag ungültig, und der Fehlermodus ist der grausame Teil: Exceeding either limit returns PermError, which fails SPF for every message from the domain — silently. There is no bounce on the sending side; the only evidence is missing mail and failing DMARC reports.
Das ist kein seltener Grenzfall. Ein Scan von 5,5 Millionen Domains im Jahr 2026 fand, dass 4.8% of SPF-enabled domains exceed the 10-lookup limit — 148,655 of 3.1M scanned (DMARCguard SPF Supply Chain Study, 2026, 5.5M Tranco domains). Jede dieser Domains sendet gerade jetzt Mail mit kaputter Authentifizierung, die meisten ahnungslos, weil nichts in ihren eigenen Systemen es ihnen sagt. Der Zustellbarkeitsschaden zeigt sich zuerst als langsames Abdriften in die Spam-Ordner, Wochen bevor jemand es bis zum Eintrag zurückverfolgt.
Wie sieht ein Eintrag über dem Limit aus — und die Lösung?
Hier ist ein Eintrag, der über das Limit gewachsen ist, wie die meisten: ein Haufen über die Zeit
angesammelter Includes, ein mx und ein veraltetes ptr, an dessen Hinzufügen
sich niemand erinnert. Er sieht vernünftig aus und gibt still PermError zurück.
# Vorher — 11 Lookups, scheitert still mit PermError
v=spf1 include:_spf.google.com # 3-4 Lookups
include:sendgrid.net # 1
include:servers.mcsv.net # Mailchimp · 1
include:_spf.salesforce.com # 1
include:spf.protection.outlook.com # 2-3
a mx ptr # 3 weitere — ptr ist veraltet
-all
Die dauerhafte Lösung hält den Root-Eintrag bei einem einzigen Lookup, indem sie die echte Liste an
eine Subdomain delegiert, während sie Ungenutztes entfernt, ptr hinauswirft und einen
statischen Versender in ein direktes ip4 umwandelt. Der delegierte Eintrag nutzt weiterhin
gewöhnliche Includes, sodass Ihre Anbieter ihre eigenen IPs weiter aktualisieren können.
# Nachher — die Root bleibt per Subdomain-Delegation bei EINEM Lookup
example.com. TXT "v=spf1 redirect=_spf.example.com"
# der delegierte Eintrag hält die echte Komplexität, an einer Stelle gepflegt
_spf.example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net
ip4:198.51.100.10 -all"
# ptr entfernt · statischer Versender durch ip4 ersetzt · ungenutzte Includes entferntLookups zählen
Welche Mechanismen kosten einen DNS-Lookup?
Das ganze Problem läuft darauf hinaus, welche Mechanismen DNS abfragen und welche nicht. Beherrschen Sie diese Tabelle, können Sie Ihren eigenen Eintrag von Hand zählen.
| Mechanismus | Was er tut | Lookup? |
|---|---|---|
| include | Kostet ≥1 Lookup und löst den eigenen SPF-Eintrag des Ziels auf, dessen verschachtelte Includes ebenfalls zählen. Der häufigste Mechanismus — rund ein Drittel aller SPF-Mechanismen in der Praxis. | Zählt |
| a | Löst die A/AAAA-Einträge der Domain auf. | Zählt |
| mx | Ein Lookup, plus einer je zurückgegebenem MX-Host — kann überraschend teuer werden. | Zählt |
| ptr | Reverse-DNS je verbindender IP, langsam und unzuverlässig. RFC 7208 rät davon ab — entfernen Sie ihn. | Zählt (veraltet) |
| exists / redirect | Jeder löst den SPF-Eintrag einer Domain auf; ein Lookup pro Stück. | Zählt |
| ip4 / ip6 / all | Literale Treffer — gar keine DNS-Abfrage. Nutzen Sie sie, um lookup-lastige Mechanismen für statische Versender zu ersetzen. | Ausgenommen |
Die nützlichste Gewohnheit ist, vor dem Hinzufügen zu zählen. Bevor Sie einen neuen Include an Ihren Eintrag schrauben, prüfen Sie die aktuelle Summe mit einem SPF-Analyzer — denn da sich die verschachtelten Includes im eigenen Eintrag eines Anbieters ohne Vorwarnung ändern können, kann ein Eintrag, der letzten Monat bei acht Lookups stand, heute bei elf liegen, ohne eine einzige Bearbeitung Ihrerseits. Es gibt zudem eine zweite, leisere Grenze: RFC 7208 §4.6.4 begrenzt Void-Lookups — Abfragen, die nichts zurückgeben — auf zwei, und ein einziger stillgelegter Dienst, dessen Include nun zu einem leeren Eintrag auflöst, kann sie allein auslösen.
Die Lösung
Es beheben, vom Schnellsten zum Nachhaltigsten
Arbeiten Sie die Liste der Reihe nach ab. Die frühen Schritte sind schnelle Erfolge; die späteren sind die strukturellen Lösungen, die das Problem fernhalten.
- 1
Bestätigen Sie, dass es wirklich ein PermError ist
Prüfen Sie Ihre Domain mit einem SPF-Checker wie MXToolbox; er zählt die verschachtelten Includes und meldet „zu viele DNS-Lookups“. Gegenprüfung: senden Sie einen Test an Gmail, öffnen Sie Original anzeigen und suchen Sie nach spf=permerror, und lesen Sie Ihre DMARC-Berichte, in denen das SPF-Ergebnis für jeden Versender permerror zeigt, nicht nur für einen.
- 2
Entfernen Sie Includes für Dienste, die Sie nicht mehr nutzen
Dies ist die sauberste und sicherste Lösung. Prüfen Sie jeden include-, a- und mx-Mechanismus; sendet der Dienst nicht mehr für Sie, löschen Sie ihn. Das beseitigt auch den Void-Lookup-PermError, den ein stillgelegter Dienst verursacht, dessen Include nun ins Leere auflöst.
- 3
Ersetzen Sie statische Versender durch direktes ip4 / ip6
Für jeden Versender auf einer festen IP — meist Ihr eigener Mailserver — tauschen Sie den include- oder a-Mechanismus gegen die IP selbst, die keinen Lookup kostet. Der Kompromiss: Sie übernehmen die Verantwortung für diese IP, da der Anbieter sie nicht mehr für Sie aktualisieren kann.
- 4
Entfernen Sie den veralteten ptr-Mechanismus
Taucht ptr irgendwo in Ihrem Eintrag auf, entfernen Sie ihn. Er führt für jede verbindende IP einen Reverse-DNS-Lookup aus, der langsam und unzuverlässig ist, und die Spezifikation rät davon ab. Ersetzen Sie ihn durch direkte IP-Verweise, wo Sie diese Hosts noch autorisieren müssen.
- 5
Delegieren Sie SPF an eine Subdomain
Auf lange Sicht zeigen Sie Ihren Root-Eintrag per redirect auf eine delegierte _spf-Subdomain, sodass die Root bei einem einzigen Lookup bleibt, während der delegierte Eintrag die echte Komplexität an einer gepflegten Stelle trägt. Das ist einmal konfiguriert statisch und die zuverlässigste Lösung für eine Domain mit vielen Versendern.
- 6
Behandeln Sie Flattening als letzte Wahl
Nur wenn Delegation nicht machbar ist, lösen Sie die Includes zu rohen IPs im Eintrag auf. Da sich Anbieter-IPs ändern, wird ein geflätteter Eintrag veraltet und bricht still, sofern Sie das periodische Neu-Flätten und die Überwachung nicht automatisieren — genau die Pflegelast, die Delegation vermeidet.
Subdomain-Delegation ist für fast jeden Fall zuverlässiger als Flattening; Flattening ist ein Notbehelf, wenn Delegation nicht machbar ist. Viele Teams, die für ein Flattening-Werkzeug zahlen, stellen fest, dass sie es nicht mehr brauchen, sobald sie entfernen und delegieren.
Der veraltete Include, der einen Eintrag allein scheitern lässt
Nicht jeder PermError kommt vom reinen Volumen. Die zweite Grenze — zwei Void-Lookups — fängt ein anderes und hinterlistigeres Scheitern: ein Include, der auf eine Domain zeigt, die keinen SPF-Eintrag mehr hat, sodass die Abfrage nichts zurückgibt. Ein Void-Lookup ist eine DNS-Abfrage, die leer oder mit einem NXDOMAIN zurückkommt, und die meisten Empfänger geben PermError zurück, sobald ein Eintrag über zwei davon hinausgeht. Der übliche Übeltäter ist ein einziger stillgelegter Dienst, dessen Include schlicht nie entfernt wurde.
Es gibt ein gut dokumentiertes Beispiel für genau dies. Trend Micro KB KA-0017579: after migrating off Hosted Email Security, customers who left include:spf.hes.trendmicro.com in their record hit a void-lookup PermError because the stale include resolved empty. Removing the one dead include fixed it. Die Lehre ist, dass ein Eintrag bequem unter zehn gezählten Lookups liegen und dennoch PermError geben kann, weil ein toter Include nicht nur verschwendetes Budget ist — er ist ein aktiver Void-Lookup. Wenn Sie von einem Maildienst wegmigrieren, gehört das Entfernen seines Includes zur Migration, nicht zu einer optionalen Aufräumung für später.
Deshalb ist die sauberste Lösung zugleich die erste auf der Liste. Entfernen ist unglamourös und es gibt kein Werkzeug, das man dafür verkaufen kann, aber jeden include-, a- und mx-Mechanismus durchzugehen und die zu löschen, die nicht mehr für Sie senden, beseitigt beide Fehlerarten auf einmal: es gewinnt Lookup-Budget zurück und räumt die Void-Lookups weg, die ein veralteter Include hinterlässt. Die meisten Einträge über dem Limit haben mindestens einen vergessenen Dienst in sich, und manche werden allein durch diesen Schritt behoben.
Warum das Lookup-Budget beim Wachsen ausgeht
Der strukturelle Grund hinter fast jedem Eintrag über dem Limit ist derselbe: SPF wurde entworfen, als die meisten Organisationen von ein oder zwei Stellen Mail sendeten, und der moderne Stack sendet von einem Dutzend. Jedes neue SaaS-Werkzeug, das in Ihrem Namen mailt — ein CRM, ein Helpdesk, eine Marketing-Plattform, ein Abrechnungssystem, ein Umfrage-Tool — will seinen eigenen Include, und die Includes verschachteln sich. Google Workspace alone consumes 3–4 lookups; a few more services and you hit the cap. Das Budget, das bei drei Versendern großzügig wirkte, ist weg, wenn Sie den siebten erreichen, und nichts im Ablauf warnt Sie beim Überschreiten der Linie.
Die Daten belegen, wie mechanisch das ist. Der häufigste Mechanismus in SPF-Einträgen ist der Include, und es ist genau der, der Lookups kostet und sich unvorhersehbar verschachtelt, weil der eigene Eintrag des Anbieters wachsen kann, ohne es Ihnen zu sagen. AutoSPF (Apr 2026) attributed 41% of SPF failures across a sample of fast-growing domains to exceeding the 10-lookup limit. Das Muster ist konsistent: je mehr Drittanbieter-Dienste eine Organisation einführt, desto schneller verbraucht sie ihr Lookup-Budget, und die Teams, die das Limit erreichen, sind meist die, die am schnellsten wachsen und am aggressivsten Werkzeuge hinzufügen.
Diese Einordnung weist direkt auf die dauerhafte Lösung. Wenn das Problem ist, dass Includes sich ansammeln und über Ihre Sichtbarkeit hinaus verschachteln, ist die Antwort nicht, Ihre Sende-Infrastruktur einzufrieren oder eine Momentaufnahme von IPs fest zu verdrahten, die abdriften wird — es ist, all diese Komplexität hinter einen einzigen delegierten Eintrag zu legen, den Sie kontrollieren, sodass die Root bei einem Lookup bleibt, egal wie viele Dienste dahinter sitzen. Wachstum hört auf, ein Countdown zum PermError zu sein, und wird zu einer Bearbeitung an einer gepflegten Stelle.
PermError ist nicht dasselbe wie ein SPF-Fail
Es lohnt, beim Fehler präzise zu sein, weil die beiden Ergebnisse völlig verschiedene Antworten verlangen. PermError is not the same as an SPF fail. Fail means the record was evaluated and the IP did not match; PermError means the record itself is broken (too many lookups, a syntax error, multiple records, or unresolvable/circular includes) and could not be evaluated at all. Ein Fail ist ein normales, gesundes Ergebnis — es ist SPF bei der Arbeit, das dem Empfänger sagt, dass eine bestimmte IP nicht auf Ihrer Liste stand. Ein PermError ist der Eintrag selbst, der unlesbar ist, was bedeutet, dass SPF dem Empfänger für keine Ihrer Mail eine brauchbare Antwort gibt.
Der Folgeeffekt reicht bis zu DMARC. DMARC interprets an SPF PermError as a fail, so if SPF is your only alignment path, a PermError quietly weakens DMARC too. Ein Team, das DMARC sorgfältig zur Durchsetzung bewegt hat, kann feststellen, dass ein einziger Eintrag über dem Limit ihm still den Boden entzieht, weil die Ausrichtung, auf die es zählte, nun für jede Nachricht zu PermError auflöst. Die Lookup-Zahl zu beheben ist daher nicht nur eine SPF-Reparatur; oft ist es das fehlende Stück, das eine DMARC-Richtlinie tatsächlich halten lässt.
Es gibt noch eine Fehlkonfiguration, die Sie ausschließen sollten, während Sie im Eintrag sind, weil sie
denselben PermError auf anderem Weg erzeugt. RFC 7208 requires exactly one SPF (v=spf1) TXT record per domain. Two records cause PermError for all mail, regardless of lookup count — a very common misconfiguration. Wenn Sie Fehler suchen und nicht
wissen, ob die Lookups oder ein doppelter Eintrag schuld sind, zählen Sie zuerst die Lookups; liegt die
Zahl bequem unter zehn und Sie sehen weiterhin PermError, suchen Sie nach diesem zweiten verirrten
v=spf1-TXT-Eintrag.
Die ehrliche Lösung
Flattening gegen Delegation, klar gesagt
Beide senken die Lookup-Zahl. Nur eine bleibt behoben.
Die anbieterdominierten Suchergebnisse zu diesem Thema bewerben Flattening stark, oft als kostenpflichtigen
Dienst, weil es die Lösung ist, die ein Werkzeug braucht. Wir sagen das weniger Profitable: die meisten
Domains brauchen kein Flattening-Abo. Entfernen Sie die Includes, die Sie nicht mehr nutzen, werfen Sie
ptr hinaus, wandeln Sie Ihre eigenen statischen Server in ip4 um, und haben Sie
noch echte Komplexität, delegieren Sie sie an eine Subdomain. Greifen Sie nur zu Flattening, wenn
Delegation wirklich keine Option ist, und richten Sie dann die Automatisierung ein, die es vor dem
stillen Verrotten bewahrt.
Wo wir stehen
Wir hosten Versand-Infrastruktur, also sehen wir ständig Einträge über dem Limit — sie sind, in unserer Erfahrung und in den veröffentlichten Daten, der häufigste einzelne SPF-Fehler. Der ehrliche Rat kostet uns ein Produkt, das wir sonst verkaufen könnten: die meisten Teams, die mit einem PermError ankommen, brauchen keinen Flattening-Dienst, sie brauchen einen Nachmittag des Entfernens und eine Subdomain-Delegation, nach der der Eintrag von allein behoben bleibt. Trend Micro KB KA-0017579: after migrating off Hosted Email Security, customers who left include:spf.hes.trendmicro.com in their record hit a void-lookup PermError because the stale include resolved empty. Removing the one dead include fixed it.
Führen Sie Mail mit uns, ist das Halten Ihres SPF innerhalb des Limits Teil der Einrichtung, und wir
gestalten die Delegation so, dass sie statisch bleibt, während Sie Versender hinzufügen und entfernen.
Hosten Sie selbst oder senden über einen ESP, gilt dieselbe Abfolge, egal, wer die Server betreibt:
bestätigen Sie den PermError, entfernen Sie Ungenutztes, werfen Sie ptr hinaus, wandeln Sie
statische Versender in direkte IPs um und delegieren Sie den Rest. Zählen Sie vor dem Hinzufügen, und das
Limit hört auf, eine Falle zu sein.
Fragen
Klar beantwortet
Die Fragen, die Teams stellen, wenn SPF ohne offensichtlichen Grund zu scheitern beginnt.
Was ist das SPF-10-Lookup-Limit genau?
Die SPF-Auswertung ist auf zehn DNS-abfragende Mechanismus-Lookups je Prüfung begrenzt, plus eine separate Obergrenze von zwei Void-Lookups, definiert in RFC 7208 §4.6.4. Mechanismen, die einen Namen auflösen — include, a, mx, ptr, exists und redirect — kosten je mindestens einen Lookup, und verschachtelte Includes zählen gegen dasselbe Budget. Literale Mechanismen (ip4, ip6, all) kosten nichts. Das Limit besteht aus Sicherheits- und Leistungsgründen: ohne es könnte ein bösartiger Eintrag Hunderte DNS-Abfragen auslösen und Empfänger zu einem Denial-of-Service-Vektor machen.
Was passiert tatsächlich, wenn ich es überschreite?
Ihr Eintrag gibt PermError zurück, und SPF scheitert für jede Nachricht, die Sie senden — nicht nur die Mail des zusätzlichen Dienstes, alle. Das Schlimmste ist, dass es still geschieht: auf Ihrer Seite gibt es keinen Bounce, also ist der einzige Hinweis verschwindende Mail und DMARC-Berichte, die permerror zeigen. Ein Eintrag, der mit drei Versendern gut lief, bricht an dem Tag, an dem Sie den sechsten hinzufügen, und die Zustellbarkeit kann wochenlang abrutschen, bevor jemand es mit der SPF-Änderung verknüpft.
Ist PermError dasselbe wie ein SPF-Fail?
Nein, und die Unterscheidung zählt. Ein SPF-Fail bedeutet, dass der Eintrag korrekt ausgewertet wurde und die sendende IP schlicht nicht autorisiert war. Ein PermError bedeutet, dass der Eintrag selbst überhaupt nicht ausgewertet werden konnte — zu viele Lookups, ein Syntaxfehler, mehr als ein SPF-Eintrag, oder ein nicht auflösbarer oder zirkulärer Include. Da DMARC einen PermError als Fail behandelt, untergräbt ein kaputter Eintrag auch still die DMARC-Ausrichtung, wenn SPF der Pfad ist, auf den Sie sich stützen.
Soll ich ein SPF-Flattening-Werkzeug nutzen?
Meist nicht als ersten Schritt, und oft gar nicht. Flattening ersetzt Includes durch ihre aufgelösten IPs, was die Lookup-Zahl tatsächlich senkt, aber diese IPs veralten in dem Moment, in dem ein Anbieter seine Sende-Infrastruktur ändert — und große Anbieter ändern ihre Bereiche regelmäßig. Ein geflätteter Eintrag braucht daher automatisiertes Neu-Flätten und Überwachung, sonst bricht er still. Die meisten Teams, die ungenutzte Includes entfernen und an eine Subdomain delegieren, stellen fest, dass sie das erwogene kostenpflichtige Werkzeug nicht mehr brauchen.
Warum ist Subdomain-Delegation besser als Flattening?
Weil sie einmal eingerichtet statisch ist, ohne Abhängigkeit von einem Drittanbieter-Werkzeug, das IPs neu auflöst. Sie zeigen Ihren Root-Eintrag auf eine delegierte _spf-Subdomain, die Root bleibt bei einem einzigen Lookup, und der delegierte Eintrag trägt die echte Komplexität — nutzt aber weiterhin gewöhnliche Includes, sodass Anbieter ihre eigenen IPs weiter aktualisieren können. Flattening behebt das Symptom (die Lookup-Zahl) und übernimmt dabei die zugrunde liegende Fragilität fest verdrahteter IPs; Delegation behebt die Struktur und lässt die Anbieter ihre eigenen Bereiche verwalten.
Kann ich einfach zwei SPF-Einträge haben, damit alles passt?
Nein — das macht es schlimmer. RFC 7208 verlangt genau einen v=spf1-TXT-Eintrag je Domain, und das Veröffentlichen von zweien verursacht einen PermError für Ihre gesamte Mail, egal wie viele Lookups jeder enthält. Es ist eine der häufigsten SPF-Fehlkonfigurationen. Führen Sie jeden autorisierten Versender in einem einzigen Eintrag zusammen, und ist dieser Eintrag zu lang für eine DNS-Zeichenkette, sollte Ihr DNS-Anbieter ihn in mehrere Zeichenketten innerhalb desselben Eintrags aufteilen — was sich von mehreren Einträgen unterscheidet.
SPF scheitert ohne offensichtlichen Grund?
Nennen Sie uns Ihre Sende-Domain, und wir zählen Ihre Lookups, finden den PermError und gestalten eine Delegation, die unter dem Limit bleibt, während Sie wachsen — ohne Flattening-Abo.