Microsoft 550 5.7.1 : le message ne contient pas d'enregistrements d'authentification SPF, DKIM ou DMARC (AS9031519)

Depuis le 5 novembre 2026, les opérateurs de messagerie et les utilisateurs signalent que certains messages destinés aux boîtes de réception Microsoft sont rejetés en raison d'une erreur liée à l'authentification, y compris ceux provenant d'expéditeurs à faible volume d'envoi. Certains opérateurs ont attribué ces échecs à l'absence d'enregistrements DMARC, mais ces signalements ne permettent pas de conclure à la mise en place d'une nouvelle politique générale de la part de Microsoft. 

Remarque: Le comportement signalé concerne les services de messagerie grand public de Microsoft ; aucune modification générale n’a été mise en place pour les destinataires professionnels de Microsoft 365.

Le motif de rejet est le suivant :

550 5.7.1 Message rejeté : le message ne contient pas d'enregistrements d'authentification SPF/DKIM/DMARC (AS9031519)

Si vous avez reçu ce message de rejet, la première chose à faire est de vérifier si le domaine figurant dans votre adresse « De » visible dispose d'un enregistrement DMARC valide.

Ce guide explique la signification de cette erreur, comment l'analyser et comment procéder si DMARC est déjà configuré sur votre domaine.

Comment résoudre l'erreur DMARC 550 5.7.1 de Microsoft

Si vous recevez le message d'erreur AS9031519, suivez ces étapes de dépannage avant d'apporter des modifications à votre configuration actuelle d'authentification des e-mails.

1. Vérifiez l'enregistrement DMARC de votre domaine

Commencez par vérifier le domaine figurant dans l'adresse « De » visible de l'e-mail rejeté. Il s'agit du domaine que les destinataires voient lorsqu'ils reçoivent votre message.

Utilisez PowerDMARC vérificateur DMARC de PowerDMARC pour rechercher son enregistrement DMARC et vérifier si celui-ci existe, si sa syntaxe est valide et s'il définit une politique efficace.

Si aucun enregistrement DMARC valide n'est détecté, vous devrez peut-être en publier un.

N'oubliez pas que le fait de voir un enregistrement TXT commençant par « v=DMARC1 » ne signifie pas automatiquement que votre configuration DMARC est valide. L'enregistrement doit également respecter une politique et une syntaxe valides.

2. Publier un enregistrement DMARC s'il n'y en a pas

Si votre domaine ne dispose pas encore d'une politique DMARC, vous pouvez en créer une à l'aide du générateur d'enregistrements DMARC.

Pour commencer par une simple surveillance, utilisez un enregistrement similaire à celui-ci :

Hôte/Nom : _dmarc
Type : TXT
Valeur : v=DMARC1; p=none; rua=mailto:[email protected]

Voici la signification de chaque élément :

• v=DMARC1 indique que l'enregistrement correspond à une politique DMARC.
• La valeur « p=none » indique aux serveurs destinataires de ne pas appliquer de politique DMARC d'quarantine ou de rejet aux messages qui ne respectent pas les règles DMARC.
• rua indique l'adresse e-mail qui reçoit les rapports DMARC agrégés.

Points importants à prendre en compte concernant le DNS :

• Remplacez « example.com » et « [email protected] » par votre domaine et votre adresse de rapport réels. La boîte mail de rapport doit exister ; sinon, vous devez utiliser l'adresse et suivre les instructions de configuration fournies par votre service de surveillance DMARC.
• Publiez l'enregistrement dans _dmarc pour le domaine concerné. Certains fournisseurs DNS ajoutent automatiquement votre nom de domaine ; vérifiez donc l'interface avant de saisir le nom d'hôte.
• Si un enregistrement DMARC existe déjà, ne le remplacez pas et ne publiez pas de doublon. Un domaine ne doit comporter qu'un seul enregistrement de politique DMARC valide sous le nom DNS correspondant.

