SPF-Fehler beheben: Ursachen, Codes und DNS-Korrekturen

Ihre E-Mail wurde zurückgewiesen. Im Header steht spf=fail. Ein 550 5.7.1 oder 550 5.7.26 erscheint, während ein Kunde auf eine nie eingetroffene Antwort wartet.

Ein SPF-Fehler ist kein Inhaltsproblem, sondern ein Fehler der DNS-Authentifizierung. Der empfangende Mailserver hat Ihren SPF-Eintrag geprüft, die Versand-IP nicht in der Liste autorisierter Absender gefunden und die Nachricht möglicherweise abgelehnt, bevor sie einen Spamordner erreichen konnte.

Seit Februar 2024 lehnen Google und Yahoo nicht authentifizierte E-Mails auf Protokollebene häufiger ab, statt sie nur als verdächtig zu markieren. Dieser Leitfaden erklärt den jeweiligen Fehlercode, zeigt, wo die betroffene IP im Header steht, und führt durch drei DNS-Korrekturen, die einen großen Teil der SPF-Fehler beheben können. So beginnen Sie gezielt mit der wahrscheinlich passenden Korrektur.

Wenn Sie erstmals E-Mail auf Ihrer Domain einrichten, sollten Sie vor der Fehlersuche eine vollständige DNS-Basiskonfiguration schaffen. SPF-Probleme entstehen häufig durch Lücken bei der Ersteinrichtung.

Was ist ein SPF-Fehler?

Ein SPF-Fehler entsteht, wenn ein empfangender Mailserver den Sender-Policy-Framework-Eintrag Ihrer Domain auswertet und die Versand-IP nicht als autorisiert findet. SPF wird als DNS-TXT-Eintrag veröffentlicht und nennt IP-Adressen und Maildienste, die in Ihrem Namen senden dürfen. Schlägt die Prüfung fehl, kann der Server die Nachricht ablehnen (Hard Fail) oder als verdächtig annehmen (Soft Fail). Ihre DMARC-Richtlinie wertet beides als Fehlschlag.

SPF prüft den Envelope-Absender, also die während des SMTP-Handshakes ausgehandelte MAIL FROM-Adresse, nicht den sichtbaren "From"-Header. Dieser Unterschied ist bei der Ursachenanalyse wichtig.

Lesen Sie zuerst den Fehlercode

Mailserver verwenden unterschiedliche SMTP-Codes für einen SPF-Fehler. Der Code zeigt, welche Entscheidung der Empfänger getroffen hat. Wer 550 5.7.26 wie einen allgemeinen 550 5.7.1 behandelt, verliert Diagnosezeit. Ordnen Sie daher den Code zuerst einer Ursache zu, bevor Sie DNS-Einträge ändern.

Schritt 1: Betroffene IP im Header finden

Raten Sie nicht, welche IP den SPF-Fehler verursacht hat. Öffnen Sie den Rohheader der zurückgewiesenen Nachricht oder der Unzustellbarkeitsmeldung und suchen Sie nach Authentication-Results. Dieser Header nennt die vom Empfänger geprüfte IP und dessen Entscheidung.

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of team@example.com does not designate
   192.0.2.55 as permitted sender)

Dort stehen zwei forensisch wichtige Angaben: die Versand-IP (192.0.2.55) und die geprüfte Domain (example.com). Ermitteln Sie nun den Eigentümer der IP:

• Ein kürzlich eingeführtes SaaS-Werkzeug? (HubSpot, Zendesk, Shopify)
• Ihr Webserver? (WordPress, cPanel)
• Eine Mailweiterleitung? (siehe Abschnitt zur Weiterleitungsfalle)

Prüfen Sie anschließend Ihren aktuellen SPF-Eintrag:

dig +short txt yourdomain.com | grep spf

Sehen Sie mehr als eine Zeile, die mit v=spf1 beginnt, haben Sie bereits eine mögliche Ursache gefunden.

Schritt 2: Die drei häufigsten Korrekturen

Viele SPF-Fehler haben eine von drei Ursachen: ein fehlendes Anbieter-Include, doppelte Einträge oder mehr als 10 DNS-Abfragen. Wählen Sie die Korrektur passend zu den Ergebnissen aus Schritt 1.

Korrektur 1: Fehlendes Include (Anbieterlücke)

Sie haben ein neues E-Mail-Werkzeug wie HelpScout, HubSpot, Zendesk oder Shopify Transactional Email hinzugefügt, aber DNS nicht aktualisiert. Der Dienst sendet in Ihrem Namen über eine nicht autorisierte IP. Dies ist nach der Einführung eines neuen Anbieters eine häufige Ursache für SPF-Fehler.

