So sieht die Meldung aus
550 5.7.1 Message rejected due to SPF check failure 550-5.7.1 SPF check failed: domain of sender does not designate this server Received-SPF: fail (domain does not designate 203.0.113.5 as permitted sender)

Was passiert ist

Der Empfänger hat die Verbindungs-IP gegen den SPF-Record der Absenderdomain geprüft und keinen Treffer gefunden. Der Record endet auf -all („hardfail“), was so viel heißt wie: alles, was ich nicht ausdrücklich aufgezählt habe, ist eine Fälschung. Genau danach handelt der Empfänger.

Wichtig für die Diagnose: geprüft wird die IP, die tatsächlich die SMTP-Verbindung aufbaut, und die Domain aus dem Envelope-From (Return-Path) — nicht die aus dem sichtbaren From:-Header. Beide können auseinanderfallen.

Die vier üblichen Ursachen

  1. Ein Absender wurde vergessen. Der häufigste Fall. Newsletter-Tool, CRM, Ticketsystem, Shop, Rechnungsversand oder Monitoring senden über eigene IPs, die nie in den Record aufgenommen wurden.
  2. Der Versand hat den Anbieter gewechselt. Nach einem Umzug zeigt der Record noch auf die alte Infrastruktur.
  3. IPv6 fehlt. Der Record enthält nur ip4:-Einträge, der Server stellt aber über IPv6 zu. Für den Empfänger ist das eine unbekannte Adresse.
  4. Die Mail wurde weitergeleitet. Bei einer klassischen Weiterleitung sendet der weiterleitende Server unter der ursprünglichen Envelope-Adresse — SPF schlägt dann zwangsläufig fehl. Dagegen hilft kein SPF-Eintrag, dafür ist ARC gedacht (und beim Weiterleiter SRS).

So gehst du vor

Zuerst die sendende IP aus der Fehlermeldung oder dem Bounce herausziehen — sie steht meist direkt darin oder im Received:-Header der Rückläufer-Mail. Dann den eigenen Record ansehen und prüfen, ob diese IP darin vorkommt, direkt oder über ein include:.

deinedomain.de. IN TXT "v=spf1 include:_spf.google.com ip4:203.0.113.5 -all"

Fehlt die IP, nimmst du sie auf — bevorzugt über das include: des Anbieters, weil der seine Adressen selbst pflegt, und nur ersatzweise als feste ip4:/ip6:-Angabe.

Achte beim Erweitern auf das Lookup-Limit: mehr als zehn DNS-abfragende Mechanismen machen den ganzen Record ungültig. Das ist der zweithäufigste Grund, warum eine vermeintliche Reparatur die Lage verschlimmert.

Was du nicht tun solltest

Der Record auf ~all oder ?all zurückzustellen, lässt die Meldung verschwinden, ohne das Problem zu lösen — und schwächt den Schutz deiner Domain gegen Spoofing. Wenn eine legitime Quelle abgelehnt wird, gehört sie in den Record, nicht der Record aufgeweicht.

Die Ursache in der echten Nachricht finden

Sende oder leite die betroffene E-Mail an hello@analyzemy.email weiter. Der Report zeigt für genau diese Nachricht, welche IP gesendet hat, wie SPF, DKIM und DMARC ausgefallen sind und wo die Kette bricht.

Jetzt E-Mail analysieren

Zuletzt aktualisiert: · Alle Fehlermeldungen