2026 Outlook.com : comment diagnostiquer l’erreur 550 5.7.515 ? Liste de contrôle de recette pour développeurs

Verdict — adapté si vous envoyez les e-mails de votre propre produit à des boîtes Outlook.com, Hotmail ou Live.com et que le rapport mentionne l’erreur 550 5.7.515 : vérifiez d’abord si les exigences pour les expéditeurs à fort volume s’appliquent à votre domaine, puis contrôlez SPF, DKIM, DMARC et leur alignement. Changer d’adresse de test ne corrige pas une authentification défaillante.

Cette procédure s’adresse aux développeurs qui gèrent le domaine d’envoi et ses enregistrements DNS, aux équipes QA qui valident les flux de préproduction et aux responsables des opérations qui configurent un service d’envoi tiers. Elle concerne les messages de votre propre produit, pas l’inscription automatisée à des services externes.

Dernière mise à jour : 22 octobre 2026. Vérification effectuée à partir des pages d’assistance et des exigences officielles de Microsoft citées ci-dessous.

Commencez par localiser le rejet dans la chaîne d’envoi

L’erreur 550 5.7.515 est une réponse de refus associée par Microsoft à des exigences d’authentification pour les expéditeurs à fort volume vers ses services de messagerie grand public. Elle ne signifie pas simplement que le message a été classé comme indésirable. Elle ne permet pas non plus de conclure que toute adresse Outlook.com rejette les e-mails de votre application.

La première preuve à conserver est le rapport de non-remise complet, souvent appelé NDR. Notez la réponse SMTP, le serveur destinataire indiqué, l’adresse d’expédition et le domaine que le message ou le rapport identifie comme problématique. La fiche d’assistance Microsoft consacrée au code 550 5.7.515 décrit ce rejet et les vérifications d’authentification à effectuer.

Distinguez trois situations, car elles ne se corrigent pas de la même façon :

Cette séparation évite une erreur de dépannage fréquente : modifier le filtrage côté destinataire alors que la connexion a déjà été refusée, ou modifier les DNS lorsque le message a été accepté mais déplacé après livraison.

Vérifiez si la règle de fort volume concerne votre domaine

Ne déduisez pas l’applicabilité de la règle du seul fait que le destinataire utilise Outlook.com. Selon l’explication officielle de Microsoft, la catégorie des expéditeurs à fort volume vise les domaines qui envoient plus de 5 000 messages par jour vers des adresses de messagerie grand public Microsoft. Le périmètre et les modalités doivent être relus dans la publication Microsoft sur les nouvelles exigences pour les expéditeurs à fort volume, qui fait foi pour la politique telle qu’elle est présentée par Microsoft.

Le seuil porte sur les messages envoyés vers les destinataires concernés, et non sur le volume total de votre application tous domaines et toutes plateformes confondus. Examinez les données correspondant au domaine d’envoi mis en cause et à la période pertinente. Si vous ne pouvez pas établir ce périmètre, consignez l’incertitude au lieu d’affirmer que votre compte est ou n’est pas soumis à ces exigences.

La règle opérationnelle est donc simple : établissez le destinataire, le domaine visible et le contenu exact du rejet avant de toucher à la configuration. Si l’erreur nomme un domaine de votre organisation, comparez-le au domaine réellement utilisé par le service d’envoi. Un domaine de test, un sous-domaine de préproduction et le domaine de production peuvent avoir des enregistrements différents.

Lisez les résultats SPF, DKIM et DMARC ensemble

La présence d’un enregistrement DNS n’équivaut pas à une authentification réussie. De même, un résultat SPF ou DKIM positif n’établit pas automatiquement l’alignement DMARC. Les mécanismes répondent à des questions différentes, comme le rappelle la documentation Microsoft sur l’authentification des e-mails.

Les noms 5321.MailFrom et 5322.From correspondent à des éléments différents du message : le premier est lié à l’expéditeur de l’enveloppe SMTP ; le second est le champ d’expéditeur présenté dans l’en-tête du message. Pour comprendre comment Microsoft présente et interprète les en-têtes, consultez sa documentation sur les en-têtes de message.

DMARC compare le domaine du champ visible From avec les domaines authentifiés par SPF ou DKIM. L’alignement peut être évalué en mode relâché ou strict selon la politique DMARC publiée. La spécification DMARC de l’IETF, RFC 9989, décrit le protocole et ses règles d’alignement. Dans votre diagnostic, ne vous contentez donc pas d’une ligne « SPF pass » ou « DKIM pass » : vérifiez quel domaine a passé le contrôle et s’il s’aligne sur celui que voit le destinataire.

Repérez la rupture dans une configuration tierce

Quand votre produit délègue l’envoi à un prestataire, l’interface du service peut afficher « authentifié » ou « configuration valide » sans que cela suffise à expliquer le résultat obtenu par Outlook.com. Le service peut signer avec son domaine par défaut, employer une adresse d’enveloppe distincte ou ne pas avoir reçu l’autorisation de signer pour votre domaine.

Comparez les valeurs observées plutôt que les libellés de l’interface :

