SPF PermError: Was das bedeutet und wie du es behebst

Von allen Ergebnissen, die eine SPF-Auswertung liefern kann, ist der PermError das tückischste. Es ist weder ein pass noch ein fail: Es ist ein permanenter Fehler, der bedeutet, dass dein Eintrag nicht korrekt auswertbar ist. Für den empfangenden Server ist es fast so, als existierte dein SPF gar nicht — und obendrein liefert es DMARC ein negatives Signal. Die Falle: Deine Mails sind völlig legitim; nur dein Eintrag ist kaputt. Dieser Leitfaden erklärt, was ein PermError wirklich ist, seine Hauptursachen, und wie du jede davon diagnostizierst und behebst.

Die möglichen Ergebnisse einer SPF-Auswertung

Um den PermError einzuordnen, musst du die sieben Ergebnisse kennen, die SPF produzieren kann:

• pass — die IP ist autorisiert.
• fail (Hardfail) — die IP ist nicht autorisiert, klares Signal (-all).
• softfail — wahrscheinlich nicht autorisiert, weiches Signal (~all).
• neutral — keine Position (?all).
• none — überhaupt kein SPF-Eintrag.
• temperror — temporärer Fehler (oft eine vorübergehende DNS-Störung); erneut versuchen.
• permerror — permanenter Fehler: Der Eintrag ist ungültig oder nicht auswertbar.

PermError und TempError werden oft verwechselt. Die Unterscheidung ist entscheidend: Ein TempError löst sich in der Regel von selbst (Netzwerk, kurzzeitiges DNS), während ein PermError niemals verschwindet, solange du deinen Eintrag nicht korrigierst.

Warum ein PermError gefährlich ist

Ein PermError „blockiert" deine Mails nicht direkt, aber er beraubt deine Domain jeglichen SPF-Schutzes und belastet vor allem DMARC. Für DMARC ist ein SPF im PermError nicht ausgerichtet und besteht nicht. Wenn DKIM die Nachricht nicht rettet, scheitert sie an DMARC — und je nach deiner Richtlinie (quarantine, reject) landet sie im Spam oder wird abgewiesen. Anders gesagt: Ein kaputter Eintrag kann deine eigenen legitimen Mails gegen die Wand fahren. Genau deshalb behebt man einen PermError schnell.

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. Überschreitest du zehn, 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. Lies aufmerksam nach — oder, sicherer, lass die Syntax von einem Werkzeug validieren.

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 du deinen PermError diagnostizierst

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

1. Hole deinen Eintrag (dig +short TXT deine-domain.de) und bestätige, dass es nur einen gibt.
2. Rolle den Baum der include ab, um die tatsächlichen Auflösungen zu zählen und Void Lookups zu erkennen.
3. Validiere die Syntax Mechanismus für Mechanismus.
4. Identifiziere die Ursache unter den fünf oben genannten.

Du kannst alles von Hand machen, aber ein Analysewerkzeug geht viel schneller. Unser kostenloser DMARC-Analyzer rollt dein SPF ab, zählt die Auflösungen, erkennt die Void Lookups und Syntaxfehler und sagt dir genau, warum du im PermError bist. Der vollständige Prüfweg steht in wie du deinen Eintrag prüfst.

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

Wenn du deine Aggregatberichte liest, unterscheide gut, was du siehst. Ein SPF-fail (das aus einem PermError oder einer nicht autorisierten IP stammen kann) hat nicht dieselbe Ursache wie ein softfail. Und vor allem: Denk daran, dass das SPF-Feld der Reports die Ausrichtung widerspiegelt, nicht nur das rohe Ergebnis. Eine Quelle im PermError erscheint als Fehler; sobald dein 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-routeur.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-routeur.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-routeur 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 deiner 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 deinem Eintrag und verschwindet erst nach der Korrektur.

Warum ist mein SPF plötzlich im PermError, obwohl es funktionierte? Fast immer, weil du die Grenze der zehn Auflösungen durch das Hinzufügen eines Dienstleisters überschritten hast, 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. Jage die toten include und die Tippfehler in den Domainnamen.

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, der auf deinen Fall zugeschnitten ist.

Künftige PermErrors vorbeugen

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

• Entferne das include eines Dienstleisters an dem Tag, an dem du aufhörst, ihn zu nutzen. Genau das erzeugt einen Void Lookup, wenn der Dienst später schließt, Monate nachdem alle ihn vergessen haben.
• Überwache deine Auflösungszählung bei jedem Hinzufügen einer Quelle: Halte eine Marge vor der Grenze von zehn, streife sie nicht. Ein Eintrag mit neun Auflösungen ist eine Zeitbombe.
• Zentralisiere die SPF-Verwaltung. 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 deine Rechnungen in den Spam schickt.

Lass Thomas diagnostizieren und beheben

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

Analysiere deine Domain kostenlos → oder erstelle ein Konto, um aus dem PermError herauszukommen und draußen zu bleiben.