SPF PermError: Was das bedeutet und wie man ihn behebt

Ursache Nr. 1: zu viele DNS-Auflösungen

Das ist mit Abstand die häufigste Ursache. RFC 7208 begrenzt die Auswertung auf zehn DNS-Auflösungen. Jedes include, a, mx, ptr, exists und redirect verbraucht eine, und die include von Dienstleistern falten sich kaskadenartig auf. Über zehn hinaus ist es PermError. Das ist so verbreitet, dass wir dem einen eigenen Leitfaden widmen: das Limit von 10 DNS-Lookups. Die Korrektur läuft über das Aufräumen unnötiger include, die Trennung nach Subdomain, oder ein kontrolliertes Flattening.

Ursache Nr. 2: zu viele „Void Lookups"

Unauffälliger, aber sehr real. Ein Void Lookup ist eine DNS-Auflösung, die nichts zurückgibt (nicht existierende Domain oder leerer Eintrag). Die RFC begrenzt die Anzahl dieser leeren Auflösungen auf zwei. Darüber hinaus ist es ebenfalls ein PermError. Die typische Ursache: ein include, das auf eine gelöschte Dienstleister-Domain zeigt, oder ein Tippfehler in einem Domainnamen. Das Symptom ist heimtückisch, weil der Eintrag „korrekt aussieht" — man muss jeden Mechanismus abrollen, um die zu erkennen, die auf nichts auflösen.

Ursache Nr. 3: eine ungültige Syntax

Ein einfacher Tippfehler kann den ganzen Eintrag zerstören: ein schlecht formatiertes ip4:, ein include ohne Doppelpunkt, ein störendes Zeichen, zwei Mechanismen ohne Leerzeichen aneinandergeklebt. SPF ist streng: Wenn der Parser des Empfängers einen Mechanismus nicht interpretieren kann, gibt er PermError zurück, statt zu raten. Aufmerksames Nachlesen hilft — oder, sicherer, die Validierung der Syntax durch ein Werkzeug.

Ursache Nr. 4: ein doppelter SPF-Eintrag

Eine Domain darf nur einen einzigen v=spf1-Eintrag haben. Existieren zwei (einer von der IT gesetzt, ein anderer vom Marketing zum Beispiel), ist die Lage mehrdeutig, und viele Empfänger geben PermError zurück — oder ignorieren beide. Die Korrektur: die beiden zu einem einzigen Eintrag zusammenführen, ihre Mechanismen kombinieren und dabei prüfen, dass man nicht über zehn Auflösungen kommt.

Ursache Nr. 5: veraltete oder verbotene Mechanismen

Manche Mechanismen sind problematisch. Das ptr zum Beispiel wird von der RFC abgeraten: langsam, unzuverlässig, kann es zu einem PermError beitragen und sollte entfernt werden. Ebenso können exotische SPF-Makros oder falsch platzierte Modifikatoren den Eintrag nicht auswertbar machen. In der Regel beschränkt sich ein gesundes SPF auf include, ip4, ip6, a, mx (sparsam) und die abschließende Qualifizierung.

Wie sich ein PermError diagnostizieren lässt

Die gute Nachricht: Ein PermError ist deterministisch — er hat eine genaue Ursache, und es genügt, sie zu finden. Die Methode:

1. Den Eintrag abrufen (dig +short TXT beispiel.de) und bestätigen, dass es nur einen gibt.
2. Den Baum der include abrollen, um die tatsächlichen Auflösungen zu zählen und Void Lookups zu erkennen.
3. Die Syntax validieren, Mechanismus für Mechanismus.
4. Die Ursache identifizieren unter den fünf oben genannten.

Alles von Hand zu machen ist möglich, aber ein Analysewerkzeug geht viel schneller. Unser kostenloser DMARC-Analyzer rollt das SPF ab, zählt die Auflösungen, erkennt die Void Lookups und Syntaxfehler und sagt genau, warum die Domain im PermError ist. Der vollständige Prüfweg steht in wie sich ein Eintrag prüfen lässt.

PermError vs. SoftFail vs. Fail: in den Reports nicht verwechseln

Bei der Lektüre der Aggregatberichte lohnt sich die genaue Unterscheidung. Ein SPF-fail (das aus einem PermError oder einer nicht autorisierten IP stammen kann) hat nicht dieselbe Ursache wie ein softfail. Und vor allem: Das SPF-Feld der Reports spiegelt die Ausrichtung wider, nicht nur das rohe Ergebnis. Eine Quelle im PermError erscheint als Fehler; sobald der Eintrag repariert ist, sollte sie wieder auf Grün wechseln. Das ist der endgültige Beweis, dass die Korrektur gegriffen hat.

Ein PermError zerlegt: ein realer Fall

Nehmen wir eine Domain, die gerade ohne Vorwarnung in den PermError gekippt ist. Das Team schwört, „nichts geändert" zu haben. Wir rollen ab. Der Eintrag:

v=spf1 include:_spf.google.com include:_spf.ancien-router.com
  include:mail.partenaire.fr include:_spf.salesforce.com include:servers.mcsv.net -all

