Mail refusé par Hotmail ou Outlook.com : erreur 550 5.7.23 et AS9031519

Point de situation au 9 novembre 2026

Nous mettons cette page à jour dès que Microsoft communique.

Les messages d’erreur et ce qu’ils veulent dire

L’expéditeur reçoit un rapport de non-remise (NDR) quelques secondes après l’envoi. Il contient souvent l’une de ces lignes :

550 5.7.23 The message was rejected because of Sender Policy Framework violation
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Le plus utile est souvent caché dans les « détails techniques » du rapport : la ligne complète renvoyée par le serveur et l’adresse IP qui a envoyé le message. Gardez ce rapport, ne le supprimez pas.

Votre domaine ou Microsoft ? Trois contrôles

Depuis un PC Windows, ouvrez l’invite de commandes et remplacez votredomaine.fr par le vôtre :

nslookup -type=txt votredomaine.fr
nslookup -type=txt _dmarc.votredomaine.fr
nslookup -type=cname selector1._domainkey.votredomaine.fr

1. SPF : la première commande doit afficher une seule ligne qui commence par v=spf1. Sur Microsoft 365, elle contient include:spf.protection.outlook.com.
2. DMARC : la deuxième doit afficher une ligne qui commence par v=DMARC1. Si elle ne renvoie rien, votre domaine n’a pas de DMARC : c’est la première chose à corriger.
3. DKIM : sur Microsoft 365, la troisième doit renvoyer une adresse chez Microsoft (se terminant par onmicrosoft.com ou dkim.mail.microsoft). Sinon, DKIM n’est pas activé pour votre domaine.

Pour confirmer, envoyez un mail vers une adresse Gmail et ouvrez « Afficher l’original » : les mentions SPF: PASS, DKIM: PASS et DMARC: PASS doivent apparaître.

SPF, DKIM et DMARC expliqués simplement

Ces trois enregistrements servent à prouver aux messageries que vos mails viennent bien de vous. Gmail et Yahoo les exigent depuis 2024, Outlook.com depuis 2025, au moins pour les expéditeurs qui envoient beaucoup. Sans eux, vos messages finissent en indésirables ou sont refusés.

DMARC : la consigne en cas d’échec. C’est la règle que vous publiez pour dire aux messageries quoi faire d’un mail qui échoue aux contrôles SPF et DKIM : le laisser passer (p=none), le mettre en indésirables (p=quarantine) ou le refuser (p=reject). DMARC vérifie aussi que le domaine contrôlé correspond bien à l’adresse affichée à votre correspondant, et vous envoie des rapports sur qui envoie des mails en votre nom.

Les trois fonctionnent ensemble : SPF et DKIM prouvent l’origine, DMARC dit quoi faire quand la preuve manque. Commencez avec p=none, lisez les rapports quelques semaines, puis durcissez la règle quand tous vos envois légitimes passent.

Les enregistrements à publier

Tout se fait dans la zone DNS de votre nom de domaine, chez le registraire où il est enregistré (IONOS, OVHcloud, Gandi…). Exemples pour un domaine qui envoie ses mails par Microsoft 365 :

SPF : un seul enregistrement TXT, à la racine du domaine

v=spf1 include:spf.protection.outlook.com -all

Ajoutez avant -all chaque service qui envoie en votre nom : copieur qui scanne vers e-mail par un serveur externe, logiciel de facturation, site web, outil de newsletter. Ne créez jamais un deuxième enregistrement SPF : modifiez celui qui existe.

DKIM : deux enregistrements CNAME, puis activation

Dans le portail Microsoft Defender, menu Stratégies et règles > Stratégies de menace > Paramètres d’authentification des e-mails > DKIM, sélectionnez votre domaine. Microsoft affiche les deux CNAME à créer (selector1._domainkey et selector2._domainkey). Créez-les dans votre DNS, puis revenez activer la signature.

DMARC : un enregistrement TXT nommé _dmarc

v=DMARC1; p=none; rua=mailto:dmarc@votredomaine.fr

