SPF-Fehler „too many DNS lookups": das Limit von 10 verstehen und beheben

Von Thomas · virtueller CISO · 03. Juli 2026

Es ist einer der frustrierendsten SPF-Fehler, weil er lautlos zuschlägt: Der Eintrag ist syntaktisch korrekt, die Server sind die richtigen, und trotzdem scheitert SPF. Die Ursache ist fast immer dieselbe: Das Limit von zehn DNS-Auflösungen ist überschritten. Darüber hinaus geben die empfangenden Server einen PermError zurück, und das SPF wird nicht mehr ausgewertet — als existierte es nicht. Dieser Leitfaden erklärt, woher dieses Limit kommt, was in der Zählung wirklich zählt, wie sich das Problem diagnostizieren lässt, und vor allem, wie man wieder unter die Grenze von zehn kommt, ohne die Zustellbarkeit zu zerstören.

Was der Fehler wirklich sagt

Wenn ein Server eine Nachricht empfängt, wertet er den SPF-Eintrag der Domain aus, um zu prüfen, ob die sendende IP autorisiert ist. Diese Auswertung kann DNS-Anfragen auslösen — zum Beispiel, um ein include: aufzulösen. RFC 7208 setzt eine strenge Obergrenze: nicht mehr als zehn DNS-Auflösungen während der gesamten Auswertung. Bei elf ist das Ergebnis weder pass noch fail, sondern PermError (permanenter Fehler).

Die Falle ist die Wirkung dieses Zustands. Für DMARC ist ein SPF im PermError nicht ausgerichtet und besteht nicht. Wenn DKIM den Schlag nicht abfängt, scheitert die Nachricht an DMARC — und je nach veröffentlichter Richtlinie landet sie im Spam oder wird abgewiesen. Völlig legitime Mails können also abgewiesen werden, wegen eines SPF-Eintrags, der zu gefräßig geworden ist. Genau deshalb verdient dieser Fehler eine schnelle Korrektur, kein Schulterzucken.

Warum es dieses Limit gibt

Es ist nicht willkürlich. Ohne Obergrenze könnte ein bösartiger (oder einfach schlecht gemachter) SPF-Eintrag bei jeder empfangenen Nachricht eine Kaskade von DNS-Anfragen auslösen — ein idealer Verstärkungs-Hebel für einen Denial-of-Service gegen die empfangenden Server. Das Limit von zehn Auflösungen begrenzt diese Kosten und schützt die weltweite Mail-Infrastruktur. Kurz: Die Einschränkung, die im Alltag nervt, ist auch das, was verhindert, dass SPF zur Waffe wird.

Was zählt (und was nicht) in den zehn

Das ist der Kern der Sache und die Quelle der meisten Missverständnisse. Es zählen in das Limit die Mechanismen, die eine DNS-Auflösung erfordern:

include: — jedes include kostet mindestens eine Auflösung, und oft mehr, wenn es weitere kaskadenartig enthält.
a und mx — lösen A/MX-Einträge auf.
ptr — Reverse-Auflösung (zu vermeiden, siehe unten).
exists: und der Modifikator redirect= — zählen ebenfalls.

Es zählen nicht: die Mechanismen, die keine Anfrage erfordern:

ip4: und ip6: — literale Adressen, null Auflösung.
all — der abschließende Mechanismus (-all, ~all).

Die Konsequenz ist glasklar: Je mehr include: durch ip4:/ip6: ersetzt werden, desto leichter wird die Zählung. Und Vorsicht bei den kaskadierenden include: Ein include:_spf.fournisseur.com kann selbst drei oder vier include enthalten, die alle in dieselben zehn zählen. So überschreitet man das Limit, ohne es zu merken — ein paar gefräßige Dienstleister genügen.

Ein zweites, weniger bekanntes Limit: Void Lookups

Neben der Obergrenze von zehn Auflösungen kennt RFC 7208 noch eine weitere Schutzschwelle, die seltener zuschlägt, aber genauso hart: das Limit für Void Lookups. Ein Void Lookup ist eine DNS-Anfrage, die keine verwertbare Antwort liefert — der Name existiert nicht, oder er existiert ohne den erwarteten Eintrag. Die RFC empfiehlt, davon höchstens zwei pro Auswertung zu tolerieren; darüber hinaus ist das Ergebnis ebenfalls ein PermError. In der Praxis bestraft das veraltete Einträge: ein abgeschalteter Dienstleister, dessen Hostname nicht mehr auflöst, ein Tippfehler im Ziel eines include, eine gelöschte Subdomain, die im Eintrag zurückblieb. Ein SPF kann also scheitern, obwohl die Zählung bequem unter zehn Auflösungen liegt — ein Grund mehr, warum das regelmäßige Aufräumen genauso zählt wie die Zählung selbst.