Erster Durchgang im Analyzer: Zwei Probleme koexistieren. Zunächst löst include:_spf.ancien-router.com auf nichts auf — der Dienstleister hat seinen Dienst vor sechs Monaten eingestellt. Das ist ein Void Lookup, und es gibt einen zweiten, weiter hinten, auf einer toten Subdomain. Zwei Void Lookups sind das Limit; der geringste weitere lässt es kippen. Rollt man dann die verbleibenden include ab, zählt man elf Auflösungen: Das Limit von zehn ist ebenfalls überschritten. Zwei aufeinandergestapelte PermError-Ursachen, was erklärt, warum die Diagnose „nach Augenmaß" gescheitert war.

Die Korrektur erfolgt in zwei Schritten. Man entfernt zuerst die beiden toten include (ancien-router und die verstorbene Subdomain): Über diese Quellen laufen ohnehin keine Mails mehr. Dieses einfache Aufräumen beseitigt die Void Lookups und lässt die Zählung auf acht oder neun Auflösungen zurückfallen. Da die Marge dann noch knapp bleibt, verschiebt man Mailchimp (servers.mcsv.net) auf eine Subdomain news. mit eigenem SPF. Die Root-Domain fällt deutlich unter die Grenze, ohne Void Lookup. PermError gelöst — und die eigentliche Lektion lautet, dass „wir haben nichts geändert" fast immer falsch ist: Ein Dienstleister hat geschlossen, und der Eintrag ist unter dem Team gealtert.

Häufige Fragen

Bedeutet PermError, dass meine Mails abgewiesen werden? Nicht direkt durch SPF, aber über DMARC: Wenn SPF im PermError ist und DKIM sich nicht ausrichtet, scheitert die Nachricht an DMARC und unterliegt der veröffentlichten Richtlinie. In der Praxis kostet ein unbehobener PermError am Ende E-Mails.

Was ist der Unterschied zwischen PermError und TempError? Der TempError ist temporär (vorübergehende DNS-Störung) und löst sich oft von selbst oder beim erneuten Versuch. Der PermError ist permanent: Er stammt aus dem Eintrag selbst und verschwindet erst nach der Korrektur.

Warum ist mein SPF plötzlich im PermError, obwohl es funktionierte? Fast immer, weil ein hinzugefügter Dienstleister die Grenze der zehn Auflösungen überschreiten ließ, oder weil ein include jetzt auf eine gelöschte Domain zeigt (Void Lookup). Es ist eine überschrittene Schwelle, keine kontinuierliche Verschlechterung.

Wie viele Void Lookups sind erlaubt? Zwei. Über zwei DNS-Auflösungen hinaus, die nichts zurückgeben, ist es PermError. Die toten include und die Tippfehler in den Domainnamen sind vorrangig zu jagen.

Kann ein Analyzer meinen PermError automatisch beheben? Er diagnostiziert ihn präzise, aber die Korrektur hängt von der Ursache ab (Aufräumen, Zusammenführen, Syntax). Ein Copilot wie Thomas geht weiter: Er schlägt den korrigierten Eintrag vor, zugeschnitten auf den behandelten Fall.

Künftige PermErrors vorbeugen

Ein PermError kommt nie ohne Grund, und dieselben Ursachen kehren wieder. Drei Gewohnheiten vermeiden sie dauerhaft:

• Das include eines Dienstleisters an dem Tag entfernen, an dem sein Dienst aufgegeben wird. Genau das erzeugt einen Void Lookup, wenn der Dienst später schließt, Monate nachdem alle ihn vergessen haben.
• Die Auflösungszählung überwachen bei jedem Hinzufügen einer Quelle: eine Marge vor der Grenze von zehn halten, sie nie streifen. Ein Eintrag mit neun Auflösungen ist eine Zeitbombe.
• Die SPF-Verwaltung zentralisieren. Der doppelte Eintrag kommt fast immer von zwei Teams, die das DNS jeweils für sich ändern. Eine einzige Hand am Eintrag beseitigt die Mehrdeutigkeit an der Wurzel.

Eine vierteljährliche Kontrolle genügt, um ein tot gewordenes include oder eine steigende Zählung zu erkennen — lange bevor der PermError in der Produktion zuschlägt und die Rechnungen in den Spam schickt.

Eine weitere Gewohnheit, die sich lohnt: nach jeder DNS-Änderung testen, nicht nur nach Kalender. Der PermError im obigen Beispiel blieb genau deshalb unbemerkt, weil niemand den Eintrag neu auswertete, als der alte Dienstleister abgeschaltet wurde — die Änderung, die SPF kaputt machte, sah überhaupt nicht nach einer SPF-Änderung aus. Jede Modifikation, die die Versandinfrastruktur berührt (ein Dienstleister kommt hinzu oder fällt weg, eine Migration, eine neu angelegte Subdomain), ist als Auslöser für eine schnelle SPF-Kontrolle zu behandeln: Das kostet Sekunden und fängt die Regression an dem Tag ab, an dem sie entsteht — solange die Ursache noch offensichtlich ist, statt sechs Monate später, wenn sich niemand mehr erinnert, was sich geändert hat.

Thomas diagnostiziert und behebt

Ein PermError hat immer eine genaue Ursache — man muss sie nur schnell finden, bevor das Mailaufkommen darunter leidet. Thomas, der virtuelle CISO, rollt den Eintrag ab, identifiziert die genaue Ursache (Überschreitung, Void Lookup, Syntax, doppelter Eintrag) und generiert den korrigierten SPF-Eintrag, sauber und unter der Grenze von zehn.

Eine Domain kostenlos analysieren oder ein Konto erstellen, um aus dem PermError herauszukommen und draußen zu bleiben.