E-mail rejeté pour usurpation de domaine (550 5.7.1)

Voir en Markdown

Résolvez les rejets d'e-mail liés à la protection anti-usurpation de domaine : comprenez l'erreur « 550 5.7.1 » et adaptez votre configuration MX Plan ou hébergement web

Objectif

Si vous envoyez un e-mail via MX Plan, Zimbra, ou le service e-mail inclus dans une offre d'hébergement web, et que l'adresse d'expéditeur utilise un domaine différent de celui utilisé lors de l'authentification, OVHcloud rejette le message — une protection contre l'usurpation de domaine (cross-domain spoofing) appliquée à partir du 20 juillet 2026.

Ce guide vous aide à comprendre le rejet, à en confirmer la cause, et à adapter votre configuration pour que vos e-mails soient de nouveau acheminés.

Prérequis

  • Une offre e-mail OVHcloud : MX Plan, Zimbra, ou le service e-mail inclus dans une offre d'hébergement web
  • Un accès à l' pour gérer vos noms de domaine et vos boîtes e-mail

En pratique

Identifier le problème

Les messages rejetés renvoient la notification suivante :

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

Cela se produit lorsque le domaine de l'adresse From (l'adresse depuis laquelle vous envoyez) diffère du domaine avec lequel vous vous êtes authentifié (les identifiants de la boîte e-mail utilisés pour vous connecter et envoyer). L'envoi depuis une adresse du même domaine que votre boîte d'authentification n'est pas concerné et continue de fonctionner.

Vous êtes probablement concerné si vous :

  • Envoyez des e-mails depuis une adresse sur un domaine différent de votre boîte d'authentification
  • Gérez des adresses génériques (contact@, support@, noreply@) sur un domaine séparé
  • Exploitez un bot, un script ou une application qui envoie des e-mails avec un domaine d'expéditeur différent du domaine d'authentification
  • Envoyez des e-mails pour le compte d'un tiers (par exemple un prestataire qui facture avec le domaine de son client)
  • Centralisez l'envoi pour plusieurs marques ou entités utilisant des domaines distincts depuis une seule infrastructure e-mail

Pourquoi ce blocage ?

Ces trois standards, aujourd'hui largement généralisés, imposent de mettre fin au cross-domain spoofing :

StandardRôle
SPF (Sender Policy Framework)Vérifie que le serveur d'envoi est autorisé par le domaine d'expéditeur
DKIM (DomainKeys Identified Mail)Ajoute une signature cryptographique liée au domaine d'envoi
DMARC (Domain-based Message Authentication)Combine SPF et DKIM et définit la conduite à tenir en cas d'échec

Envoyer un e-mail avec un domaine différent de celui utilisé pour l'authentification rompt cet alignement ; le bloquer protège la réputation de vos domaines et la délivrabilité de vos messages légitimes.

Résoudre le rejet

Solution recommandée — créer une boîte e-mail sur le domaine d'envoi

Créez une boîte e-mail sur le domaine depuis lequel vous souhaitez envoyer, puis authentifiez-vous avec elle. Techniquement, une seule boîte e-mail suffit : une fois créée, elle peut s'authentifier et envoyer depuis n'importe quelle adresse de ce même domaine, l'usurpation au sein d'un même domaine n'étant pas concernée par ce blocage.

Configurez ce domaine sur une offre Zimbra Starter — voir notre guide « Premiers pas avec l'offre Zimbra » — puis créez-y une boîte e-mail.

Warning

L'usurpation au sein d'un même domaine est un risque de sécurité, et elle deviendra bientôt désactivable par l'administrateur du domaine. À l'heure actuelle, n'importe quelle boîte e-mail du domaine peut envoyer en tant que n'importe quelle autre adresse de ce même domaine — un seul jeu d'identifiants expose donc toutes les adresses, sans piste d'audit par adresse. OVHcloud prépare un paramètre permettant aux administrateurs de domaine de désactiver entièrement cette possibilité ; une configuration reposant sur une boîte e-mail partagée usurpant plusieurs adresses cessera de fonctionner une fois celle-ci désactivée. Ne construisez pas votre configuration sur cette base — privilégiez plutôt :

  • Une boîte e-mail par adresse que vous utilisez réellement, ou
  • Une fonctionnalité de délégation permettant d'accorder un accès contrôlé à une boîte e-mail existante sans partager son mot de passe
  • Adresse générique : vous disposez de john.smith@mydomain.ovh sur MX Plan et souhaitez envoyer depuis contact@example.com. Créez une boîte e-mail, par exemple mary.johnson@example.com, sur ce domaine, puis authentifiez-vous avec celle-ci pour envoyer en tant que contact@example.com.
  • Plusieurs entités : votre entreprise gère deux marques, l'une sur mydomain.ovh et l'autre sur example.com. Si vous envoyez actuellement tous vos e-mails depuis une seule boîte sur mydomain.ovh, créez une boîte sur example.com pour la seconde marque.
  • Envoi pour le compte d'un tiers : votre agence envoie des communications pour un client sur example.com depuis votre propre domaine. Créez une boîte sur example.com pour vous authentifier et envoyer avec des adresses de ce domaine.

Solution alternative si vous restez au sein du même domaine

Si toutes vos adresses partagent déjà un seul domaine, ce blocage n'est pas votre cause — vérifiez de nouveau la section « Identifier le problème » ci-dessus, car le rejet provient forcément d'une autre combinaison adresse/domaine que celle que vous attendez. Pour gérer plusieurs identités sur ce domaine unique, utilisez plutôt ces fonctionnalités natives à la place d'une boîte e-mail partagée :

BesoinFonctionnalitéDisponible sur
Envoyer *en tant qu'*une autre adresse du même domaineDroit d'envoiExchange
Envoyer pour le compte de quelqu'un sur le même domaineDroit d'envoyer de la partExchange
Partager l'accès à une boîte e-mail sans partager le mot de passeDroit d'accèsExchange
Envoyer à un groupe de contactsMailing List (MX Plan) ou groupes ExchangeMX Plan, Exchange

Si le problème persiste

Si vous avez ajusté votre configuration et que les messages sont toujours rejetés avec la même erreur 550 5.7.1 :

  • Vérifiez que l'adresse utilisée pour l'authentification correspond bien à l'adresse From réellement utilisée par votre application ou votre appareil d'envoi — un décalage est facile à manquer dans les configurations groupées ou automatisées.
  • Laissez quelques minutes à une boîte e-mail nouvellement créée ou à un changement de configuration pour se propager avant de retester.
  • Contactez le support OVHcloud en fournissant l'intégralité des en-têtes du message rejeté, l'adresse utilisée pour l'authentification, et l'adresse From visée.

Aller plus loin

Pour gérer les alias et redirections d'une adresse existante, consultez le guide « Utiliser les alias et redirections e-mail ».

En savoir plus sur Zimbra Starter.

Pour approfondir les standards sous-jacents, consultez Améliorer la sécurité des e-mails via un enregistrement SPF, Améliorer la sécurité des e-mails via un enregistrement DKIM, et Améliorer la sécurité des e-mails via un enregistrement DMARC.

Échangez avec notre communauté d'utilisateurs.

Cette page vous a-t-elle aidé ?