Une fois la mise à jour effectuée, vérifiez le résultat DNS public à l'aide d'un outil de vérification DMARC après l'actualisation des caches DNS. Envoyez ensuite un nouvel e-mail de test au destinataire Microsoft concerné. Il se peut que vous deviez renvoyer les messages précédemment rejetés.

Remarque: La publication de DMARC peut résoudre le problème d'enregistrements manquants identifié dans certains cas signalés, mais elle ne garantit pas la livraison ni ne résout toutes les causes possibles de ce rejet.

3. Vérifier l'authentification et l'alignement « SPF » et DKIM

La publication des enregistrements DMARC ne constitue qu'une partie du processus d'authentification des e-mails. Vous devez également vous assurer que vos services d'envoi légitimes authentifient correctement les messages.

Les exigences publiées par Microsoft concernant les expéditeurs à fort volume précisent que les protocoles SPF et DKIM doivent tous deux être validés. Pour que le DMARC soit validé, au moins l'un de ces mécanismes doit également correspondre au domaine figurant dans l'adresse « De » visible.

Vérifiez les points suivants :

• SPF: Vérifiez que l'adresse IP d'envoi est autorisée par l'enregistrement « SPF » du domaine de l'expéditeur de l'enveloppe. Pour la conformité DMARC, ce domaine doit correspondre au domaine « From » visible.
• DKIM : assurez-vous que les messages sortants sont signés à l'aide d'une signature DKIM valide. Le domaine de signature (d=) doit correspondre au domaine « De » visible pour que DKIM contribue à la réussite du test DMARC.
• Microsoft 365 DKIM : si vous utilisez Microsoft 365 avec un domaine personnalisé, activez la signature DKIM pour ce domaine plutôt que de vous fier exclusivement au domaine de signature par défaut de Microsoft.
• Expéditeurs tiers : vérifiez tous les services qui envoient des e-mails en votre nom, notamment les plateformes marketing, les CRM, les fournisseurs d'e-mails transactionnels et les autres applications externes.

N'oubliez pas que la simple publication d'enregistrements SPF et DKIM ne suffit pas à prouver que vos messages passent l'authentification. Vous devez examiner les résultats réels de l'authentification pour les messages envoyés via chaque service.

4. Surveiller les rapports DMARC pour détecter les échecs d'authentification

Après avoir publié ou validé votre enregistrement DMARC, consultez les rapports globaux pour comprendre comment les différentes sources d'envoi authentifient vos e-mails.

Ces rapports vous aident à identifier :

• Sources d'envoi légitimes qui satisfont ou ne satisfont pas aux critères « SPF » et DKIM.
• Problèmes d'alignement affectant l'authentification DMARC.
• Des sources non autorisées tentent d'envoyer des e-mails en utilisant votre domaine.
• Problèmes d'authentification susceptibles d'affecter la livraison des e-mails.

Une plateforme de surveillance DMARC telle que PowerDMARC permet de regrouper ces rapports dans un tableau de bord clair, ce qui facilite l'analyse des échecs d'authentification sur plusieurs domaines et services d'envoi.

Une politique de surveillance n'est pas synonyme de protection

Pour les expéditeurs confrontés au rejet signalé par Microsoft, la publication d'un enregistrement DMARC avec p=none peut aider à résoudre le problème immédiat. Mais considérer cela comme la fin du processus laisse d'importantes failles dans la sécurité de votre domaine.

A p=none indique aux serveurs de messagerie destinataires de surveiller les résultats DMARC sans prendre de mesures coercitives à l'encontre des messages non conformes. Elle établit une politique DMARC, mais elle n’empêche pas les messages non authentifiés d’atteindre leurs destinataires. Et à moins que l'enregistrement ne comporte un champ rua correctement configurée, vous risquez de ne disposer que de peu d'informations sur la manière dont votre domaine est utilisé.

Cette visibilité est essentielle. Sans analyser les rapports DMARC, vous ne pouvez pas identifier de manière fiable tous les services qui envoient des e-mails en votre nom, détecter les échecs d'authentification et d'alignement, ni distinguer le trafic légitime d'une éventuelle utilisation abusive de votre domaine.