Diagnostizieren: wie viele Auflösungen verbraucht der Eintrag?

Vor der Korrektur steht die Messung. Reparieren lässt sich nicht, was man nicht sieht. Unser kostenloser DMARC-Analyzer wertet das SPF aus, rollt die kaskadierenden include ab und zeigt, wo die Zählung steht. Das Ziel ist, den Baum des Eintrags zu visualisieren: jedes veröffentlichte include und alles, was es dahinter nach sich zieht. Sobald dieser Baum vor Augen steht, springen die Schuldigen ins Auge — typischerweise ein oder zwei große Dienstleister, die allein die Hälfte des Budgets verbrauchen.

Fünf Wege, wieder unter die Grenze zu kommen

Hier die Korrekturen, von der einfachsten zur strukturierendsten:

Die unnötigen include entfernen. Das Offensichtlichste, und das am häufigsten Vergessene. Dieses Tool, das das Marketing vor zwei Jahren getestet hat und nicht mehr nutzt? Sein include liegt noch herum. Aufräumen heißt hier: nur die Quellen behalten, die wirklich senden.
include durch ip4:/ip6: ersetzen. Wenn ein Dienstleister stabile IP-Bereiche veröffentlicht, lassen sie sich fest eintragen statt seines include. Damit werden DNS-Auflösungen zu Literalen, die nicht zählen. Vorsicht jedoch: Ändert der Dienstleister seine IPs, muss der Eintrag nachziehen.
Den Eintrag flatten (SPF Flattening). Das Flattening besteht darin, die include ein für alle Mal aufzulösen und sie durch die entsprechenden ip4:/ip6: zu ersetzen. Mächtig, aber mit Methode zu handhaben (die IPs der Dienstleister ändern sich). Wir widmen dem einen eigenen Leitfaden: was SPF Flattening ist.
Die Versände nach Subdomain trennen. Statt alles auf der Root-Domain zu stapeln, geht das Marketing von mail.beispiel.de und gehen die Transaktionsmails von notif.beispiel.de aus. Jede Subdomain hat ihr eigenes Budget von zehn Auflösungen, unabhängig. Das ist oft die dauerhafteste Lösung für große Versender.
Den ptr-Mechanismus vermeiden. Langsam, unzuverlässig, und von der RFC selbst abgeraten. Wenn er im Eintrag herumliegt, gehört er entfernt.

Und ein fortgeschrittener Weg: exists-Makros

Die fünf Korrekturen oben reduzieren die Zählung. Es gibt einen sechsten, technischeren Weg, der sie umgeht: Der exists-Mechanismus in Kombination mit SPF-Makros autorisiert eine unbegrenzte Anzahl von IPs in einer einzigen Auflösung, wobei die Entscheidung an eine selbst kontrollierte DNS-Zone delegiert wird. Diese Technik ist großen Versendern mit dynamischem Bestand vorbehalten und bringt eigene Kompromisse mit sich; wir erklären sie ausführlich in SPF-Makros und der exists-Mechanismus.

Der Fehler, den man beim Korrigieren nicht machen darf

Beim Versuch, die Zählung zu reduzieren, setzen manche Teams ihr SPF auf ~all (Softfail) „um Ruhe zu haben", oder löschen es gar. Schlechte Idee. Die abschließende Qualifizierung zu schwächen (-all → ~all, oder schlimmer +all) hat keinerlei Wirkung auf die Auflösungszählung — es korrigiert nichts — aber es schwächt den Schutz. Der richtige Reflex ist, die Anzahl der Auflösungen zu reduzieren, nicht die Deckung zu senken. Zum Unterschied zwischen -all und ~all siehe die Mechanismen -all und ~all.

Prüfen, dass es behoben ist

Sobald der Eintrag entlastet ist, zwei Kontrollen:

Ihn erneut durch den kostenlosen SPF-Prüfer laufen lassen, um zu bestätigen, dass die Zählung wieder unter zehn liegt und es keinen PermError mehr gibt. Siehe auch wie sich ein Eintrag prüfen lässt.
Die Aggregatberichte überwachen: Eine Quelle, die durch Überschreitung an SPF scheiterte, sollte nun bestehen (und sich ausrichten). Das ist der endgültige Beweis, dass die Korrektur gegriffen hat.

Ein verwandtes Wort: Dieser Überschreitungs-PermError ist nicht mit anderen permanenten Fehlern zu verwechseln (ungültige Syntax, doppelter Eintrag). Die Details der Fälle stehen in der PermError, was das bedeutet.

Ein konkretes Beispiel: Anatomie einer Überschreitung

