SPF reparieren: doppelte Policies, Includes und falsche Absenderdomains

Zuerst den tatsächlich geprüften Namen finden

SPF bewertet im normalen Fall die Envelope-Absenderdomain und die sendende IP. Die im Mailprogramm sichtbare From-Adresse ist nicht automatisch der SPF-Abfragename. Öffne eine empfangene Testmail und vergleiche Return-Path und Authentication-Results. Bei einem leeren Envelope-Absender kann stattdessen die HELO-Identität relevant sein.

Fehler 1: zwei SPF-Policies am selben Namen

Falsch wäre die gleichzeitige Veröffentlichung von v=spf1 ip4:192.0.2.25 -all und v=spf1 include:_spf.sender.example -all als getrennte Policies für example.com. Empfänger fügen diese nicht zu einer gemeinsamen Liste zusammen.

Wenn beide Versandwege tatsächlich legitim sind, kann das Gerüst v=spf1 ip4:192.0.2.25 include:_spf.sender.example -all lauten. Die Werte sind fiktiv und müssen aus deiner Konfiguration stammen. Andere TXT-Records, etwa Anbieter-Verifizierungen, bleiben erlaubt. Es geht um die Anzahl der SPF-Policies, nicht die Anzahl sämtlicher TXT-Records.

Fehler 2: Includes ohne Prüfung anhängen

Ein include autorisiert nicht pauschal einen Firmennamen. Es verweist auf eine andere SPF-Auswertung. Verwende den genauen Hostnamen, den dein Anbieter aktuell für den betroffenen Versanddienst dokumentiert. Verschachtelte DNS-verursachende Terme zählen beim Limit der Auswertung mit. Ein kurzes sichtbares SPF kann daher trotzdem das Limit überschreiten. DNSABC zählt direkte Terme und löst diese Abhängigkeiten nicht vollständig rekursiv auf.

Fehler 3: sichtbares From und SPF verwechselt

Ein Dienst kann From: rechnung@example.com verwenden, aber den Envelope-Absender unter einer eigenen Domain führen. SPF kann für die Anbieter-Domain bestehen und trotzdem nicht mit example.com ausgerichtet sein. Eine passende DKIM-Signatur kann den für DMARC benötigten ausgerichteten Erfolgsweg liefern. Prüfe deshalb das gesamte Ergebnis einer realen Nachricht.

Warum +all keine Reparatur ist

+all erlaubt jeder sendenden IP, SPF zu bestehen. Das beseitigt vielleicht einen Fehlerstatus, aber zugleich die beabsichtigte Begrenzung. Entferne nicht verstandene Regeln nicht blind. Dokumentiere Server, Newsletter, Formulare und Dienstleister, konsolidiere die Policy und teste neu versendete Nachrichten aus jedem System.

Sauberer Abschluss

Kontrolliere den vollständigen veröffentlichten Namen beim autoritativen Anbieter und mindestens zwei Resolver. Warte die vorherige TTL ab, wenn Empfänger noch alte Antworten sehen. Behalte die genaue Fehlermeldung: none, fail, softfail und permerror sind verschiedene Ergebnisse und verlangen unterschiedliche Ursachenprüfung.