• Domaine du champ From : c’est le domaine que vos destinataires voient. Il doit correspondre à votre intention d’envoi et à la politique DMARC.
• Domaine de 5321.MailFrom : contrôlez le domaine qui intervient dans la validation SPF. Il peut différer du domaine visible, notamment lorsque l’envoi est délégué.
• Domaine DKIM (d=) : vérifiez que le domaine de signature est celui que vous avez configuré ou qu’il est aligné avec le domaine visible selon la politique applicable.
• Enregistrements publiés : confirmez qu’ils correspondent au bon domaine et au bon environnement. Une entrée créée pour la production ne configure pas automatiquement un sous-domaine de test.
• Rapport reçu : confrontez le résultat d’authentification du destinataire aux valeurs que votre fournisseur affirme utiliser.

Une incohérence typique est un message visible comme provenant de notifications.exemple alors que SPF s’applique à un domaine d’enveloppe du prestataire et que DKIM signe avec un domaine appartenant à ce dernier. SPF peut réussir pour l’enveloppe et DKIM pour la signature, mais aucun des domaines authentifiés ne s’aligne nécessairement avec le champ From. Dans ce cas, l’action n’est pas de répéter la même validation dans le tableau de bord : vérifiez l’autorisation DNS, le domaine de retour et la signature configurés pour votre propre domaine.

Appliquez cette liste de contrôle avant la recette

Cochez chaque point et conservez les éléments de preuve. Si une valeur est inconnue, marquez-la comme non vérifiée plutôt que de la traiter comme valide.

• [ ] J’ai conservé le rapport de non-remise complet, avec le code SMTP et le texte explicatif.
• [ ] J’ai confirmé que le destinataire appartient bien à Outlook.com, Hotmail ou Live.com et relevé le serveur qui a renvoyé le rejet.
• [ ] J’ai identifié le domaine exact du champ visible From dans l’e-mail concerné.
• [ ] J’ai vérifié si les envois vers les boîtes grand public Microsoft entrent dans le périmètre des exigences de fort volume décrit par Microsoft.
• [ ] J’ai contrôlé le résultat SPF et le domaine d’enveloppe auquel ce résultat se rapporte.
• [ ] J’ai contrôlé le résultat DKIM et la valeur d= de la signature.
• [ ] J’ai comparé les domaines authentifiés par SPF et DKIM avec le domaine du champ From, selon la politique d’alignement DMARC.
• [ ] J’ai demandé au service d’envoi tiers de confirmer les domaines réellement utilisés, puis comparé sa réponse aux en-têtes ou journaux disponibles.
• [ ] J’ai appliqué les corrections DNS ou de configuration à l’environnement concerné et vérifié leur publication avant le nouvel essai.
• [ ] J’ai prévu de conserver les résultats du nouvel essai, y compris en cas d’échec, au lieu de conclure à partir d’un simple statut « envoyé ».

Cette liste porte sur la configuration de votre propre produit. Elle ne doit pas servir à créer des comptes en série sur des services tiers. Pour éviter d’exposer des données personnelles dans les essais, utilisez des identités de test contrôlées et limitez les données des messages au strict nécessaire.

Recette après correction : vérifiez la livraison, pas seulement l’envoi

Une correction n’est vérifiée que si vous observez le résultat côté destinataire et que vous pouvez le rapprocher des traces côté expéditeur. Un statut « envoyé » dans l’application indique souvent que le message a été remis au service d’envoi, pas que le serveur destinataire l’a accepté ni qu’il a rejoint la boîte de réception.

Procédez ainsi dans votre environnement de test ou de préproduction :

• Préparez un scénario reproductible. Utilisez le même flux fonctionnel qui a généré le rejet : inscription, réinitialisation de mot de passe ou notification de votre produit. Notez l’adresse de test, l’environnement, le modèle de message et le domaine d’expédition.
• Déclenchez un envoi après la correction. Ne réutilisez pas un ancien message ou un ancien rapport comme preuve de la nouvelle configuration. Enregistrez l’heure et l’identifiant de suivi fournis par votre système, s’ils existent.
• Conservez la réponse SMTP et les journaux. Recherchez une nouvelle réponse 550 5.7.515 ou un autre échec, puis rapprochez-la du rapport de non-remise et des événements du service d’envoi.
• Inspectez les en-têtes du message reçu. Si le message arrive, relevez les résultats SPF, DKIM et DMARC, les domaines associés et les indicateurs d’alignement. La documentation Microsoft sur les en-têtes explique comment les consulter.
• Notez le résultat réel. Distinguez « refusé », « accepté mais absent de la boîte principale », « présent dans les indésirables » et « reçu dans la boîte ». Ces résultats n’ont pas la même signification.
• Recommencez si le premier résultat contredit la configuration attendue. Un message reçu ne prouve pas à lui seul que tous les domaines, toutes les routes d’envoi et tous les destinataires ont le même comportement.

Un outil de réception temporaire peut être utile pour vérifier le contenu réel d’un message de test sans exposer votre adresse personnelle. Il ne corrige pas SPF, DKIM ou DMARC et ne remplace pas un destinataire Outlook.com contrôlé lorsque vous cherchez à reproduire précisément ce rejet. Si le message est refusé avant livraison, un changement de boîte de test ne fera pas disparaître le refus.