Voici ce que les organisations risquent de négliger lorsqu’elles s’arrêtent à p=none:

• Sources d'envoi non identifiées : Vous ne savez peut-être pas quelles plateformes, applications ou services tiers utilisent votre domaine pour envoyer des e-mails.
• Exposition continue à l'usurpation d'identité : Une politique de surveillance uniquement n'impose pas aux destinataires d'quarantine r ou de rejeter les messages non conformes à DMARC.
• Lacunes en matière d'authentification : La présence d'enregistrements SPF et DKIM ne garantit pas automatiquement la conformité à DMARC. Au moins un de ces mécanismes doit être valide et correspondre au domaine visible dans le champ « De ».
• Aucune avancée en matière d'application : Sans examen des rapports ni correction des problèmes légitimes liés à la source d'envoi, il n'existe aucune base claire permettant de passer à une politique DMARC plus stricte.

Dans la pratique, on utilise p=none comme phase de surveillance. Examinez les résultats, autorisez les sources d'envoi légitimes, résolvez les problèmes d'alignement, puis passez à p=quarantine ou p=reject.

L'objectif ne doit pas se limiter à publier un rapport conforme à un contrôle de livraison déclaré. Il doit consister à comprendre, gérer et protéger chaque service envoyant des e-mails au nom de votre domaine.

Que faire si votre domaine dispose déjà d'un enregistrement DMARC ?

L'absence d'enregistrement DMARC n'explique pas tous les rejets signalés sous la référence AS9031519. Les discussions sur le forum Q&A de Microsoft font état d'échecs intermittents, notamment dans des cas où les expéditeurs affirment que les paramètres « SPF », DKIM et DMARC sont déjà correctement configurés.

Si votre domaine dispose déjà d'un enregistrement DMARC, cherchez à comprendre les raisons de ce rejet total plutôt que de publier un nouvel enregistrement ou de modifier votre politique actuelle.

Vérifiez les points suivants :

1. Consultez l'intégralité du message de rejet : recherchez le diagnostic complet, y compris le numéro AS9031519, l'hôte destinataire et l'horodatage.
2. Vérifiez l'enregistrement DNS public : assurez-vous que l'enregistrement DMARC est valide et publié sous le nom DNS correct. Vérifiez également qu'il n'y a pas d'enregistrements en double ni d'erreurs de syntaxe.
3. Identifier la source d'envoi : déterminer si l'e-mail rejeté provenait de Microsoft 365, de Google Workspace, d'une plateforme marketing, d'un CRM ou d'un autre service.
4. Vérifiez les résultats réels de l'authentification : examinez les résultats relatifs à l'SPF, au DKIM et au DMARC pour les messages envoyés via le service concerné. Assurez-vous qu'au moins un de ces mécanismes, dont le résultat est positif, correspond au domaine « De » visible.
5. Comparez attentivement les tentatives réussies et celles qui ont échoué : un message de comparaison remis avec succès peut vous aider à analyser votre configuration, mais ses en-têtes ne permettent pas de déterminer ce qui est arrivé à un message rejeté séparément.

Si le problème persiste, contactez votre fournisseur de messagerie ou le service d'assistance aux expéditeurs de Microsoft. Joignez le rapport de diagnostic complet, l'horodatage UTC, l'hôte destinataire et les journaux d'envoi pertinents. Masquez les informations sensibles avant de partager les journaux publiquement.

Les rapports de rejet sporadiques laissent penser que le problème pourrait ne pas se limiter à l'absence d'enregistrements DMARC. Évitez de supposer que chaque incident a la même cause sous-jacente.

Pourquoi Microsoft rejette-t-il certains e-mails dépourvus de DMARC ?

Les rapports de novembre 2026 ont mis en évidence un éventuel changement dans la manière dont l'infrastructure de messagerie grand public de Microsoft évalue les enregistrements d'authentification.

