E-Mail wegen Cross-Domain-Spoofing abgelehnt (550 5.7.1)

Als Markdown ansehen

Beheben Sie E-Mail-Ablehnungen durch den Cross-Domain-Spoofing-Schutz: Verstehen Sie den Fehler 550 5.7.1 und passen Sie Ihre MX Plan- oder Webhosting-Konfiguration an

Ziel

Wenn Sie eine E-Mail über MX Plan, Zimbra oder den in einem Webhosting-Paket enthaltenen E-Mail-Dienst versenden und die Absenderadresse eine andere Domain verwendet als die, mit der Sie sich authentifiziert haben, lehnt OVHcloud die Nachricht ab — ein Schutz gegen Cross-Domain-Spoofing, der ab dem 20. Juli 2026 gilt.

In dieser Anleitung erfahren Sie, wie Sie die Ablehnung nachvollziehen, die Ursache bestätigen und Ihre Konfiguration anpassen, damit Ihre E-Mails wieder zugestellt werden.

Voraussetzungen

  • Sie verfügen über ein OVHcloud E-Mail-Angebot: MX Plan, Zimbra oder den in einem Webhosting-Paket enthaltenen E-Mail-Dienst.
  • Sie haben Zugriff auf das , um Ihre Domains und E-Mail-Accounts zu verwalten.

In der praktischen Anwendung

Das Problem erkennen

Abgelehnte Nachrichten erhalten folgende Meldung:

550 5.7.1 Rejected by policy: From header domain does not align with authenticated domain
Info

Dies geschieht, wenn die Domain der From-Adresse (die Adresse, von der aus Sie senden) von der Domain abweicht, mit der Sie sich authentifiziert haben (die Zugangsdaten des E-Mail-Accounts, mit denen Sie sich anmelden und senden). Der Versand von einer Adresse auf der gleichen Domain wie Ihr Authentifizierungs-Account ist davon nicht betroffen und funktioniert weiterhin.

Sie sind wahrscheinlich betroffen, wenn Sie:

  • E-Mails von einer Adresse auf einer anderen Domain als Ihrem Authentifizierungs-Account versenden
  • generische Adressen (contact@, support@, noreply@) auf einer separaten Domain verwalten
  • einen Bot, ein Skript oder eine Anwendung betreiben, die mit einer anderen Absenderdomain als der Authentifizierungsdomain versendet
  • E-Mails im Auftrag eines Dritten versenden (z. B. ein Dienstleister, der mit der Domain seines Kunden Rechnungen versendet)
  • den Versand für mehrere Marken oder Einheiten zentralisieren, die unterschiedliche Domains innerhalb einer einzigen E-Mail-Infrastruktur nutzen

Warum besteht diese Sperre?

Die Existenz dieser drei weit verbreiteten Standards macht es notwendig, die Praxis des Cross-Domain-Spoofings zu beenden:

StandardRolle
SPF (Sender Policy Framework)Überprüft, ob der sendende Server von der Absenderdomain autorisiert ist
DKIM (DomainKeys Identified Mail)Fügt eine kryptografische Signatur hinzu, die mit der sendenden Domain verknüpft ist
DMARC (Domain-based Message Authentication)Kombiniert SPF und DKIM und legt fest, was bei einem Fehlschlag geschieht

Der Versand mit einer anderen Domain als der zur Authentifizierung verwendeten bricht diese Übereinstimmung; die Sperrung schützt den Ruf Ihrer Domains und die Zustellbarkeit Ihrer legitimen Nachrichten.

Die Ablehnung beheben

Empfohlene Lösung — ein E-Mail-Account auf der Versanddomain einrichten

Richten Sie einen E-Mail-Account auf der Domain ein, von der Sie senden möchten, und authentifizieren Sie sich damit. Technisch gesehen genügt ein einziger E-Mail-Account: Sobald dieser eingerichtet ist, kann er sich authentifizieren und von jeder Adresse dieser gleichen Domain aus senden, da Spoofing innerhalb derselben Domain von dieser Sperre nicht betroffen ist.

Konfigurieren Sie diese Domain in einem Zimbra Starter-Paket — siehe unsere Anleitung Erste Schritte mit Zimbra — und richten Sie darauf einen E-Mail-Account ein.

Warning