p=none ne bloque rien : il annonce que vous avez une politique et vous fait recevoir des rapports. Une fois que les rapports montrent que tous vos envois légitimes passent, vous pourrez durcir la politique (quarantine, puis reject).

Une modification DNS est prise en compte selon la durée de vie (TTL) de l’enregistrement : souvent quelques minutes, parfois quelques heures.

Les causes les plus fréquentes

1. Pas de DMARC du tout : c’est le cas le plus touché par l’incident de novembre 2026.
2. Un outil qui envoie sans être déclaré : copieur, logiciel de facturation, site web, outil de newsletter.
3. Deux enregistrements SPF au lieu d’un seul, souvent après un changement d’hébergeur ou de messagerie.
4. Un SPF trop chargé : au-delà de 10 recherches DNS (les « include »), la vérification échoue.
5. DKIM jamais activé dans Microsoft 365 pour votre propre domaine : il ne l’est pas d’office.
6. Un transfert automatique : une règle qui redirige les mails vers une autre adresse peut faire échouer SPF chez le destinataire final.

Un cas réel

Début novembre, dans une PME, un collaborateur envoie un document en pièce jointe à un client dont l’adresse se termine par @hotmail.com. Le message revient aussitôt avec le code 550 5.7.23, alors que les mêmes envois vers d’autres destinataires arrivent sans problème. Nous avons commencé par contrôler l’authentification du domaine expéditeur, exactement comme décrit plus haut : c’est le bon point de départ dans tous les cas.

Vous êtes le destinataire Hotmail ou Outlook.com

Vous ne pouvez rien corriger de votre côté : le refus a lieu avant que le message n’arrive dans votre boîte, il n’est donc pas non plus dans vos courriers indésirables. Prévenez l’expéditeur par un autre moyen, demandez-lui de réessayer et de transmettre le rapport d’erreur à son support informatique.

Questions fréquentes

Pourquoi certains de mes mails passent et d’autres non ?

Depuis le 5 novembre 2026, les refus vers Hotmail et Outlook.com sont intermittents : selon le serveur Microsoft qui traite le message, il peut être accepté ou refusé. Un domaine sans DMARC semble plus exposé.

Mes mails vers Gmail passent, pourquoi pas vers Hotmail ?

Chaque messagerie applique ses propres contrôles. Les boîtes grand public de Microsoft sont actuellement plus strictes, et l’incident en cours ne touche qu’elles.

Faut-il mettre DMARC en p=reject tout de suite ?

Non. Commencez par p=none pour recevoir les rapports sans rien bloquer. Une politique stricte posée trop tôt peut faire refuser vos propres mails légitimes, par exemple ceux d’un copieur ou d’un logiciel oublié dans le SPF.

Le destinataire peut-il débloquer la situation ?

Non. La correction se fait sur le domaine qui envoie. Le destinataire peut seulement prévenir l’expéditeur.

Est-ce que Microsoft a reconnu le problème ?

Pas officiellement au 9 novembre 2026. Un problème en cours sur le service Exchange aurait été évoqué par un modérateur Microsoft, mais aucune cause ni aucun correctif n’ont été publiés. Nous mettrons cette page à jour.

Ce que fait votre support

La correction se fait dans la zone DNS du domaine et dans Microsoft 365, en général à distance. Nous vérifions vos trois enregistrements, nous ajoutons les services oubliés, nous activons DKIM et nous suivons les rapports DMARC. Si votre messagerie est chez nous en maintenance, écrivez à sav@digidoc.fr en joignant le rapport de non-remise.

Sources : Microsoft Learn, « Email non-delivery reports and SMTP errors in Exchange Online » (codes 5.7.23 et 5.7.509) ; Microsoft Tech Community, « Strengthening the email ecosystem: Outlook’s new requirements for high-volume senders » (avril 2025) ; LazyAdmin et Borns IT-Blog (9 novembre 2026) ; Windows Latest (8 novembre 2026).