spf-too-many-dns-lookups

Es ist einer der frustrierendsten SPF-Fehler, weil er lautlos zuschlägt: Dein Eintrag ist syntaktisch korrekt, deine Server sind die richtigen, und trotzdem scheitert SPF. Die Ursache ist fast immer dieselbe: Du hast das Limit von zehn DNS-Auflösungen überschritten. Darüber hinaus geben die empfangenden Server einen PermError zurück, und dein 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 du das Problem diagnostizierst, und vor allem, wie du wieder unter die Grenze von zehn kommst, ohne deine Zustellbarkeit zu zerstören.

Was der Fehler wirklich sagt

Wenn ein Server eine Nachricht empfängt, wertet er deinen SPF-Eintrag 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. Erreichst du 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 deine Nachricht an DMARC — und je nach deiner Richtlinie landet sie im Spam oder wird abgewiesen. Du kannst also völlig legitime Mails abgewiesen bekommen, 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 dich 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 du include: durch ip4:/ip6: ersetzt, desto leichter wird deine Zählung. Und achte auf die kaskadierenden include: Ein include:_spf.fournisseur.com kann selbst drei oder vier include enthalten, die alle in deine zehn zählen. So überschreitet man das Limit, ohne es zu merken — ein paar gefräßige Dienstleister genügen.

Diagnostizieren: wie viele Auflösungen verbrauchst du?

Bevor du korrigierst, miss. Du kannst nicht reparieren, was du nicht siehst. Unser kostenloser DMARC-Analyzer wertet dein SPF aus, rollt die kaskadierenden include ab und sagt dir, wo du in der Zählung stehst. Das Ziel ist, den Baum deines Eintrags zu visualisieren: jedes include, das du veröffentlichst, 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 deines Budgets verbrauchen.

Fünf Wege, wieder unter die Grenze zu kommen

Hier die Korrekturen, von der einfachsten zur strukturierendsten:

1. Entferne die unnötigen include. 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. Räum auf: Behalte nur die Quellen, die wirklich senden.
2. Ersetze include durch ip4:/ip6:. Wenn ein Dienstleister stabile IP-Bereiche veröffentlicht, kannst du sie fest eintragen statt seines include. Du verwandelst DNS-Auflösungen in Literale, die nicht zählen. Vorsicht jedoch: Ändert der Dienstleister seine IPs, musst du nachziehen.
3. Flatte deinen Eintrag (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.
4. Trenne deine Versände nach Subdomain. Statt alles auf deine Root-Domain zu stapeln, lass das Marketing von mail.deine-domain.de und die Transaktionsmails von notif.deine-domain.de ausgehen. Jede Subdomain hat ihr eigenes Budget von zehn Auflösungen, unabhängig. Das ist oft die dauerhafteste Lösung für große Versender.
5. Vermeide den ptr-Mechanismus. Langsam, unzuverlässig, und von der RFC selbst abgeraten. Wenn er in deinem Eintrag herumliegt, entferne ihn.

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 deinen 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 dein Eintrag entlastet ist, zwei Kontrollen:

1. Lass ihn erneut durch den Analyzer laufen, um zu bestätigen, dass die Zählung wieder unter zehn liegt und es keinen PermError mehr gibt. Siehe auch wie du deinen Eintrag prüfst.
2. Überwache deine Aggregatberichte: 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: Verwechsle diesen Überschreitungs-PermError nicht mit anderen permanenten Fehlern (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.

Addiere: 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 bei deinem Dienstleister ändern können — mit dem Risiko, deine Zustellbarkeit zu zerstören, wenn du nicht nachziehst. 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 du unter der Grenze warst. 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:

• Prüfe die Kosten, bevor du einen Dienstleister hinzufügst. Jedes neue include kann mehrere verbergen; schau dir seinen Baum an, bevor du es veröffentlichst, nicht danach.
• Bevorzuge Subdomains von Anfang an für volumenstarke Ströme (Marketing, Benachrichtigungen). Du gönnst dir ein Budget von zehn Auflösungen pro Strom und musst nie alles im Notfall entwirren.
• Auditiere dein SPF regelmäßig. 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. Behandle ihn als zu pflegendes Gut, nicht als 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 deine Rechnungen plötzlich im Spam landen.

Lass Thomas dein SPF überwachen

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

Analysiere deine Domain kostenlos → oder erstelle ein Konto, um dein SPF unter Kontrolle zu halten.