Pourquoi Microsoft 365 rejette-t-il mon e-mail (erreur 550 5.7.x) ?

Que signifie 550 5.7.1 sur Microsoft 365 ?

550 5.7.1 est le verdict « accès refusé » le plus large de Microsoft : le système de réception a accepté la connexion, mais une politique a bloqué la livraison. Selon les conseils de Microsoft sur l’erreur 5.7.1 (qui couvrent aussi tout de 5.7.0 à 5.7.999), elle « indique généralement qu’un paramètre de sécurité de votre organisation ou de celle du destinataire empêche votre message de l’atteindre ».

En pratique, elle relève de quelques catégories :

• Une restriction de destinataire ou de groupe. La boîte ou la liste de distribution n’accepte que des expéditeurs authentifiés ou internes : un message externe est refusé. Seul l’admin du destinataire peut l’assouplir.
• Une règle de transport (mail flow). Une règle d’un côté ou de l’autre a rejeté votre message.
• Votre IP est sur la liste de blocage Microsoft. Le diagnostic dit Client host [x.x.x.x] blocked using Blocklist 1; To request removal from this list please forward this message to delist@microsoft.com. C’est un problème de réputation, pas de règle : commencez par une vérification du domaine sur les listes de blocage publiques puis voyez le retrait plus bas.
• Un enregistrement SPF ou MX cassé sur votre domaine, cause que Microsoft cite explicitement sur la page 5.7.1.

Le déclencheur varie : le texte de diagnostic est donc l’indice décisif. Ligne de liste de blocage : corrigez la réputation. Ligne RESOLVER.RST.AuthRequired : le destinataire exige une authentification qu’un externe ne peut fournir.

Échecs d’authentification : pourquoi Microsoft renvoie 5.7.23 ou 5.7.509 ?

Parce que Microsoft associe chaque protocole d’authentification à un code : savoir lequel s’est déclenché indique exactement quel enregistrement corriger. 5.7.23 et 5.7.509 sont les plus fréquents.

550 5.7.23 The message was rejected because of Sender Policy Framework violation signifie que le destinataire a vérifié SPF et que votre serveur d’envoi n’était pas autorisé par votre domaine. La référence NDR de Microsoft le décrit ainsi : « le système de destination valide les e-mails entrants avec SPF, et un problème affecte votre configuration SPF ». En général, c’est un nouveau service d’envoi (CRM, outil de ticketing, plateforme marketing) jamais ajouté à votre TXT SPF.

550 5.7.509 Access denied, sending domain does not pass DMARC verification and has a DMARC policy of reject est un rejet DMARC. Votre domaine 5322.From a échoué à DMARC et, comme votre propre politique publiée est p=reject, Microsoft respecte cette instruction et refuse le message. Votre politique fait exactement ce que vous lui avez demandé. Le problème, c’est qu’un flux légitime ne s’authentifie pas. C’est l’équivalent Microsoft du code renvoyé par Gmail (550 5.7.26), et le même mode d’échec que pour les rejets 550 de Gmail.

L’ordre est le même dans les deux cas : identifiez le protocole en échec, corrigez l’enregistrement, puis vérifiez que le domaine qui réussit est aligné sur votre From. Si vous découvrez ces trois protocoles, notre présentation de l’authentification des e-mails pose les bases avant de toucher au DNS.

Comment corriger un rejet d’authentification 550 5.7.x ?

Traitez les trois protocoles dans l’ordre, puis vérifiez l’alignement. Cette séquence résout la grande majorité des rejets 5.7.23 et 5.7.509. Pour 5.7.515, suivez la procédure dédiée aux gros volumes Outlook.com, qui exige en plus que SPF et DKIM réussissent tous les deux.

1. Publiez un SPF complet. Mettez chaque service qui envoie pour votre domaine dans un seul enregistrement TXT SPF. Un seul : Microsoft rejette les domaines à plusieurs enregistrements SPF. Vérifiez qu’il se résout et reste sous la limite de 10 requêtes avec le test SPF de Palisade. Si vous envoyez aussi via Google Workspace, notre guide SPF Google Workspace montre comment les fusionner en un seul enregistrement.
2. Activez la signature DKIM. Activez DKIM sur chaque plateforme d’envoi et publiez la clé publique fournie. Validez la signature avec le test DKIM. DKIM est le plus robuste des deux car, contrairement à SPF, il survit à la plupart des transferts.
3. Publiez une politique DMARC. Ajoutez un enregistrement à _dmarc.yourdomain.com, d’abord v=DMARC1; p=none; rua=mailto:reports@yourdomain.com pour suivre les rapports avant l’application. Vérifiez la syntaxe avec le test DMARC.
4. Vérifiez l’alignement. Le domaine qui réussit SPF ou DKIM doit correspondre à votre domaine From visible. C’est là que se résout presque toujours le cas « tout est configuré mais Microsoft me rejette encore ». Voir la section suivante.
5. Renvoyez et lisez les en-têtes. Envoyez un test à un destinataire Outlook.com ou Microsoft 365, ouvrez la source du message et vérifiez spf=pass, dkim=pass et dmarc=pass pour votre propre domaine.

