Depuis le 5 novembre 2026, de nombreux administrateurs constatent que Outlook.com, Hotmail, Live et MSN rejettent une partie des emails envoyés par des domaines qui ne publient pas d’enregistrement DMARC. Le message de refus est explicite : 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records. Les petits expéditeurs sont touchés, pas seulement les gros volumes.
Microsoft n’a publié aucune annonce. Ses modérateurs ont ensuite parlé d’une dégradation de service, et plusieurs sources rapportent une correction le 9 novembre. Incident ou avant-goût d’une règle durable, la leçon pour la délivrabilité email est la même : un domaine qui envoie des emails sans DMARC est désormais exposé à des rejets sans préavis. Voici ce que l’on sait, ce qui reste incertain et la marche à suivre.
À retenir : publiez au minimum
v=DMARC1; p=none; rua=mailto:…sur chaque domaine qui envoie des emails, et vérifiez que SPF ou DKIM est aligné sur le domaine visible dans le champ From. Un enregistrement DMARC seul ne suffit pas si aucun mécanisme ne s’aligne.
Chronologie : ce qui a été observé
5 novembre 2026. Le fournisseur MailRoute relève dans ses journaux d’envoi les premiers rejets vers les domaines grand public de Microsoft. Le même jour, des administrateurs ouvrent des fils sur le forum Microsoft Q&A, en datant le début des refus entre le 4 et le 6 novembre. Microsoft n’a rien annoncé au préalable.
6 au 8 novembre. Les signalements se multiplient. Le refus est intermittent : un message passe, le suivant est rejeté, un nouvel envoi réussit parfois. Un administrateur indique qu’environ la moitié de ses clients sont touchés. Le média allemand heise et plusieurs éditeurs spécialisés (EasyDMARC, URIports) documentent le phénomène.
9 novembre. Un modérateur Microsoft du forum Q&A évoque « un problème de service Exchange en cours », classé comme dégradation de service. Des administrateurs signalent dans l’après-midi que les rejets semblent s’arrêter.
10 novembre. Selon EasyDMARC et URIports, le centre d’administration Microsoft 365 décrit un incident (référence EX1545193) : une mise à jour des règles anti-spam aurait marqué et bloqué des messages à tort, avant d’être annulée. Cet incident est réservé aux administrateurs ; nous n’avons pas pu le consulter directement. Les sources le présentent comme clos, et la notice ne parlerait pas de DMARC.
Le message d’erreur et ce qu’il signifie
Le rejet le plus fréquent prend cette forme :
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
Remote-MTA: live-com.olc.protection.outlook.comLe code 550 est un refus définitif : le serveur ne réessaiera pas. La mention AS9031519 n’est pas documentée publiquement par Microsoft. Certains messages ont aussi été refusés avec un code 550 5.7.23, normalement associé à un échec SPF. Contrairement au code 550 5.7.515 de la règle de 2025, ce message n’indique pas quel contrôle a échoué. Il faut donc relire les en-têtes et la configuration DNS pour conclure.
Seuls les destinataires grand public sont concernés : outlook.com, hotmail.com, live.com, msn.com et leurs variantes nationales. D’après EasyDMARC, les tenants Microsoft 365 professionnels ne semblent pas affectés en réception, sans confirmation officielle. Si vos clients sont des particuliers, ou des indépendants qui utilisent une adresse Hotmail, l’impact a pu être direct : devis, factures, confirmations de commande.
Pourquoi des domaines bien configurés ont aussi été rejetés
Une partie des signalements vient d’expéditeurs dont SPF, DKIM et DMARC étaient correctement publiés. Certains en-têtes affichaient même spf=pass, dkim=pass et dmarc=pass sur des messages refusés. Ce n’est pas compatible avec une simple règle « pas de DMARC, pas de remise ». C’est cohérent avec l’hypothèse d’un filtre anti-spam défectueux que Microsoft aurait annulé.
À l’inverse, plusieurs administrateurs ont vu les rejets cesser dès la publication d’un enregistrement DMARC. Les deux constats ne s’excluent pas : le filtre semblait pénaliser d’abord les domaines sans DMARC, tout en touchant d’autres messages par erreur. En pratique, vous ne pouvez pas compter sur l’indulgence d’un fournisseur. Vous pouvez en revanche supprimer la cause la plus probable de rejet.
Ce que Microsoft exige officiellement depuis 2025
La règle documentée par Microsoft date d’avril 2025. Elle vise les expéditeurs qui envoient plus de 5 000 messages par jour vers ses services grand public, avec le même domaine From. Depuis le 5 mai 2025, ces expéditeurs doivent respecter trois conditions :
| Exigence | Niveau attendu |
|---|---|
| SPF | Doit passer pour le domaine d’envoi |
| DKIM | Doit passer |
| DMARC | Au moins p=none, aligné sur SPF ou DKIM (idéalement les deux) |
Les messages non conformes reçoivent le code 550 5.7.515 Access denied, sending domain … does not meet the required authentication level. Microsoft recommande aussi des adresses From et Reply-To valides, une désinscription fonctionnelle et une hygiène de liste. D’autres acteurs durcissent aussi leurs règles : Spamhaus contrôle désormais l’identité DNS de chaque IP d’envoi. Notre article sur les exigences DMARC de Gmail, Microsoft et Yahoo replace cette règle dans l’ensemble des fournisseurs.
L’épisode de novembre montre que la frontière des 5 000 messages n’est pas une protection. Un filtre peut se durcir sans préavis, et les petits domaines sans DMARC ont été les premiers exposés.
Le correctif minimal : publier DMARC correctement
Vérifiez d’abord si votre domaine publie un enregistrement :
dig +short TXT _dmarc.example.frSans réponse, publiez un enregistrement TXT sur _dmarc :
_dmarc.example.fr. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.fr"La politique p=none ne bloque rien : elle demande seulement aux destinataires d’évaluer DMARC et de vous envoyer des rapports. C’est le minimum demandé par Microsoft, Google et Yahoo. Le paramètre rua est facultatif pour la norme, mais indispensable en pratique : sans rapports, vous ne savez pas qui envoie avec votre domaine. Notre guide pour lire un rapport DMARC XML explique comment les exploiter.
Publier DMARC ne suffit pas si ni SPF ni DKIM ne s’alignent. DMARC passe uniquement si l’un des deux mécanismes réussit pour le domaine visible dans le champ From. Les erreurs les plus fréquentes :
- Microsoft 365 signe avec
onmicrosoft.com. Sans DKIM activé pour votre domaine personnalisé, la signature passe mais n’est pas alignée. - Un outil tiers utilise son propre domaine de rebond. Le Return-Path appartient à la plateforme : SPF passe pour elle, pas pour vous.
- SPF dépasse 10 recherches DNS. Le résultat devient
permerror; voir notre explication de la limite SPF. - Deux enregistrements DMARC coexistent. La norme impose un seul enregistrement : en présence de deux, DMARC est ignoré.
Notre vérificateur de domaine gratuit contrôle la présence et la syntaxe de SPF et DMARC en quelques secondes. Il ne remplace pas la vérification des messages réels : seul un en-tête reçu montre l’alignement effectif.
Si des messages sont encore rejetés
- Conservez le NDR complet, avec la ligne
Remote-MTAet la référence entre crochets. Elle permet à Microsoft d’identifier le message. - Récupérez un message accepté et un message refusé du même flux, puis comparez leurs en-têtes
Authentication-Results. - Vérifiez chaque outil d’envoi : messagerie, CRM, facturation, site web, plateforme marketing. Un seul outil non aligné suffit à produire des échecs.
- Renvoyez après correction. Un
550n’est pas retenté automatiquement : le message d’origine est perdu pour le destinataire. - Contactez le support expéditeurs Outlook.com via son formulaire dédié si votre configuration est correcte et que les refus persistent.
Après le correctif : faire progresser DMARC
p=none évite le rejet pour absence de DMARC, mais ne protège pas votre domaine contre l’usurpation. Une fois les sources légitimes identifiées dans les rapports, faites progresser la politique vers p=quarantine, puis p=reject. Avancez par paliers, en vérifiant à chaque étape qu’aucun flux légitime n’échoue. Notre méthode pour configurer SPF, DKIM et DMARC sans casser ses emails détaille ces paliers.
Cette progression n’est pas qu’une affaire de sécurité. Elle rend aussi votre réputation lisible pour Gmail, Yahoo et Microsoft. Elle ne garantit pas l’arrivée en boîte de réception, qui dépend aussi de vos pratiques d’envoi et de l’engagement de vos destinataires.
FAQ
Faut-il un DMARC même si j’envoie peu d’emails ?
Oui. La règle officielle de Microsoft vise les envois de plus de 5 000 messages par jour. Les rejets de novembre 2026 ont pourtant touché des domaines à faible volume. Un enregistrement p=none avec rapports ne coûte rien et supprime ce risque.
L’erreur 550 5.7.1 est-elle la même que 550 5.7.515 ?
Non. Le code 5.7.515 correspond à la règle documentée de 2025 pour les gros expéditeurs non authentifiés. Le message 5.7.1 … lacks SPF/DKIM/DMARC Auth Records est apparu en novembre 2026 et n’est pas documenté par Microsoft. Les deux se traitent avec la même méthode : présence de DMARC, puis alignement.
Microsoft 365 est-il concerné en tant qu’expéditeur ?
Oui, si votre domaine envoie depuis Microsoft 365 sans DMARC, ou si DKIM signe encore avec le domaine onmicrosoft.com. Activez DKIM pour votre domaine personnalisé et publiez un enregistrement DMARC.
p=none suffit-il ?
Pour éviter un rejet lié à l’absence de DMARC, oui. Pour protéger votre domaine contre l’usurpation, non : il faut à terme quarantine ou reject, une fois les sources légitimes alignées.
Microsoft a-t-il confirmé une nouvelle règle ?
Non, à la date de rédaction (10 novembre 2026). Les seules déclarations publiques viennent de modérateurs du forum, qui parlent d’une dégradation de service. Nous mettrons cet article à jour si Microsoft publie une position officielle.
Conclusion
Que les rejets de novembre relèvent d’un incident ou d’un durcissement, le constat est le même : DMARC fait désormais partie de la configuration minimale de tout domaine qui envoie des emails. Publiez un enregistrement avec rapports, alignez chaque outil d’envoi, puis renforcez la politique à partir des données réelles. Si vos flux sont nombreux ou mal documentés, notre prestation d’audit et de configuration SPF, DKIM et DMARC commence par cet inventaire.
Sources et références
- heise online — Outlook.com: The email is real — but it still isn’t getting through (9 novembre 2026)
- MailRoute — Outlook.com Is Quietly Rejecting Email From Domains Without DMARC (6 novembre 2026)
- EasyDMARC — Microsoft Is Now Rejecting Mail From Domains Without DMARC (mis à jour le 10 novembre 2026)
- URIports — Microsoft Now Requires DMARC, Even for Low-Volume Email Senders
- Microsoft Q&A — 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records
- Microsoft Q&A — SPF validation error (réponse du modérateur, 9 novembre 2026)
- Microsoft Tech Community — Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders (avril 2025)
- Microsoft Support — Résoudre l’erreur NDR 550 5.7.515 dans Outlook.com