SPF permerror beheben

Was permerror bedeutet

RFC 7208 kennt sieben SPF-Ergebnisse: none, neutral, pass, fail, softfail, temperror und permerror. Ein permerror (permanent error) sagt: Der Record ist so beschaffen, dass eine korrekte Auswertung unmöglich ist. Im Gegensatz zum temperror hilft kein zweiter Versuch, der Fehler liegt in der Zone selbst.

Wie der Empfänger damit umgeht, entscheidet er allein. Google und Microsoft behandeln permerror in der Praxis wie "kein SPF": Die Mail bekommt keinen Authentifizierungsbonus, und wenn DMARC auf SPF angewiesen ist, schlägt auch DMARC fehl. Genau deshalb ist ein permerror schlimmer als ein fehlender Record: Du glaubst, geschützt zu sein, bist es aber nicht.

Ursache 1: Mehr als zehn DNS-Lookups

Die mit Abstand häufigste Ursache. Der Empfänger darf beim Auswerten höchstens zehn DNS-Abfragen machen. Jedes include, a, mx, ptr, exists und redirect zählt, und zwar inklusive der Lookups, die die eingebundenen Records selbst erzeugen. Microsoft 365 kostet zwei, Google Workspace drei, ein typisches Newsletter-Tool zwei bis vier. Mit einem CRM, einem Ticketsystem und dem alten Hoster ist das Limit schnell überschritten.

Die Lösung ist Aufräumen, nicht Tricksen: Entferne Dienste, die nicht mehr senden. Ersetze includes von Diensten mit festen IP-Adressen durch ip4- oder ip6-Mechanismen, die keinen Lookup kosten. Wenn das nicht reicht, verteile Absender auf Subdomains (newsletter.beispiel.de mit eigenem SPF), denn jede Domain hat ihr eigenes Limit.

v=spf1 include:spf.protection.outlook.com include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net include:spf.hoster-alt.de -all

Ergebnis: 13 Lookups, permerror. Nach dem Aufräumen:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ip4:203.0.113.10 -all

Ursache 2: Mehrere SPF-Records

Eine Domain darf genau einen TXT-Record haben, der mit v=spf1 beginnt. Zwei davon sind laut RFC ein permerror, unabhängig vom Inhalt. Das passiert, wenn ein Dienstleister in seiner Anleitung schreibt "füge diesen TXT-Record hinzu" und der Kunde das wörtlich nimmt, statt den bestehenden Record zu erweitern.

Prüfe alle TXT-Records der Domain und führe alle Mechanismen in einem einzigen Record zusammen. Der Rest wird gelöscht.

Ursache 3: Syntaxfehler

Ein Tippfehler reicht. Typische Fälle: "include=" statt "include:", ein Leerzeichen im Mechanismus, "v=spf1" nicht am Anfang, ein Zeilenumbruch oder Anführungszeichen mitten im Record, weil der DNS-Editor lange Strings aufgeteilt hat, oder ein Mechanismus, den es nicht gibt ("ipv4:" statt "ip4:").

Gerade Strings über 255 Zeichen sind tückisch: DNS erlaubt sie nur als mehrere Teilstrings, die der Empfänger wieder zusammensetzt. Manche DNS-Panels setzen die Trennung falsch, dann steht mitten in einer Domain ein Anführungszeichen.

• Jeder Mechanismus mit Doppelpunkt: include:, ip4:, ip6:, a:, mx:, exists:
• Nur ein Leerzeichen zwischen den Mechanismen, keine Tabs, keine Kommas
• Das all-Ende genau einmal und ganz am Schluss
• Keine Großschreibung nötig, aber schädlich ist sie nicht

Ursache 4: Include auf eine Domain ohne SPF

include:spf.dienst.de funktioniert nur, wenn spf.dienst.de selbst einen SPF-Record hat. Fehlt er, weil der Dienst umgezogen ist, den Hostnamen geändert hat oder der Kunde ihn abgetippt hat, ergibt das einen permerror für die gesamte Domain. Ein einziges verwaistes include reicht.

Der SPF Checker löst jedes include auf und zeigt, welche Ziele keinen Record liefern. Solche Einträge entfernst du oder ersetzt sie durch den aktuellen Hostnamen aus der Dokumentation des Anbieters.

Ursache 5: Redirect-Schleifen und ptr

Seltener, aber hartnäckig: Ein redirect=, der auf eine Domain zeigt, die wieder zurückverweist, oder ein include, das sich über Umwege selbst einbindet. Der Empfänger bricht ab und meldet permerror. Der veraltete ptr-Mechanismus verursacht zwar keinen permerror, wird aber von vielen Empfängern ignoriert und kostet Lookups; entferne ihn.

So gehst du vor

Die Reihenfolge ist wichtig, weil ein Fehler den nächsten verdecken kann.

1. Alle TXT-Records der Domain abrufen und sicherstellen, dass genau einer mit v=spf1 beginnt.
2. Den Record durch den SPF Checker laufen lassen: Syntax, Lookup-Zahl und verwaiste Includes werden angezeigt.
3. Nicht mehr genutzte Dienste entfernen. Wenn du unsicher bist, frag den Kunden, welche Systeme in den letzten zwölf Monaten Mails gesendet haben.
4. Statische Absender auf ip4/ip6 umstellen, große Versender auf Subdomains auslagern.
5. Neuen Record mit -all oder vorerst ~all setzen, TTL kurz halten, nach fünf Minuten erneut prüfen.
6. DMARC-Reports der folgenden Tage beobachten: Dort siehst du, ob alle legitimen Absender jetzt pass liefern.

Häufige Fragen

Kann ich das Lookup-Limit mit SPF-Flattening umgehen?

Flattening ersetzt alle includes durch die aufgelösten IP-Adressen. Das funktioniert, bis ein Anbieter seine Adressen ändert, und das passiert bei Microsoft und Google regelmäßig. Ohne Automatisierung ist Flattening eine tickende Zeitbombe. Aufräumen ist fast immer die bessere Lösung.

Wie lange dauert es, bis der behobene Record wirkt?

So lange wie die TTL des alten Records, meist zwischen fünf Minuten und einer Stunde. Empfänger cachen SPF nicht darüber hinaus.

Warum zeigt ein Tool permerror, ein anderes aber pass?

Manche Tools zählen Lookups anders oder ignorieren Syntaxfehler. Maßgeblich ist das Verhalten großer Empfänger, und die halten sich streng an RFC 7208. Im Zweifel hilft ein Blick in die DMARC-Aggregate-Reports von Google.