Utilisez l’outil de requête DNS pour vérifier que chaque enregistrement est bien publié et propagé, et le test MX pour écarter un problème de routage déguisé en problème de politique.

Quand utiliser le guide dédié à 550 5.7.515 ?

Suivez ce guide quand le NDR indique 550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level et que le destinataire est sur Outlook.com, Hotmail, Live.com, MSN ou un autre service grand public de Microsoft. Ce n’est pas une erreur générique de tenant Microsoft 365.

Microsoft exige que SPF et DKIM réussissent tous deux, qu’une politique DMARC valide (p=none, p=quarantine ou p=reject) existe, et que DMARC réussisse car SPF ou DKIM est aligné sur le domaine 5322.From visible. Le guide 550 5.7.515 contient le modèle de preuve par en-têtes, des exemples d’alignement et la procédure de retest sur le même flux ; cette page sert à classer les autres codes 5.7.x.

Pourquoi l’alignement décide-t-il du résultat ?

L’alignement est la règle selon laquelle un SPF ou DKIM réussi doit appartenir au même domaine que celui de votre en-tête From. Sans elle, un spammeur pourrait réussir SPF pour un domaine jetable tout en usurpant votre nom, techniquement authentifié, totalement frauduleux : DMARC refuse donc de compter un succès non aligné.

Deux causes expliquent presque tous les cas « authentifié mais toujours rejeté » :

• SPF authentifie le mauvais domaine. SPF valide le Return-Path caché, que beaucoup de plateformes règlent sur leur domaine, pas le vôtre. SPF réussit pour la plateforme mais n’est pas aligné sur votre From : DMARC ne voit aucun succès aligné.
• DKIM signe avec un autre domaine. Si la balise d= est le domaine de votre fournisseur et non le vôtre, la signature est valide mais non alignée : c’est le piège décrit dans pourquoi votre signature DKIM échoue à l’alignement.

La correction durable : authentifier sur un sous-domaine que vous contrôlez, ce qui garde SPF et DKIM alignés en mode relâché (le défaut de DMARC). Un succès DMARC peut lever 5.7.509 ; 5.7.515 exige en plus des succès SPF et DKIM distincts : suivez le test propre à ce code au lieu de supposer que les deux erreurs disparaissent ensemble.

Problèmes courants avec les rejets Microsoft 365 550 5.7.x

Mon IP est bannie selon le rejet (5.7.511 ou liste de blocage)

550 5.7.511 Access denied, banned sender (et la variante Blocklist 1 de 5.7.1) signifient que Microsoft a banni votre IP d’envoi, généralement après des plaintes pour spam ou un compte compromis. L’authentification seule ne suffira pas. Écrivez à delist@microsoft.com avec le NDR complet et l’adresse IP pour demander le retrait, comme l’indique la référence NDR de Microsoft. Corrigez ensuite la cause, car un retrait ne tiendra pas si le comportement se répète. La page 550 5.7.511 détaille le contenu de cet e-mail et pourquoi le portail en libre-service ne s’applique pas. Inscrire l’IP aux Smart Network Data Services de Microsoft montre les données de plaintes et de pièges qui pèsent sur la réputation, et notre guide pour vérifier et améliorer la réputation d’un domaine couvre le rétablissement.

Un seul service voit ses e-mails rejetés

Si votre plateforme principale livre mais qu’un flux renvoie 5.7.23, ce service manque à votre SPF ou ne signe pas DKIM avec votre domaine. Vos rapports agrégés DMARC nomment chaque source qui envoie en votre nom. Lisez-les, puis ajoutez les expéditeurs légitimes. C’est la cause la plus fréquente d’une correction qui « marche » pour presque tout, sauf un système encore rejeté.

550 5.7.520 bloque un message transféré

550 5.7.520 Access denied, Your organization does not allow external forwarding n’est pas du tout un problème d’authentification. La politique anti-spam sortante de Microsoft bloque par défaut le transfert externe automatique, contre l’exfiltration. Coupez la règle de transfert, ou faites activer le transfert externe par un admin dans cette politique, en sachant que l’activer pour toute l’organisation affaiblit un vrai contrôle de sécurité. Préférez une politique ciblée à une autorisation globale.

Tout s’authentifie mais la livraison reste lente

Réussir l’authentification lève le blocage, pas votre réputation. Si Microsoft vous a limité pendant la panne ou si vos plaintes ont grimpé, les reports s’atténueront sur des jours d’envoi propre, pas instantanément. Si les e-mails sont en file d’attente plutôt que rejetés, notre guide sur la mise en file d’attente explique la différence.

Pour une mise en œuvre de ces contrôles propre à un fournisseur, voir Comment activer DMARC pour Microsoft 365 ?.

À lire aussi

• Pourquoi Gmail rejette-t-il mes e-mails (erreur 550) ?
• Yahoo bloque mes e-mails non authentifiés : pourquoi ?
• E-mail en file d’attente : causes et solutions