Fehlerhafter Eintrag:

v=spf1 include:spf.trekmail.net -all

Gültiger Eintrag (nach Hinzufügen von HelpScout):

v=spf1 include:spf.trekmail.net include:helpscoutemail.com -all

Suchen Sie die erforderliche SPF-Include-Zeichenfolge in der Dokumentation des Anbieters. Ergänzen Sie sie in Ihrem bestehenden SPF-TXT-Eintrag, statt einen neuen Eintrag anzulegen. Jeder verwendete Versanddienst sollte aufgeführt sein.

Korrektur 2: Doppelter Eintrag (schwerer Syntaxfehler)

Pro Domain ist nur ein SPF-Eintrag zulässig. Wenn Sie für ein neues Werkzeug einen zweiten TXT-Eintrag anlegen, statt ihn mit dem bestehenden zu vereinen, sehen Empfänger zwei widersprüchliche Richtlinien und erklären beide für ungültig. Das führt zu einem PermError und kann einen harten SPF-Fehler für alle E-Mails der Domain auslösen, auch für zuvor problemlos zugestellte Nachrichten.

Falsch, zwei getrennte Einträge:

v=spf1 include:spf.trekmail.net -all
v=spf1 include:_spf.google.com -all

Richtig, zu einem Eintrag zusammengeführt:

v=spf1 include:spf.trekmail.net include:_spf.google.com -all

Melden Sie sich bei Ihrem DNS-Anbieter an, behalten Sie nur einen SPF-TXT-Eintrag und führen Sie alle Angaben in einer Zeile zusammen. Ein durch doppelte Einträge verursachter PermError kann SPF für alle Absender beeinträchtigen, bis der Eintrag korrigiert ist.

Korrektur 3: Das Limit von 10 Abfragen (Architekturfehler)

RFC 7208 begrenzt die SPF-Auswertung auf 10 DNS-Abfragen, damit Server nicht als DNS-Verstärkungsvektoren missbraucht werden. Mechanismen wie include, a und mx zählen jeweils zum Limit. Auch verschachtelte Includes, bei denen ein Anbieter einen weiteren Anbieter einbindet, werden gezählt.

Bei mehr als 10 Abfragen entsteht PermError, und SPF kann für alle Absender fehlschlagen. Prüfen Sie die aktuelle Zahl, indem Sie den Eintrag verfolgen:

dig +short txt yourdomain.com

Zählen Sie jeden Mechanismus include, a und mx und folgen Sie den verschachtelten Includes der Anbieter. Wenn Sie das Budget überschreiten, bieten sich zwei saubere Ansätze an:

1. Absender auf Subdomains aufteilen. Verschieben Sie Marketingwerkzeuge mit hohem Volumen auf marketing.yourdomain.com. Die Subdomain erhält ein eigenes Budget von 10 Abfragen, getrennt vom Eintrag der Hauptdomain.
2. Eintrag abflachen. Ersetzen Sie include-Ketten durch die tatsächlichen IPs, in die sie aufgelöst werden, und verwenden Sie ip4: oder ip6:. Diese Mechanismen zählen nicht als Abfragen. Nachteil: Wenn Anbieter IPs wechseln, müssen Sie den Eintrag manuell aktualisieren.

Beachten Sie außerdem das Limit für leere Abfragen. Wenn mehr als zwei Abfragen in der Kette NXDOMAIN zurückgeben, etwa wegen include:spf.gogle.com, wird der Eintrag gemäß RFC 7208 §11.1 ungültig. Ein Tippfehler in einem verschachtelten Anbieter-Include kann die gesamte SPF-Auswertung beeinträchtigen.

Weiterleitungsfalle: Warum SPF bei legitimen E-Mails fehlschlägt

Ein SPF-Fehler kann auch ohne fehlerhafte DNS-Konfiguration entstehen. Sie senden an eine Alumni-Adresse (alice@university.edu), die automatisch an Gmail (alice@gmail.com) weiterleitet. Gmail sieht die Nachricht von der Server-IP der Universität. Diese IP steht nicht in Ihrem SPF-Eintrag, sodass SPF trotz korrekter ursprünglicher Einrichtung fehlschlägt.

