SPF-Fehler too many DNS lookups (PermError) beheben: Das 10-Lookup-Limit verständlich erklärt
Über Jahre galt ein SPF-PermError als kosmetisches Problem. Der Eintrag überschritt eine technische Grenze, die meisten Empfänger zuckten mit den Schultern und stellten trotzdem zu. Das ändert sich gerade grundlegend. Mit der zunehmenden Verbreitung von DMARC im Enforcement-Modus zählt ein SPF-PermError nicht mehr als harmloses Nebenrauschen, sondern wirkt wie ein SPF-Fail. Steht die DMARC-Richtlinie auf reject und fehlt ein gültiges DKIM, landet legitime Geschäftspost im Spam oder wird ganz abgelehnt.
Dieser Guide erklärt verständlich, was hinter der Fehlermeldung too many DNS lookups steckt, wie das 10-Lookup-Limit zustande kommt, wie Sie die include-Kette zählen und diagnostizieren und mit welchen Lösungswegen Sie den Fehler dauerhaft beheben, von der Aufräumarbeit bis zum SPF-Flattening.
Warum ein PermError heute zu Zustellverlust führt
TL;DR: Ein SPF-Eintrag darf bei der Auswertung höchstens zehn DNS-Lookups verursachen. Jeder Mechanismus mit DNS-Abfrage, also
include,a,mx,ptrundexists, zählt mit, und geschachtelte includes summieren sich. Wird das Limit überschritten, ergibt SPF einen PermError. Unter DMARC im Modusquarantineoderrejectzählt dieser PermError wie ein SPF-Fail und kann ohne gültiges DKIM zur Ablehnung führen. Behoben wird er durch Aufräumen, Konsolidieren und im Bedarfsfall durch automatisch gepflegtes SPF-Flattening.
SPF, das Sender Policy Framework, legt fest, welche Mailserver im Namen einer Domäne senden dürfen. Die empfangende Seite löst dazu den SPF-Eintrag der Absenderdomäne auf und prüft, ob die sendende IP-Adresse abgedeckt ist. Damit diese Auflösung nicht ausufert, begrenzt RFC 7208 die Zahl der DNS-Lookups je Auswertung auf zehn. Wird diese Grenze gerissen, lautet das Ergebnis PermError, also ein dauerhafter, unbehebbarer Fehler in der Auswertung.
Isoliert betrachtet bleibt ein PermError oft folgenlos, weil viele Server SPF allein nicht hart durchsetzen. Im Zusammenspiel mit DMARC sieht das anders aus. DMARC verlangt, dass entweder SPF oder DKIM bestehen und zur sichtbaren Absenderadresse ausgerichtet sind. Ein PermError gilt dabei als gescheiterter SPF. Fehlt zugleich ein gültiges, ausgerichtetes DKIM, scheitert die DMARC-Prüfung vollständig. Bei einer Richtlinie von p=reject bedeutet das die Ablehnung der Nachricht. Was früher unbemerkt blieb, wird unter Enforcement zum direkten Zustellrisiko.
Wie das 10-Lookup-Limit zustande kommt
Das Tückische am Limit ist, dass es selten ein einzelner Eintrag sprengt. Es ist die Summe vieler Dienste, die über die Zeit in den SPF-Eintrag wandern. Ein typischer mittelständischer Eintrag bindet den Mailprovider, einen oder mehrere Newsletter-Dienste, ein CRM, ein Ticketing-System und vielleicht noch einen Rechnungsversand ein. Jeder dieser Dienste wird über ein include eingebunden, und jedes include löst mindestens einen DNS-Lookup aus.
Entscheidend ist, dass includes geschachtelt sein können. Binden Sie den include eines Anbieters ein, bringt dieser oft selbst weitere includes mit, die wiederum eigene Lookups verursachen. Aus einem include werden so schnell drei oder vier gezählte Lookups. Diese Mechanismen lösen jeweils eine DNS-Abfrage aus:
| Mechanismus | Löst Lookup aus | Hinweis |
|---|---|---|
include | Ja | Häufigste Ursache, summiert sich durch Schachtelung |
a | Ja | Prüft A- oder AAAA-Eintrag der genannten Domäne |
mx | Ja | Kann mehrere Hosts auflösen, bleibt aber ein gezählter Lookup |
ptr | Ja | Veraltet und unzuverlässig, sollte vermieden werden |
exists | Ja | Selten genutzt, kostet ebenfalls einen Lookup |
ip4 und ip6 | Nein | Direkte IP-Angabe, verbraucht keinen Lookup |
Rechnen Sie eine realistische Konstellation durch: Mailprovider zwei Lookups, ein Marketing-Newsletter zwei, ein zweiter Versanddienst zwei, das CRM zwei, das Ticketing-System zwei. Das sind bereits zehn Lookups, bevor ein einziger eigener Mailserver per a oder mx ergänzt wurde. Die Grenze ist also schneller erreicht, als die überschaubare Liste der eigenen includes vermuten lässt.
PermError diagnostizieren und die Lookup-Kette zählen
Bevor Sie etwas ändern, müssen Sie wissen, wo die Lookups versteckt sind. Das bloße Lesen des eigenen SPF-Eintrags genügt nicht, weil die teuren Lookups in den geschachtelten includes der Anbieter stecken, die der Eintrag nicht sichtbar macht.
Schritt 1: Den aktuellen Eintrag und die Zählung sichtbar machen
Verwenden Sie ein SPF-Auswertungswerkzeug, das den Eintrag rekursiv auflöst und die Lookups Mechanismus für Mechanismus aufaddiert. Solche Werkzeuge zeigen die vollständige Kette, also auch die includes, die ein Anbieter intern nachzieht. So sehen Sie, welcher Dienst tatsächlich wie viele Lookups beisteuert. Mit dem kostenlosen Conbool E-Mail-Check prüfen Sie zudem, wie SPF im Zusammenspiel mit DKIM und DMARC ausgewertet wird.
Schritt 2: Die Verursacher den Diensten zuordnen
Notieren Sie zu jedem include den dahinterliegenden Dienst und dessen Lookup-Kosten. Diese Zuordnung ist der eigentliche Erkenntnisgewinn. Oft finden sich hier includes von Diensten, die längst abgelöst wurden, oder doppelte Einbindungen desselben Anbieters über verschiedene Subdomänen. Genau diese Altlasten sind die einfachsten und risikoärmsten Kürzungskandidaten.
Schritt 3: Den Bezug zu DMARC herstellen
Prüfen Sie parallel, ob für die Domäne eine DMARC-Richtlinie veröffentlicht ist und in welchem Modus sie steht. Bei p=none ist der PermError ein Warnsignal ohne unmittelbare Folge. Bei quarantine oder reject ist er ein aktives Zustellproblem, das vorrangig zu beheben ist.
Lösungswege: aufräumen, konsolidieren, Flattening mit Vorsicht
Die Behebung folgt einer klaren Reihenfolge, von der risikoärmsten zur aufwendigsten Maßnahme. Beginnen Sie immer oben.
Aufräumen. Entfernen Sie includes von Diensten, die nicht mehr senden. Jeder gestrichene include eines Anbieters spart dessen gesamte Lookup-Kette, oft also mehr als einen Lookup. Streichen Sie ebenso veraltete ptr-Mechanismen, die ohnehin als unzuverlässig gelten. Häufig genügt dieser erste Schritt bereits, um unter das Limit zu kommen.
Konsolidieren. Nutzen Sie mehrere Produkte desselben Anbieters, lässt sich häufig ein einzelner, umfassender include verwenden statt mehrerer einzelner. Prüfen Sie zudem, ob breite a- oder mx-Mechanismen nötig sind. Versendet ein Dienst über feste, bekannte IP-Adressen, können Sie diese als ip4 oder ip6 direkt eintragen. Diese direkten Angaben verbrauchen keinen Lookup und sind damit ein wirksames Mittel, die Zählung zu senken.
SPF-Flattening, mit Vorsicht. Bleibt der Eintrag trotz Aufräumen und Konsolidieren über der Grenze, kommt Flattening infrage. Dabei werden die includes aufgelöst und durch die dahinterliegenden ip4- und ip6-Adressen ersetzt. Weil diese IP-Mechanismen keinen Lookup kosten, sinkt die Zahl zuverlässig unter zehn. Der Preis dafür ist ein statischer Eintrag: Ändert ein Anbieter seine Versand-IPs, wird der Eintrag still falsch und legitime Mail kann am SPF scheitern. Manuelles Flattening verlagert das Problem damit nur, von einem Lookup-Fehler zu einem Wartungsrisiko. Sinnvoll ist Flattening deshalb ausschließlich mit einer Lösung, die die IP-Bereiche der eingebundenen Dienste laufend überwacht und den Eintrag automatisch aktualisiert.
Der Bezug zu DMARC und wie Conbool die Quellen sichtbar macht
Ein SPF-PermError lässt sich technisch beheben, aber das eigentliche Ziel ist die saubere DMARC-Ausrichtung. SPF ist nur eine von zwei Säulen. Selbst ein fehlerfreier SPF-Eintrag nützt wenig, wenn ein Versanddienst nicht ausgerichtet signiert und die DMARC-Prüfung deshalb trotzdem scheitert. Deshalb gehört die SPF-Pflege immer in den größeren Kontext der E-Mail-Authentifizierung mit DMARC.
Der schwierigste Teil ist dabei nicht der Eintrag selbst, sondern die Frage, welche Dienste überhaupt im Namen Ihrer Domäne senden. Genau diese Sichtbarkeit liefern DMARC-Aggregatberichte. Sie zeigen, von welchen Quellen Mail mit Ihrer Domäne ausgeht und ob SPF und DKIM dort jeweils bestehen und ausgerichtet sind. Aus diesem Bild leitet sich ab, welcher include im SPF-Eintrag wirklich gebraucht wird und welcher Altlast ist. Wie Sie diese Berichte praktisch lesen, erklärt der Beitrag DMARC-Report XML auswerten.
Conbool wertet diese Berichte automatisch aus und macht die Versandquellen in einer verständlichen Oberfläche sichtbar, ohne XML von Hand zu lesen. Wer einen DMARC-Eintrag erst aufsetzt, findet eine geführte Anleitung unter DMARC-Record erstellen. Den eingehenden Schutz, der SPF, DKIM und DMARC bei der Annahme prüft, übernimmt das Conbool MailGuard-Gateway.
Häufig gestellte Fragen
Was bedeutet ein SPF-PermError?
Ein SPF-PermError ist ein dauerhafter Auswertungsfehler des SPF-Eintrags. Er entsteht, wenn der Eintrag fehlerhaft ist oder eine harte Grenze überschreitet, am häufigsten das Limit von zehn DNS-Lookups. Die empfangende Seite kann SPF dann nicht zu einem Pass auswerten und behandelt das Ergebnis als Fehler. Unter DMARC zählt dieser PermError nicht als neutral, sondern wirkt wie ein SPF-Fail und kann je nach Richtlinie zu Quarantäne oder Ablehnung führen.
Warum gibt es ein 10-DNS-Lookup-Limit bei SPF?
Das Limit ist in RFC 7208 festgelegt und schützt die DNS-Infrastruktur. Jeder Mechanismus, der eine DNS-Abfrage auslöst, also include, a, mx, ptr und exists, kostet einen Lookup. Geschachtelte includes summieren sich, weil jeder eingebundene Eintrag seine eigenen Lookups mitbringt. Ohne Obergrenze könnte ein einziger SPF-Eintrag eine Kettenreaktion vieler DNS-Anfragen auslösen. Deshalb begrenzt der Standard die Zahl der Lookups bei der Auswertung auf zehn.
Wie behebe ich den Fehler too many DNS lookups?
Zuerst zählen Sie mit einem SPF-Prüfwerkzeug die tatsächliche Zahl der Lookups und sehen, welche includes sie verursachen. Dann entfernen Sie includes von Diensten, die Sie nicht mehr nutzen, fassen Dienste eines Anbieters zusammen und ersetzen breite a- oder mx-Mechanismen durch konkrete ip4- und ip6-Einträge, die keinen Lookup kosten. Reicht das nicht, kommt SPF-Flattening infrage, bei dem includes durch ihre aufgelösten IP-Adressen ersetzt werden. Flattening sollte nur mit automatischer Pflege erfolgen, da sich die IPs der Anbieter ändern können.
Was ist SPF-Flattening und ist es sinnvoll?
SPF-Flattening bedeutet, dass die includes eines Eintrags aufgelöst und durch die dahinterliegenden ip4- und ip6-Adressen ersetzt werden. Weil ip4 und ip6 keinen DNS-Lookup auslösen, sinkt die Lookup-Zahl unter zehn. Sinnvoll ist Flattening, wenn sich die Lookups durch Aufräumen und Konsolidieren nicht ausreichend senken lassen. Es hat aber einen Haken: Ändert ein Dienst seine Versand-IPs, wird der statische Eintrag falsch und legitime Mail kann scheitern. Flattening sollte daher nur mit einer Lösung erfolgen, die die IPs automatisch überwacht und aktualisiert.
Führt ein SPF-PermError zu Zustellverlust?
Ja, das kann passieren. Solange SPF isoliert betrachtet wird, fällt ein PermError oft nicht weiter auf. Sobald DMARC im Spiel ist und auf quarantine oder reject steht, zählt der PermError wie ein SPF-Fail. Besteht zugleich kein gültiges DKIM, scheitert die DMARC-Ausrichtung insgesamt und die empfangende Seite kann die Nachricht in den Spam verschieben oder ablehnen. Mit der wachsenden Verbreitung von Enforcement wird ein bislang unbemerkter PermError so zu einem realen Risiko für die Zustellbarkeit.
Fazit
Der SPF-Fehler too many DNS lookups ist kein Schönheitsfehler mehr. Unter DMARC-Enforcement wird aus dem PermError ein SPF-Fail, der ohne gültiges DKIM zur Ablehnung legitimer Geschäftspost führen kann. Die gute Nachricht: Der Fehler ist gut beherrschbar. Wer die include-Kette sichtbar macht, ungenutzte Dienste streicht, Anbieter konsolidiert und feste IPs direkt einträgt, kommt meist schon unter das Limit. Flattening bleibt das letzte Mittel und gehört wegen der wechselnden Anbieter-IPs nur in automatisch gepflegte Hände.
Der nächste Schritt liegt bei Ihnen: Prüfen Sie Ihre Domäne mit dem kostenlosen Conbool E-Mail-Check und sehen Sie auf der Seite zur DMARC-E-Mail-Authentifizierung, wie Conbool Ihre Versandquellen sichtbar macht und die saubere Ausrichtung von SPF, DKIM und DMARC absichert.
Weiterführende Artikel:
