Depuis le 5 novembre, des expéditeurs signalent que Outlook.com et Hotmail refusent une partie de leurs e-mails faute d’enregistrement DMARC, d’après MailRoute et Suped. L’erreur est un « 550 5.7.1 Message rejected : Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) ».
Le rejet est intermittent : un même domaine peut voir un message passer, puis le suivant revenir en erreur. Newsletters, notifications d’un site ou mails transactionnels sont les premiers exposés.
Prudence toutefois : Microsoft n’a rien annoncé à ce stade, et ces rapports viennent d’éditeurs d’outils d’e-mail. Suped souligne qu’ils n’établissent pas une nouvelle politique ni un taux de rejet global. Publier SPF, DKIM et DMARC reste de toute façon la bonne pratique.
Ce que l’on sait, et ce que l’on ignore
Microsoft impose déjà SPF, DKIM et DMARC aux expéditeurs de plus de 5 000 messages par jour depuis mai 2025, avec une erreur 5.7.515 en cas de manquement, selon MailRoute et Suped, qui citent la documentation de l’éditeur. La nouveauté constatée touche aussi de petits volumes : MailRoute évoque des expéditeurs ordinaires, toSend des domaines qui envoient quelques mails par jour.
Les sources divergent sur la cause. MailRoute et toSend désignent l’absence de DMARC ; Suped rappelle qu’un enregistrement DMARC ne corrige ni une signature DKIM manquante ni une adresse IP non autorisée. Un p=none n’offre donc aucune garantie d’acceptation.
Étape 1 : faire l’inventaire de vos envois
Listez chaque service qui envoie au nom de votre domaine : newsletter, boîte de messagerie, plugin de formulaires, outil de facturation. Pour chacun, notez le domaine de l’adresse d’expéditeur (From) et le service qui envoie réellement. DMARC ne passe que si le domaine du From correspond au domaine validé par SPF ou signé par DKIM, c’est ce qu’on appelle l’alignement.
Étape 2 : publier un enregistrement SPF
SPF déclare qui a le droit d’envoyer pour votre domaine. Il ne doit exister qu’un seul enregistrement TXT SPF par domaine, et il doit inclure tous vos services. Le modèle ci-dessous est générique : remplacez la valeur par celle que donne votre fournisseur.
example.com. IN TXT « v=spf1 include:_spf.votre-fournisseur.net — all »Étape 3 : activer la signature DKIM
DKIM ajoute une signature cryptographique à chaque message. Votre fournisseur d’envoi vous donne un sélecteur et une clé publique à publier dans le DNS, sous la forme suivante. DKIM est le plus fiable des deux mécanismes, car SPF casse souvent lors du transfert d’un message.
selector1._domainkey.example.com. IN TXT « v=DKIM1 ; k=rsa ; p=CLE_PUBLIQUE »Étape 4 : publier DMARC
Ajoutez un enregistrement TXT sur _dmarc.votre-domaine. Commencez par p=none, qui ne bloque rien, et une adresse rua pour recevoir les rapports. Il ne doit y avoir qu’un seul enregistrement DMARC : avec deux, toSend indique que les récepteurs ignorent les deux.
_dmarc.example.com. IN TXT « v=DMARC1 ; p=none ; rua=mailto:dmarc@example.com »Vérifier que tout passe
Les commandes dig permettent de contrôler la publication : dig +short TXT _dmarc.example.com doit renvoyer un texte commençant par « v=DMARC1 ». Envoyez ensuite un message de test vers une adresse Outlook ou Hotmail et ouvrez ses en-têtes : la ligne Authentication-Results doit afficher spf=pass, dkim=pass et dmarc=pass. Cherchez aussi « AS9031519 » dans vos messages d’erreur pour savoir si vous êtes concerné.
Durcir la politique progressivement
Les sources recommandent de démarrer en p=none. Une fois les rapports analysés et tous les envois légitimes alignés, on peut passer à p=quarantine, puis à p=reject. Ce calendrier est une pratique courante plutôt qu’une règle de Microsoft ; toSend rappelle que de nombreux domaines restent en p=none sans risque.
Reste à savoir ce que Microsoft confirmera
Reste à voir si Microsoft publie une position officielle et un seuil de volume. D’ici là, publier SPF, DKIM et DMARC aligné est la seule protection fiable. Nous mettrons ce guide à jour si l’éditeur s’exprime.