Nehmen wir einen realistischen Eintrag, den eines KMU, das seine Tools über die Jahre gestapelt hat:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com
  include:_spf.salesforce.com include:servers.mcsv.net include:spf.protection.outlook.com -all

Auf den ersten Blick sechs include — man könnte an sechs Auflösungen glauben. Die Realität ist schwerer, denn jedes include faltet sich auf:

include:_spf.google.com → 1, aber es enthält selbst mehrere include (_netblocks, _netblocks2, _netblocks3) → ~4 insgesamt.
include:spf.protection.outlook.com → 1, plus seine eigenen Sub-include → ~2-3.
include:_spf.salesforce.com, sendgrid.net, mailchimp.com, servers.mcsv.net → 1 bis 2 je.

Zusammengezählt: Man überschreitet leicht zwölf oder dreizehn Auflösungen. Ergebnis: PermError, und die gesamte Post dieses KMU — einschließlich seiner echten Rechnungen über Salesforce — riskiert die Quarantäne.

Die Korrektur besteht in zwei Handgriffen. Zunächst sind servers.mcsv.net und mailchimp.com Doppler (derselbe Anbieter): Man entfernt einen. Dann verschiebt man das Marketing (Mailchimp) auf eine Subdomain news.pme.fr mit eigenem SPF. Die Root-Domain fällt auf sechs oder sieben Auflösungen zurück, unter die Grenze, und jeder Strom behält sein Budget. Keine legitime Mail verloren, und kein PermError mehr.

Häufige Fragen

Betrifft das Limit von zehn auch DKIM? Nein. DKIM hat diese Einschränkung nicht — es ist eine Besonderheit von SPF, verbunden mit der Art, wie es Autorisierungen im DNS auflöst. Übrigens ist in realen Deployments die DKIM-Ausrichtung oft robuster als SPF, gerade weil sie dieser Art Obergrenze entgeht (siehe wie die drei Protokolle zusammenarbeiten).

Wie viele Auflösungen „kostet" ein include? Mindestens eine, um es aufzulösen. Aber wenn es selbst include, a oder mx enthält, kommen diese hinzu. Ein einziges Dienstleister-include kann drei oder vier allein verbrauchen.

Ist das Flattening die beste Lösung? Nicht immer. Es regelt die Zählung, aber es friert IPs ein, die sich beim Dienstleister ändern können — mit dem Risiko, die Zustellbarkeit zu zerstören, wenn niemand nachzieht. Für viele Organisationen genügt es, die unnötigen include aufzuräumen und nach Subdomain zu trennen, ohne die Wartungsschuld des Flattening.

Warum „funktionierte" mein Eintrag vorher? Weil er unter der Grenze lag. Jeder neu hinzugefügte Dienstleister drückt die Zählung nach oben; eines Tages lässt ein include zu viel es in den PermError kippen. Es ist eine Schwelle, keine schrittweise Verschlechterung.

Vorbeugen statt heilen

Der PermError kommt nie überraschend, wenn man die Zählung im Auge behält. Drei Gewohnheiten vermeiden ihn dauerhaft:

Die Kosten prüfen, bevor ein Dienstleister hinzukommt. Jedes neue include kann mehrere verbergen; sein Baum gehört angeschaut, bevor es veröffentlicht wird, nicht danach.
Subdomains von Anfang an bevorzugen für volumenstarke Ströme (Marketing, Benachrichtigungen). Das ergibt ein Budget von zehn Auflösungen pro Strom und erspart jedes Entwirren im Notfall.
Das SPF regelmäßig auditieren. Die Versandparks driften: Ein Tool kommt, ein anderes geht, ohne dass man sein include entfernt. Eine vierteljährliche Kontrolle genügt, um den Eintrag sauber zu halten.

Die goldene Regel: Ein SPF-Eintrag ist lebendig. Er ist ein zu pflegendes Gut, nicht eine Zeile, die man ein für alle Mal veröffentlicht — die wenigen Minuten pro Quartal, die man hier verbringt, kosten weit weniger als ein Tag Suche, warum die Rechnungen plötzlich im Spam landen.

Thomas überwacht das SPF

Die SPF-Zählung driftet mit jedem neuen Tool, das an die Domain angeschlossen wird. Thomas, der virtuelle CISO, rollt den Eintrag ab, erkennt die gefräßigen und unnötigen include, schlägt die sicherste Korrektur für den behandelten Fall vor (Aufräumen, Subdomains, oder kontrolliertes Flattening) und warnt, bevor das Limit überschritten wird — nicht nachdem die Mails anfangen zu fallen.

Eine Domain kostenlos analysieren oder ein Konto erstellen, um das SPF unter Kontrolle zu halten.