„550 5.7.23 The message was rejected because of Sender Policy Framework violation“ (SPF fail): so behebst du es

Was das bedeutet

Der empfangende Server hat den SPF-Eintrag deiner Domain geprüft und festgestellt, dass der Server, der die E-Mail gesendet hat, nicht für deine Domain senden darf. Bei Microsoft 365 und Exchange sieht der Bounce so aus:

550 5.7.23 The message was rejected because of Sender Policy Framework violation

Andere Server formulieren es kürzer. Die Meldung sieht meist so aus:

550 5.7.1 SPF fail - not authorized
550 5.7.1 Rejected by SPF

SPF (Sender Policy Framework) ist ein TXT-Eintrag im DNS deiner Domain, der die Server auflistet, die für sie E-Mails senden dürfen. Sendet ein Server, der nicht auf der Liste steht, „schlägt SPF fehl“. Endet der Eintrag mit -all („alles andere ablehnen“), lehnen viele Empfänger die E-Mail sofort ab.

Warum das passiert

• Ein Absender fehlt im SPF. Du nutzt neu ein Newsletter-Tool, ein CRM, einen Onlineshop, ein Rechnungstool oder einen neuen E-Mail-Anbieter und hast ihn nicht hinzugefügt.
• Die IP deines Servers hat sich geändert (neues Hosting, neuer VPS), und SPF nennt noch die alte.
• Zwei SPF-Einträge existieren für die Domain. Das ist ungültig, und SPF schlägt für jeden Absender fehl.
• Zu viele Abfragen. SPF erlaubt nur 10 DNS-Abfragen (jedes include:, a, mx zählt). Darüber liefert SPF einen Fehler, den manche Empfänger wie ein Fail behandeln.
• Weiterleitung. Die E-Mail ging an eine Adresse, die an Microsoft 365 oder ein anderes Postfach weiterleitet. Der weiterleitende Server steht nicht in deinem SPF, also schlägt die Prüfung dort fehl.
• Jemand anderes fälscht deine Domain. In diesem Fall macht SPF mit der Ablehnung genau seinen Job.

So prüfst du es

1. Mach einen Delivmail-Test. Sende von derselben App oder demselben Server, der den Bounce erhalten hat, eine E-Mail an die einmalige Adresse auf der Startseite (/). Der Bericht zeigt die sendende IP, die von SPF geprüfte Domain (den Envelope-Absender bzw. Return-Path) und das SPF-Ergebnis mit Begründung.
2. Scanne deine Domain. Nutze /domain-scanner, um deinen SPF-Eintrag zu lesen. Er zeigt, ob es zwei Einträge, einen Syntaxfehler oder zu viele Abfragen gibt.
3. Lies die Header des Bounces. Der Bounce enthält oft eine Zeile wie Received-SPF: Fail mit der geprüften IP.

So behebst du es

1. Finde den Versanddienst. Der Delivmail-Bericht zeigt die IP. Die Dokumentation des Dienstes nennt sein SPF-Include, zum Beispiel include:spf.protection.outlook.com für Microsoft 365 oder include:_spf.google.com für Google Workspace.
2. Füge ihn zu deinem einzigen SPF-Eintrag hinzu. Bearbeite den bestehenden Eintrag, leg keinen zweiten an:

   v=spf1 include:spf.protection.outlook.com include:spf.newsletter-example.com ip4:203.0.113.10 -all

3. Fasse doppelte Einträge zusammen. Wenn du zwei v=spf1-Einträge hast, kombiniere sie zu einem.
4. Bleib unter 10 Abfragen. Entferne Dienste, die du nicht mehr nutzt. Ersetze a und mx durch ip4:, wenn du die IP kennst.
5. Nutze ~all, während du testest. Damit werden unbekannte Absender als verdächtig markiert statt abgelehnt. Geh zurück auf -all, sobald alles besteht.
6. Richte auch DKIM ein. DKIM signiert die E-Mail und übersteht Weiterleitungen. Mit DKIM und DMARC verlassen sich Empfänger weniger auf SPF allein.

Wenn eine Weiterleitung die Ursache ist

Bitte die Person, anders weiterzuleiten (eine Postfachregel, die mit SRS umleitet, oder die Mails direkt abholen), oder sorge dafür, dass deine E-Mails mit DKIM signiert sind, damit DMARC trotzdem bestehen kann.

Prüfe, ob es behoben ist

Warte, bis sich die DNS-Änderung verbreitet hat (oft Minuten, bis zur TTL des Eintrags, manchmal einige Stunden). Starte den Domain-Scanner, um zu bestätigen, dass es einen einzigen gültigen SPF-Eintrag gibt, und mach dann einen neuen Delivmail-Test vom selben Dienst: SPF sollte pass zeigen. Sende die E-Mail zum Schluss erneut an die Adresse, die den Bounce verursacht hat.