Depuis début novembre 2026, des centaines d’administrateurs système signalent des rejets d’e-mails vers les adresses Microsoft grand public. Le point commun : l’absence d’un enregistrement DMARC. Microsoft, lui, n’a rien dit.
Un problème sans annonce
Le 4 novembre 2026, les premiers signalements apparaissent sur le forum Microsoft Q&A, puis sur Reddit (r/microsoft365, r/sysadmin) et la liste mailop. Des administrateurs constatent que leurs e-mails vers outlook.com, hotmail.com, live.com et msn.com sont rejetés avec le message : « 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records ».
Ce code d’erreur ne correspond à aucune règle publiée par Microsoft. La seule exigence documentée en matière de DMARC pour les services grand public date d’avril 2025 : depuis le 5 mai 2025, les domaines envoyant plus de 5 000 messages par jour doivent passer SPF, DKIM et publier un enregistrement DMARC d’au moins p=none. Le code associé est 550 5.7.515 — un autre, donc.
Le 5 novembre, le fournisseur de messagerie MailRoute confirme observer ces rejets dans ses logs d’envoi. Neil Jenkins, directeur produit de Fastmail, signale des cas similaires pour ses clients.
Des petites structures touchées
C’est là que le problème sort du cadre des gros expéditeurs. Plusieurs cas documentés concernent des domaines envoyant très peu de messages : une entreprise d’une cinquantaine d’employés incapable d’envoyer un e-mail à une adresse Outlook personnelle, un bureau de deux personnes dont un simple message de réponse rebondit, des clients de MSP (prestataires de services managés) qui n’ont jamais atteint le seuil des 5 000 envois quotidiens.
Le seuil officiel ne semble donc plus être un critère dans le comportement observé.
Un comportement incohérent
Les rapports décrivent une situation instable. Plusieurs administrateurs constatent que des messages envoyés à deux minutes d’intervalle, depuis la même boîte, avec la même configuration, sont tantôt livrés, tantôt rejetés.
Certains domaines disposant d’une authentification SPF, DKIM et DMARC complète ont également été touchés de manière intermittente. Un message envoyé via Zoho a été rejeté, puis livré lors d’un renvoi 19 minutes plus tard. Ce caractère aléatoire complique toute interprétation définitive.
Ce que Microsoft dit, et ne dit pas
À la date de rédaction de cet article, Microsoft n’a publié aucune annonce de changement de politique, aucune note sur son portail Postmaster, aucune entrée dans son tableau de bord de santé des services, aucun billet de blog.
Un modérateur externe du forum Microsoft a qualifié la situation de « service degradation » en cours d’investigation active. C’est la seule réponse officielle obtenue par les personnes affectées.
Trois hypothèses, aucune certitude
En l’absence de communication de Microsoft, plusieurs lectures circulent dans la communauté.
- Hypothèse 1 : un déploiement non documenté. Microsoft aurait étendu silencieusement sa politique DMARC à tous les expéditeurs, sans seuil de volume. Les experts notent que Google et Yahoo ont fait la même trajectoire — commencer par les gros expéditeurs, puis abaisser le seuil.
- Hypothèse 2 : un bug. Le comportement incohérent (messages livrés puis rejetés à quelques minutes d’écart, domaines correctement configurés touchés) suggère un dysfonctionnement dans le filtre plutôt qu’une politique appliquée de manière déterministe.
- Hypothèse 3 : les deux à la fois. Frank Dickson, analyste chez Dickson Research, avance que « le déploiement a été bâclé, mais la destination ne fait pas de doute ». En d’autres termes : une intention réelle, mal exécutée.
Aucune de ces hypothèses ne peut être confirmée ni infirmée à ce stade.
La direction est claire, même si le timing ne l’est pas
Ce qui ne fait pas débat : l’industrie du courrier électronique se dirige vers une authentification obligatoire pour tous. Google et Yahoo l’exigent des expéditeurs de masse depuis février 2024. Microsoft a suivi pour les gros volumes en mai 2025. Que le mouvement s’étende à tous les expéditeurs semble, pour la plupart des observateurs, une question de temps.
Ce qui est contesté : le fait que cela se produise sans annonce, avec un message d’erreur qui ne correspond à aucune règle publiée, et de manière intermittente. « Personne ne devrait apprendre une nouvelle règle par un message de rejet », résume Frank Dickson.
Que faire en attendant ?
Pour les expéditeurs qui veulent se prémunir, la mesure est simple et sans risque. D’abord vérifier si un enregistrement DMARC existe avec la commande « dig +short TXT _dmarc.votredomaine.be« . Si la réponse est vide, il n’y a pas d’enregistrement. Ensuite, publier un enregistrement minimal chez votre hébergeur DNS : nom « _dmarc », type TXT, valeur « v=DMARC1; p=none;« .
Cette politique indique que le domaine utilise DMARC mais ne demande aucune action en cas d’échec d’authentification. Elle ne modifie pas le traitement de vos e-mails. Enfin, s’assurer que SPF et DKIM sont correctement configurés et alignés avec le domaine d’envoi. Cette mesure est recommandée par plusieurs fournisseurs de messagerie et administrateurs, mais Microsoft ne l’a pas officiellement confirmée comme correctif.
En résumé
Situation actuelle : des rejets d’e-mails vers les services Microsoft grand public, touchant des domaines de toutes tailles, sans enregistrement DMARC. Origine : non confirmée. Ni bug ni politique officielle n’ont été reconnus par Microsoft. Impact : intermittent et imprévisible. Des domaines correctement configurés peuvent être touchés.
Recommandation raisonnable : publier un enregistrement DMARC p=none. C’est une mesure préventive, sans effet secondaire connu, qui protège contre l’hypothèse d’un durcissement définitif de la politique.