Pour bien comprendre cette distinction, il est important de faire la distinction entre le comportement de l'AS9031519 récemment signalé et les exigences relatives aux expéditeurs à fort volume publiées précédemment par Microsoft.

Exigences publiées par Microsoft en matière d'authentification des e-mails à haut volume

Le 2 avril 2025, Microsoft a annoncé un renforcement exigences d'authentification des e-mails pour les expéditeurs à fort volume utilisant ses services de messagerie grand public.

Ces exigences sont entrées en vigueur le 5 mai 2025 et s’appliquent aux domaines envoyant plus de 5 000 e-mails par jour vers Outlook.com, Hotmail, Live.com et les adresses grand public associées. La documentation d’assistance de Microsoft précise que le seuil correspond à 5 000 messages ou plus dont l’adresse d’expéditeur visible correspond au même domaine.

Conformément à ces exigences publiées, les expéditeurs à fort volume doivent :

• Publiez des enregistrements SPF et DKIM valides, en veillant à ce que les deux contrôles d'authentification soient réussis.
• Publiez un enregistrement DMARC valide, qui peut initialement utiliser un p=none .
• Assurez-vous qu'au moins un mécanisme de validation ( SPF ou DKIM) corresponde au domaine « De » visible afin que DMARC soit validé.

Les expéditeurs qui ne respectent pas ces exigences peuvent faire l'objet d'un rejet distinct :

550 5.7.515 Accès refusé : le domaine expéditeur ne répond pas au niveau d'authentification requis.

Ce cas est différent de celui portant le numéro AS9031519. Le premier est lié aux exigences publiées par Microsoft concernant les expéditeurs à fort volume, tandis que le second correspond au refus lié à l'authentification signalé par les opérateurs en novembre 2026.

Que nous révèlent les rapports de novembre 2026 ?

Les derniers rapports font état de rejets touchant certains expéditeurs dont le volume d'envoi ne dépasse pas le seuil précédemment publié.

Des chercheurs spécialisés dans la délivrabilité des e-mails ont recensé le diagnostic AS9031519 dans leurs propres observations sur le courrier sortant le 6 novembre 2026. Parmi les cas étudiés figuraient des domaines dépourvus d'enregistrements DMARC, même lorsque les protocoles SPF et DKIM étaient déjà configurés. Il a également été signalé que le rejet était intermittent, certains messages provenant du même domaine étant acceptés.

Des utilisateurs particuliers et des administrateurs de messagerie ont également signalé ce problème dans les forums de discussion Microsoft Q&A. Parmi ces cas, on trouve notamment des situations où des expéditeurs utilisant Microsoft 365 envoient des e-mails à des destinataires Outlook.com ou Hotmail, ainsi que des signalements de messages rejetés de manière intermittente.

Les rapports disponibles indiquent que :

• Certains expéditeurs à faible volume ont vu leurs messages rejetés.
• Des enregistrements DMARC manquants ont été identifiés dans plusieurs affaires faisant l'objet d'une enquête.
• Certains domaines concernés avaient déjà configuré les protocoles SPF et DKIM.
• La publication d'un enregistrement DMARC valide aurait permis de résoudre certains cas.
• Tous les messages ne sont pas rejetés, et des défaillances intermittentes ont également été signalées.

Microsoft n'a pas confirmé publiquement l'extension généralisée de ses exigences DMARC à l'ensemble des expéditeurs. Les rapports de novembre doivent donc être considérés comme des observations de comportement, et non comme la preuve d'une nouvelle politique s'appliquant à tous les expéditeurs à faible volume.

Pour les organisations, la solution concrète consiste à vérifier leur configuration d'authentification, à analyser en détail chaque rejet et à suivre l'évolution de la situation, plutôt que de partir du principe que tous les rejets ont la même cause.

Que signifie réellement l'erreur 550 5.7.1 ?

Le code d'état SMTP 550 5.7.1 est un code de rejet général indiquant qu'un message a été refusé en raison d'un problème lié à l'autorisation ou à la politique de sécurité. Cela peut avoir plusieurs causes, notamment des enregistrements « SPF » incomplets, des configurations de connecteurs incorrectes ou les politiques de sécurité du serveur de réception.

