Microsoft a reculé six jours avant l'échéance

Microsoft a reculé six jours avant l’échéance

par | Sep 7, 2026 | Emailing

Le 2 avril 2025, Microsoft annonce que les domaines envoyant plus de cinq mille messages par jour vers Outlook.com et Hotmail devront authentifier leurs envois. SPF, DKIM, DMARC en p=none au minimum, aligné sur l’un des deux. Application le 5 mai.

Le 29 avril, six jours avant l’échéance, Microsoft met à jour son billet. Les messages non conformes ne seront pas rejetés : ils partiront en courrier indésirable.

Cette correction discrète en dit plus long sur l’état réel du parc que toute la documentation qui l’entoure.

Ce qui était annoncé, et ce qui a été livré

La menace initiale était un rejet à la porte, avec un code SMTP explicite, toujours documenté aujourd’hui :

550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

Un message rejeté avec ce code n’entre jamais. L’expéditeur reçoit un rapport de non remise, ce qui est désagréable mais parfaitement clair.

Ce qui a été livré est autre chose : le dossier indésirable. Le message entre, il est stocké, il n’est pas lu, et personne n’est prévenu. Ni le destinataire, qui ne va pas voir, ni l’expéditeur, qui compte cette remise comme une réussite.

Du point de vue de l’expéditeur, la seconde sanction est bien pire que la première : elle est invisible. Un rejet vous apprend quelque chose. Un classement en indésirables ne vous apprend rien, et vous laisse continuer.

Pourquoi ce recul était inévitable

Microsoft n’a pas reculé par gentillesse. Il a reculé parce qu’un rejet massif au 5 mai aurait cassé des flux légitimes en grand nombre, et que la responsabilité de cette casse lui serait revenue.

Google a mis presque deux ans à franchir la même étape : les règles publiées en octobre 2023 pour février 2024 n’ont produit de rejets systématiques qu’à partir de novembre 2025, quand Google a annoncé « des rejets temporaires et permanents ».

Deux ans entre l’annonce et l’application, chez l’acteur le mieux outillé du marché. Ce délai est la vraie mesure de l’inertie du parc installé.

Ce que Microsoft ne publie pas

Le contraste avec les deux autres opérateurs est net sur deux points.

Aucun taux de plainte chiffré n’est publié pour les expéditeurs groupés. Google et Yahoo annoncent tous deux 0,30 %. Microsoft, rien. Vous ne savez donc pas à partir de quand vous êtes en faute chez le troisième acteur mondial.

Aucune norme technique de désabonnement n’est exigée. Là où Google et Yahoo imposent le mécanisme en un clic avec un délai chiffré, Microsoft recommande un lien de désabonnement fonctionnel et facile à trouver. C’est une exigence de bon sens, pas une exigence vérifiable.

En revanche, Microsoft rappelle une règle que beaucoup d’expéditeurs violent sans le savoir : ne pas dépasser dix requêtes DNS dans l’enregistrement SPF. Ce n’est pas une recommandation maison, c’est une obligation de la norme depuis 2014, et le motif de panne d’authentification le plus banal du métier.

Ne pas confondre deux mécanismes Microsoft

Une confusion revient dans toutes les discussions sur Outlook, et elle fait perdre du temps.

D’un côté, les exigences pour les expéditeurs de volume vers les boîtes grand public Outlook.com et Hotmail : c’est ce dont parle cet article.

De l’autre, le Bulk Complaint Level, une note de 0 à 9 attribuée par Exchange Online Protection au courrier en masse entrant chez les entreprises clientes de Microsoft 365. Le seuil par défaut est 7, la politique standard prédéfinie descend à 6, la stricte à 5.

Le premier mécanisme vous concerne comme expéditeur. Le second concerne le paramétrage de vos clients, sur lequel vous n’avez aucune prise, et qui explique qu’un même message atterrisse en boîte de réception chez l’un et en indésirables chez l’autre, sans que rien n’ait changé de votre côté.

Juillet 2026 : un signal qui s’éteint

Microsoft opère un service de données réseau, SNDS, qui montre aux propriétaires d’adresses IP ce que voit le filtre : volumes, taux de plainte, et jusqu’ici les touches sur ses pièges à spam.

À compter du 22 juillet 2026, les comptages de touches de pièges ne figurent plus dans le rapport. Le motif avancé est la protection de l’intégrité des systèmes anti abus.

Le raisonnement se défend : un compteur de pièges est aussi un outil de calibrage pour qui cherche à les éviter. Mais l’expéditeur honnête y perd le seul signal qui lui disait, sans ambiguïté, que sa collecte était polluée. Il lui reste à traiter le problème là où il naît, dans l’hygiène de la liste elle-même.

Ce que vous faites demain matin

Regardez vos journaux d’envoi et cherchez le code 5.7.515. S’il apparaît, une partie de vos messages est refusée à l’entrée d’Outlook, et vous le saviez peut-être déjà sans le savoir.

Puis comparez, sur un même envoi, votre taux de remise annoncé chez Outlook et votre taux d’engagement mesuré chez Outlook. Un écart marqué entre les deux est la signature d’un classement en indésirables, la sanction qui ne dit pas son nom.

Et retenez la leçon générale de cet épisode : entre ce qu’un opérateur annonce et ce qu’il applique, il y a un délai, une négociation implicite avec le parc installé, et parfois un rétropédalage. Bâtir sa délivrabilité sur les annonces revient à bâtir sur un calendrier qui bouge.

Sources

LaFactory travaille l’emailing sur pièces : en-têtes, enregistrements DNS, journaux de rejet. Aucune promesse de taux d’ouverture, jamais. Contactez-nous pour un audit de délivrabilité.