Der Weg lautet: Ihr Server -> Universitätsserver -> Gmail. Gmail bewertet den letzten Hop. Weiterleitungsfehler lassen sich nicht allein mit SPF beheben, weil SPF nur die ursprüngliche Versand-IP autorisiert. Sobald ein Weiterleiter beteiligt ist, stimmt die IP-Prüfung nicht mehr.

Die passende Ergänzung ist DKIM. DKIM signiert Nachrichtentext und Header kryptografisch. Ein Weiterleiter verändert den Nachrichtentext normalerweise nicht, sodass die DKIM-Signatur den Relay-Hop häufig übersteht. Bei einem SPF-Fehler kann eine gültige DKIM-Signatur die Nachricht unter DMARC weiterhin authentifizieren.

Wenn Sie Weiterleitung auf Infrastrukturebene betreiben und SPF-kompatible Umschreibungen benötigen, sollten Sie das Sender Rewriting Scheme (SRS) kennen. Damit können Weiterleiter den Envelope-Absender so umschreiben, dass SPF am Ziel bestehen kann. Weitere Weiterleitungsprobleme behandelt der Leitfaden zur Einrichtung und Fehlerbehebung von E-Mail-Weiterleitungen.

Korrektur vor dem Fortfahren prüfen

Warten Sie nach einer DNS-Änderung auf die Verteilung, bei vielen Anbietern typischerweise 5 bis 30 Minuten und in einzelnen Fällen einige Stunden. Prüfen Sie anschließend, ob die Änderung tatsächlich übernommen wurde.

Senden Sie eine Testmail an eine Gmail-Adresse, öffnen Sie den Rohheader und suchen Sie nach Authentication-Results. Das gewünschte Ergebnis lautet:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of team@example.com designates
   192.0.2.55 as permitted sender)

Steht dort weiterhin spf=fail oder spf=softfail, wurde die Änderung noch nicht verteilt oder der Eintrag enthält noch ein Problem. Vergleichen Sie die IP im Header mit der im aktualisierten Eintrag. Beide sollten übereinstimmen.

Sie können den Eintrag auch direkt prüfen:

dig +short txt yourdomain.com

Prüfen Sie, dass genau ein Eintrag mit v=spf1 beginnt, alle Versanddienste enthält und mit -all (Hard Fail) oder ~all (Soft Fail) endet.

SPF für mehrere Domains verwalten

Bei einer Domain ist die SPF-Verwaltung meist eine einmalige Aufgabe: Includes ergänzen, Duplikate zusammenführen und die Zahl der Abfragen korrigieren. Wenn Sie jedoch E-Mail für 10, 50 oder 500 Domains mit jeweils eigenen SPF-Einträgen und SaaS-Anbietern verwalten, wird die manuelle Diagnose jedes SPF-Fehlers zu spürbarem Betriebsaufwand.

Das verwaltete SMTP von TrekMail, verfügbar ab Starter für $3.50/mo, reduziert die Konfiguration auf ein Include je Domain. TrekMail übernimmt IP-Wechsel, Bounce-Überwachung, DKIM-Ausrichtung und die zugrunde liegende Zustellungsinfrastruktur. Im Agency-Tarif ($23.25/mo) können Agenturen eine standardisierte DNS-Vorlage auf Kundendomains anwenden, statt SPF-Fehler in vielen einzelnen Einträgen zu suchen.

Mit einer 14-day kostenlosen Testphase können Sie die verwaltete Zustellung praktisch erproben.

SPF-Fehler in Kurzform

Ein SPF-Fehler bedeutet, dass der Empfangsserver DNS geprüft, die Versand-IP nicht gefunden und die Richtlinie angewendet hat. Hard Fail (-all) kann Ablehnung bedeuten, Soft Fail (~all) eine Platzierung im Spam. PermError bedeutet, dass der Eintrag ungültig ist und SPF für Absender fehlschlagen kann, bis der Eintrag korrigiert wurde.

Arbeiten Sie die Korrekturen der Reihe nach durch:

1. Betroffene IP im Header Authentication-Results finden
2. Fehlendes Anbieter-Include ergänzen, wenn ein neuer Dienst den Fehler verursacht
3. Doppelte SPF-Einträge zu einem Eintrag zusammenführen
4. DNS-Abfragen auf weniger als 10 reduzieren oder Absender mit hohem Volumen auf Subdomains verteilen
5. Bei weitergeleiteten Nachrichten DKIM implementieren, weil SPF einen Relay-Hop nicht zuverlässig übersteht

Wählen Sie zuerst die passende Korrektur und bestätigen Sie das Ergebnis anhand der Header.