Dans ce cas précis, le message de diagnostic signale un refus lié à l'authentification :

Le message ne contient pas d'enregistrements d'authentification SPF, DKIM ou DMARC (AS9031519)

Ce diagnostic est plus précis que le code d'état SMTP général. Il met en évidence un problème d'authentification signalé par l'infrastructure de messagerie grand public de Microsoft, bien que les rapports disponibles ne permettent pas d'établir qu'un enregistrement DMARC manquant soit à l'origine de tous les cas observés.

Cette distinction est importante, car le fait de chercher à résoudre un problème au niveau d'un mécanisme d'authentification inapproprié peut entraîner une perte de temps et empêcher de résoudre le problème de diffusion sous-jacent.

Foire aux questions

1. Est-ce que « p=none » suffit, ou dois-je indiquer « p=reject » ?

Une politique « p=none » constitue un point de départ acceptable lors de la mise en œuvre initiale de DMARC. Cependant, s'en tenir à une politique de surveillance uniquement expose votre domaine à des menaces d'usurpation d'identité et de falsification. L'application de DMARC est le seul moyen d'empêcher les attaquants d'envoyer des e-mails depuis votre propre domaine. 

Veillez à mettre à jour votre politique en la définissant sur « p=quarantine », puis sur « p=reject » une fois que vous aurez vérifié toutes vos sources d'envoi légitimes et résolu les problèmes d'alignement.

2. Comment puis-je vérifier que mon nouvel enregistrement DMARC est visible ?

Utilisez un outil de recherche DMARC pour consulter les enregistrements DNS publics de votre domaine.

Vérifiez que l'enregistrement apparaît sous le nom d'hôte _dmarc correct et que sa syntaxe et sa politique sont valides. Une fois que les caches DNS se sont actualisés, envoyez un nouvel e-mail de test au destinataire Microsoft concerné afin de vérifier si la livraison s'est améliorée.

3. Le destinataire peut-il corriger cette erreur lui-même ?

En règle générale, non. Le protocole DMARC est configuré dans le DNS du domaine expéditeur ; c'est donc au propriétaire du domaine ou à l'administrateur de messagerie qu'il revient d'examiner la situation et d'apporter les modifications nécessaires.

Si vous recevez un message rejeté, contactez l'expéditeur et transmettez-lui l'intégralité du message de rejet. Son administrateur de messagerie pourra alors vérifier les enregistrements d'authentification du domaine d'origine et enquêter sur les raisons de ce rejet.

Si l'expéditeur confirme que son authentification est correctement configurée mais que le problème persiste, il se peut que son fournisseur de messagerie ou Microsoft doive se pencher sur la question.

Comment PowerDMARC vous aide à analyser les rejets d'e-mails Microsoft

La gestion de l'authentification des e-mails sur plusieurs domaines et services d'envoi nécessite une surveillance continue. PowerDMARC aide les entreprises à vérifier leurs configurations d'authentification, à analyser les défaillances et à suivre leurs progrès en matière de mise en œuvre du protocole DMARC.

Avec PowerDMARC, vous pouvez :

• Vérifier l'authentification des e-mails : validez les enregistrements DMARC et surveillez les résultats d'authentification SPF, DKIM et DMARC sur l'ensemble de vos domaines.
• Analyser les échecs d'authentification : utilisez les rapports consolidés et les analyses d'authentification pour identifier les sources d'envoi problématiques, les problèmes d'alignement et les activités non autorisées.
• Suivre les progrès en matière d'application : surveillez votre politique DMARC, consultez les rapports agrégés et évoluez vers les paramètres « p=quarantine » ou « p=reject » en bénéficiant d'une meilleure visibilité sur votre écosystème de messagerie.

Commencez votre essai gratuit de 15 jours de PowerDMARC et bénéficiez d'une meilleure visibilité sur l'authentification de vos e-mails, la sécurité de votre domaine et la délivrabilité de vos messages.