Spoofing innerhalb derselben Domain ist ein Sicherheitsrisiko und wird bald durch den Domain-Administrator deaktivierbar sein. Derzeit kann jeder E-Mail-Account der Domain als jede andere Adresse dieser gleichen Domain senden — ein einziger Satz von Zugangsdaten legt somit alle Adressen offen, ohne Nachvollziehbarkeit pro Adresse. OVHcloud bereitet eine Einstellung vor, mit der Domain-Administratoren diese Möglichkeit vollständig deaktivieren können; eine Konfiguration, die auf einem gemeinsam genutzten E-Mail-Account beruht, der mehrere Adressen imitiert, funktioniert dann nicht mehr. Bauen Sie Ihre Konfiguration nicht darauf auf — bevorzugen Sie stattdessen:

  • Einen E-Mail-Account pro Adresse, die Sie tatsächlich verwenden, oder
  • Eine Delegationsfunktion, die kontrollierten Zugriff auf einen bestehenden E-Mail-Account gewährt, ohne dessen Passwort weiterzugeben
  • Generische Adresse: Sie verfügen über john.smith@mydomain.ovh auf MX Plan und möchten von contact@example.com aus senden. Richten Sie einen E-Mail-Account ein, z. B. mary.johnson@example.com, auf dieser Domain, und authentifizieren Sie sich damit, um als contact@example.com zu senden.
  • Mehrere Einheiten: Ihr Unternehmen verwaltet zwei Marken, eine auf mydomain.ovh und eine weitere auf example.com. Wenn Sie derzeit alle E-Mails von einem einzigen Account auf mydomain.ovh versenden, richten Sie einen Account auf example.com für die zweite Marke ein.
  • Versand im Auftrag eines Dritten: Ihre Agentur versendet Kommunikation für einen Kunden auf example.com von Ihrer eigenen Domain aus. Richten Sie einen Account auf example.com ein, um sich zu authentifizieren und mit Adressen dieser Domain zu senden.

Alternative Lösung, wenn Sie innerhalb derselben Domain bleiben

Wenn alle Ihre Adressen bereits eine gemeinsame Domain nutzen, liegt die Ursache nicht in dieser Sperre — überprüfen Sie erneut den Abschnitt Das Problem erkennen oben, da die Ablehnung zwangsläufig von einer anderen Adress-/Domain-Kombination stammt als erwartet. Um mehrere Identitäten auf dieser einen Domain zu verwalten, nutzen Sie stattdessen diese nativen Funktionen anstelle eines gemeinsam genutzten E-Mail-Accounts:

BedarfFunktionVerfügbar bei
Als eine andere Adresse derselben Domain sendenSenden alsExchange
Im Auftrag von jemandem auf derselben Domain sendenSenden im Auftrag vonExchange
Zugriff auf einen E-Mail-Account teilen, ohne das Passwort weiterzugebenZugangsrechteExchange
An eine Kontaktgruppe sendenMailingliste (MX Plan) oder Exchange-KontaktgruppenMX Plan, Exchange

Wenn das Problem weiterhin besteht

Wenn Sie Ihre Konfiguration angepasst haben und Nachrichten weiterhin mit demselben Fehler 550 5.7.1 abgelehnt werden:

  • Überprüfen Sie, ob die Adresse, mit der Sie sich authentifizieren, mit der tatsächlich von Ihrer Versandanwendung oder Ihrem Gerät verwendeten From-Adresse übereinstimmt — bei Massenversand oder automatisierten Konfigurationen wird eine Abweichung leicht übersehen.
  • Lassen Sie einem neu eingerichteten E-Mail-Account oder einer Konfigurationsänderung einige Minuten Zeit, um sich zu verbreiten, bevor Sie es erneut versuchen.
  • Kontaktieren Sie den OVHcloud Support mit den vollständigen Headern der abgelehnten Nachricht, der zur Authentifizierung verwendeten Adresse und der beabsichtigten From-Adresse.

Weiterführende Informationen

Informationen zur Verwaltung von Alias und Weiterleitungen einer bestehenden Adresse finden Sie im Leitfaden E-Mail Alias und Weiterleitung verwenden.

Weitere Informationen zu Zimbra Starter.

Vertiefende Informationen zu den zugrunde liegenden Standards finden Sie in E-Mail-Sicherheit durch SPF-Eintrag verbessern, E-Mail-Sicherheit durch DKIM-Eintrag verbessern und E-Mail-Sicherheit durch DMARC-Eintrag verbessern.

Treten Sie unserer User Community bei.

War diese Seite hilfreich?