FAQ : interpréter le code et valider le correctif

Que révèle réellement le code 550 5.7.515 ?

Ce code renvoie au refus décrit par Microsoft pour des domaines qui ne satisfont pas les exigences d’authentification appliquées aux expéditeurs à fort volume. Il ne faut pas le transformer en règle générale applicable à tous les expéditeurs Outlook.com. Confirmez le périmètre avec le domaine concerné, le type de destinataire et le rapport complet, puis contrôlez les résultats d’authentification.

Comment distinguer un rejet SMTP d’un classement en indésirables ?

Un rejet apparaît dans la réponse SMTP ou dans un rapport de non-remise, qui peut contenir le code 550 5.7.515. Un message classé comme indésirable a été accepté pour livraison, même s’il n’est pas visible dans la boîte principale. Pour trancher, confrontez les journaux de votre service d’envoi, le NDR éventuel et les dossiers du compte de test.

Pourquoi une authentification réussie ne garantit-elle pas l’alignement DMARC ?

SPF valide le domaine lié à l’enveloppe SMTP ; DKIM valide une signature associée à son domaine d=. DMARC vérifie ensuite l’alignement de l’un de ces domaines authentifiés avec le domaine visible dans 5322.From. Un résultat positif isolé peut donc coexister avec un échec d’alignement, notamment lorsque le service tiers utilise ses propres domaines.

Quelle preuve recueillir après la modification des DNS ?

Envoyez un nouveau message depuis l’environnement concerné vers une boîte de test que vous contrôlez. Archivez la réponse SMTP ou l’absence de rejet, le rapport de non-remise s’il existe et les en-têtes du message reçu. Vérifiez les résultats SPF, DKIM, DMARC et les domaines correspondants. Consignez séparément ce qui a été corrigé, ce qui a été observé et ce qui reste à confirmer.

Élargissez les essais selon les éléments observés

Après une réception réussie, décidez de la suite à partir des preuves, pas d’une impression générale. Si le message arrive et que les en-têtes montrent les résultats attendus pour le domaine testé, consignez ce scénario comme validé. Si l’erreur réapparaît, comparez le nouveau rapport avec l’ancien : domaine mentionné, route d’envoi, résultat SPF, signature DKIM et alignement DMARC.

Élargissez la régression lorsque le domaine ou le chemin d’envoi diffère, lorsqu’un autre modèle utilise une adresse From distincte ou lorsque la configuration de préproduction n’est pas identique à celle de production. En revanche, ne présentez pas la réussite d’un seul essai comme une garantie générale de livraison. La décision doit rester bornée à l’environnement, au domaine et au destinataire effectivement testés.

Dans votre compte rendu, séparez trois catégories : les changements appliqués, les preuves collectées après ces changements et les questions encore ouvertes. Cette distinction aide l’équipe à éviter de réintroduire une configuration non validée et permet aux opérations de reprendre le diagnostic sans confondre une livraison retardée, un classement en indésirables et un rejet SMTP.

Une fois l’authentification de votre domaine correctement configurée, vous pouvez utiliser EmailPut comme boîte de réception temporaire pour examiner le contenu des messages de test sans communiquer votre adresse principale à chaque outil de préproduction. C’est une option pour vérifier ce qui arrive réellement ; elle ne répare pas la configuration d’envoi et ne garantit pas l’acceptation par Outlook.com.

Questions fréquentes

Que signifie une réponse 550 5.7.515 dans le contexte d’Outlook.com ?

Elle indique que le domaine d’envoi ne satisfait pas les exigences d’authentification appliquées par Microsoft aux expéditeurs à fort volume. Ce code ne prouve pas, à lui seul, que tout expéditeur est concerné par cette règle : vérifiez la portée applicable, le domaine mentionné dans le rejet et les résultats d’authentification avant de modifier votre configuration.

Comment savoir si le message a été refusé ou placé dans les indésirables ?

Un refus est signalé par une réponse SMTP négative et généralement par un rapport de non-remise contenant le code 550 5.7.515. Un message classé comme indésirable a, au contraire, été accepté pour livraison, même s’il n’apparaît pas dans la boîte de réception principale. Consultez le rapport et les journaux du service d’envoi.

Pourquoi DMARC échoue-t-il alors que SPF ou DKIM semble valide ?

Un résultat SPF ou DKIM positif ne suffit pas à établir l’alignement DMARC. DMARC compare le domaine visible dans l’en-tête From avec le domaine authentifié par SPF ou avec le domaine de signature DKIM. Un service tiers peut donc réussir son propre contrôle sans authentifier le domaine présenté à vos destinataires.

Comment confirmer qu’une correction a résolu le rejet pour mes e-mails de test ?

Envoyez un nouveau message de votre environnement de test vers une boîte Outlook.com que vous contrôlez. Conservez les journaux SMTP, le rapport de non-remise éventuel et les en-têtes reçus, puis vérifiez les résultats SPF, DKIM et DMARC ainsi que leur alignement. Une réception réussie confirme ce scénario, mais ne garantit pas la livraison dans tous les environnements.