Microsoft rejette les e-mails sans enregistrements DMARC sans préavis

Le vendredi matin, 7 novembre 2026, les administrateurs ont constaté une augmentation soudaine des rejets d'e-mails envoyés vers des domaines gérés par Microsoft, tels que hotmail.com et outlook.com. Le message de rejet citait l'absence d'enregistrements d'authentification, pointant spécifiquement le manque de politiques DMARC malgré des configurations SPF et DKIM valides. Ce changement non annoncé a perturbé la communication pour de nombreux serveurs de messagerie auto-hébergés et petites entreprises reposant sur des configurations DNS standard.

Que s'est-il passé

Le problème a été identifié pour la première fois par Mythic Beasts, un hébergeur, après que leurs journaux ont révélé plus de 500 rejets jeudi qui n'avaient pas eu lieu auparavant. Le code d'erreur renvoyé par les serveurs de Microsoft était 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records. Fait crucial, les messages rejetés possédaient des enregistrements Sender Policy Framework (SPF) et DomainKeys Identified Mail (DKIM) parfaitement valides. Le seul composant manquant était un enregistrement Domain-based Message Authentication, Reporting, and Conformance (DMARC) dans la zone DNS du domaine.

Pour tester une correction, l'équipe a ajouté un enregistrement DMARC avec une politique définie sur "none" pour plusieurs domaines affectés. Cette politique indique aux serveurs récepteurs que le propriétaire du domaine n'a aucune instruction spécifique pour gérer le courrier non authentifié, agissant effectivement comme si aucune politique n'existait. Une fois cet enregistrement publié, les serveurs de Microsoft ont de nouveau accepté les e-mails. Un sondage plus large à travers le Fediverse a confirmé que d'autres opérateurs indépendants connaissaient des échecs identiques, indiquant un changement généralisé dans la logique de filtrage du courrier entrant de Microsoft plutôt qu'une erreur de configuration isolée.

Initialement, l'absence d'annonce a conduit à spéculer qu'il pourrait s'agir d'un durcissement délibéré des normes de sécurité. L'année dernière, Microsoft avait introduit une exigence pour les domaines envoyant plus de 5 000 messages par jour de publier un enregistrement DMARC, mais ce changement avait été communiqué bien à l'avance. Cette récente modification semblait s'appliquer à tous les expéditeurs quel que soit le volume et sans avertissement. Une mise à jour du rapport original a ensuite clarifié que le changement était probablement involontaire, mais Microsoft n'avait pas encore déterminé comment annuler l'erreur de configuration.

Détails clés

• Message d'erreur : Les e-mails rejetés renvoient 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records.
• Services affectés : La livraison du courrier vers hotmail.com et outlook.com est impactée.
• Cause racine : Absence d'un enregistrement DNS DMARC, même lorsque SPF et DKIM sont correctement configurés.
• Correction temporaire : La publication d'un enregistrement DMARC avec une politique p=none restaure la délivrabilité.
• Portée : Le changement semble affecter tous les expéditeurs, pas seulement ceux à haut volume dépassant 5 000 messages quotidiens.
• Statut : Microsoft n'a pas émis de déclaration officielle ni de calendrier de retour arrière, bien que des sources internes suggèrent que le changement était accidentel.

Contexte

L'authentification des e-mails repose sur trois principaux protocoles pour prévenir l'usurpation d'identité et le phishing. SPF liste les adresses IP autorisées à envoyer des e-mails pour un domaine. DKIM ajoute une signature numérique à chaque message, permettant au destinataire de vérifier qu'il n'a pas été altéré en transit. DMARC s'appuie sur ces deux derniers en spécifiant ce que le serveur récepteur doit faire si un message échoue aux vérifications SPF ou DKIM. Les politiques peuvent être définies sur "none" (surveillance uniquement), "quarantine" (envoyer dans les spams) ou "reject" (bloquer entièrement).

Bien que DMARC soit une bonne pratique en matière de sécurité, beaucoup de petites installations auto-hébergées l'omettent car il nécessite une surveillance minutieuse pour s'assurer que le courrier légitime n'est pas bloqué accidentellement. Historiquement, les grands fournisseurs ont introduit progressivement les exigences DMARC, commençant souvent par les expéditeurs à haut volume. L'application soudaine de la présence de DMARC, même avec une politique passive "none", représente un changement significatif dans la manière dont les filtres entrants valident l'identité de l'expéditeur. Cela fait passer DMARC d'une amélioration de sécurité recommandée à une exigence structurelle obligatoire pour la livraison de base.

Pourquoi c'est important

Pour les équipes exploitant leur propre logiciel ou gérant des e-mails auto-hébergés, cet incident met en lumière la fragilité de dépendre de plateformes externes avec des changements opérationnels opaques. Sans préavis, des communications commerciales critiques peuvent disparaître dans des trous noirs, sans moyen immédiat de diagnostiquer le problème sauf si l'on surveille attentivement les journaux de rebond. Le fait que des SPF et DKIM valides soient insuffisants souligne que les exigences de conformité évoluent plus vite que ce que beaucoup de petits opérateurs ne peuvent suivre.

De plus, l'impossibilité de contacter Microsoft pour obtenir du soutien aggrave le problème. Les responsables IT et développeurs doivent compter sur les forums communautaires et le débogage par essai-erreur pour résoudre les problèmes de livraison. Cela augmente la charge opérationnelle sur les petites équipes qui n'ont peut-être pas d'experts dédiés à la délivrabilité des e-mails. Cela sert également de rappel que les configurations DNS "définir et oublier" sont risquées lorsque les grands destinataires changent leur logique de validation de manière inattendue.

Ce que vous pouvez faire

• Vérifiez votre DNS : Vérifiez si votre domaine possède un enregistrement DMARC à l'aide d'outils de recherche en ligne ou d'utilitaires en ligne de commande comme dig.
• Ajoutez un enregistrement temporaire : S'il est absent, ajoutez un enregistrement TXT pour _dmarc.yourdomain.com avec la valeur v=DMARC1; p=none; pour restaurer immédiatement la délivrabilité.
• Surveillez les journaux de rebond : Examinez les journaux de votre serveur de messagerie pour les erreurs 550 5.7.1 afin d'identifier tout message manqué depuis les quelques derniers jours.
• Validez les enregistrements existants : Assurez-vous que vos enregistrements SPF et DKIM sont toujours valides et alignés avec votre infrastructure de messagerie actuelle.
• Communiquez avec les utilisateurs : Si vous connaissez des clients utilisant les e-mails Microsoft, informez-les des retards potentiels et demandez-leur de vérifier leurs dossiers de spam.
• Planifiez des politiques plus strictes : Une fois la délivrabilité restaurée, envisagez de passer de p=none à p=quarantine ou p=reject après avoir vérifié que toutes les sources légitimes passent l'authentification.