Microsoft 365 : l'édition Fisher-Price de l'informatique

Les deux derniers articles ont bâti un serveur de courrier qui satisfait un jeu de règles, une fois à partir de quatre paquets et une fois à partir d’un seul binaire. Presque personne ne fait cela. On paie Microsoft, on pointe son domaine vers Exchange Online, et on le laisse tout gérer. La vraie question ici n’est donc pas « comment je le construis », mais « si j’ai déjà payé pour la plateforme sur laquelle tourne la quasi-totalité du pays, puis-je lui faire tenir les mêmes règles ? »

La réponse, d’après la documentation de Microsoft et un regard en lecture seule sur le DNS de vrais tenants, est : certaines bien, plusieurs pas du tout, et la plateforme ne vous dira pas lesquelles. C’est l’édition Fisher-Price de la sécurité du courrier. Les angles sont arrondis, les outils tranchants sont rangés, et quelques-uns des contrôles que vous iriez vraiment chercher ne sont pas là pour être activés. Chaque affirmation est sourcée sur une page de Microsoft vérifiée le 22 octobre 2026, et chaque résultat DNS est reproductible avec dig.

Le tableau de bord

Voici les règles maison de l’article d’ouverture, /fr/email/why-every-mail-setting-has-to-be-right/, face à ce qu’Exchange Online laisse réellement faire à un administrateur.

Cinq d’entre elles sont un non net ou une absence. La forme de tout cela, c’est trois colonnes : ce que Microsoft décide et réussit, la poignée que vous avez le droit d’activer, et celles qui ne sont tout simplement pas là pour être basculées.

Lisez la suite pour comprendre pourquoi chacune est là où elle est, car les raisons sont plus accablantes que les verdicts.

Ce qu’il fait bien, dit sans détour

Le crédit d’abord, car il est mérité. Sur le chemin sortant, Exchange Online est vraiment bon. La validation DANE est active par défaut depuis 2022, la validation MTA-STS est automatique avec « nothing administrators need to do to apply it »,¹ et un mode DANE Mandatory par connecteur est arrivé début 2026.² C’est plus que ce que la plupart des serveurs auto-hébergés gèrent d’emblée.

Le DANE entrant avec DNSSEC est devenu disponible (GA) le 28 octobre 2024, et les enregistrements TLSA se valident sur un tenant qui est passé au nouvel hôte.³⁴ La capacité existe donc. Le piège, c’est tout ce qui l’entoure, et c’est le reste de cet article.

Pas de clair en entrée : il n’y a pas d’interrupteur

La première règle maison est que le serveur refuse le courrier qui arrive en clair. Sur Exchange Online, il n’existe aucun moyen d’exiger cela de chaque expéditeur. Le TLS peut être demandé, mais seulement sur un connecteur partenaire, limité à des domaines ou des plages d’IP nommés, et le paramètre « applies only to Partner type connectors ».⁵ Pour tous les autres, le défaut est opportuniste.⁶ Vous pouvez exiger le TLS de vos partenaires nommés. Vous ne pouvez pas l’exiger de l’internet en général, qui est précisément l’ensemble d’expéditeurs que la règle vise. Aucun contrôle require-inbound-TLS à l’échelle du tenant n’est documenté comme existant.

Rejeter les domaines expéditeurs inconnus : pas documenté du tout

Le montage Postfix refuse le courrier dont le domaine expéditeur n’existe pas, à MAIL FROM, avant le corps. Je suis allé chercher l’équivalent Exchange Online dans la documentation anti-spam, authentification et anti-hameçonnage, et il n’y en a aucun. Le plus proche est l’authentification composite, et Microsoft est explicite : « a composite authentication failure doesn’t directly result in a message being blocked ».⁷ Je vais donc le dire avec prudence : Microsoft ne documente aucun contrôle qui jette le courrier d’un domaine expéditeur inexistant. Que quelque chose de non documenté se produise dans le filtrage, je ne peux pas le voir de l’extérieur, et vous non plus, ce qui est justement le problème.

Rejeter les échecs SPF et DKIM : non, et non

C’est celle qui devrait arrêter net un administrateur. La règle maison est de rejeter un message qui échoue en dur à SPF, ou dont la signature DKIM est présente et ne se vérifie pas. Exchange Online ne fait ni l’un ni l’autre à la porte.

Pour SPF il existe un réglage, enfoui dans le filtre anti-spam avancé. Il est « Off » par défaut, et quand il est actif il ne rejette pas le message : il marque le courrier d’un expéditeur non listé « as high confidence spam ».⁸ Relisez cela. La chose la plus forte qu’Exchange Online fera contre quelqu’un qui falsifie un domaine dont le SPF dit -all, c’est le classer dans le dossier Courrier indésirable, et même cela est désactivé d’origine. Pour DKIM, il n’y a rien du tout : aucun réglage ne rejette un message au seul motif que sa signature n’a pas pu être vérifiée. Une signature défaillante alimente DMARC et le score composite, et c’est tout.

Le rejet se produit dans un cas : quand le domaine de l’expéditeur publie DMARC p=reject, Exchange Online l’honore par défaut et refuse au moment du SMTP avec 550 5.7.1.⁹ Bien, et actif par défaut, mais cela dépend entièrement du fait que l’expéditeur ait fait ce qu’il fallait. Les contrôles que les autres montages utilisaient pour votre propre protection en entrée, rejeter sur échec SPF et rejeter sur signature cassée, ne sont pas là pour être activés.

IPv6 : deux ans plus tard, le NCSC n’est pas joignable par ce biais

IPv6 est obligatoire dans cette série. Exchange Online le prend en charge en entrée, par domaine accepté, après une adhésion, et sous réserve que Microsoft désactive automatiquement « a small percentage of our customers ».¹⁰ Ce déploiement a été annoncé en octobre 2024 comme devant prendre trois à six mois. J’ai donc lu l’enregistrement AAAA de l’hôte de courrier de vingt-deux organisations britanniques sous Microsoft 365. Neuf, deux ans plus tard, n’en ont aucun.

La boîte du National Cyber Security Centre lui-même n’est pas joignable en IPv6, pas plus que HMRC, le service de courrier du NHS, le ministère de la Défense, l’Information Commissioner ou la Lloyds Bank.⁴ Impossible de dire, depuis le DNS, si chacune a été désactivée par Microsoft ou n’a jamais adhéré. Le résultat est le même, et toutes les vingt-deux sont sur l’ancien hôte de courrier qui, comme nous allons le voir, ne peut pas être signé.

DNSSEC : pas prévu pour l’hôte que vous utilisez vraiment

C’est ici que la documentation et le DNS cessent d’être d’accord, et c’est le constat le plus tranchant de l’article. Le DANE entrant a besoin de DNSSEC, et DNSSEC a besoin que l’hôte de courrier soit dans une zone signée. Tout tenant Exchange Online ordinaire a son MX pointé vers un hôte sous mail.protection.outlook.com. J’ai vérifié si cette zone est signée, et elle ne l’est manifestement pas :

$ dig @1.1.1.1 +dnssec DS protection.outlook.com
;; flags: qr rd ra ad; ANSWER: 0
protection.outlook.com. 60 IN NSEC \000.protection.outlook.com. NS RRSIG NSEC

La zone parente est signée, et elle renvoie un enregistrement NSEC authentifié prouvant qu’il n’y a pas de DS pour protection.outlook.com. C’est une déclaration signée que la délégation n’est pas signée. Ainsi, chaque MX en *.mail.protection.outlook.com, c’est-à-dire la quasi-totalité des tenants Microsoft 365 de la planète, est dans une zone non signée et ne peut pas faire de DANE.

La nouvelle infrastructure signée vit sous un autre nom, mx.microsoft, et y passer est un changement manuel, sur adhésion. Combien l’ont fait ? Sur environ trente-cinq domaines britanniques que j’ai échantillonnés, pas un seul n’y était. Les tenants que j’ai pu trouver sur l’hôte signé étaient tous néerlandais. Et le billet d’avril 2026 de Microsoft lui-même dit que le plan n’est pas de corriger l’hôte que tout le monde utilise :

Currently, there are no plans to enable DNSSEC on the mail flow domain mail.protection.outlook.com.²

Donc : DNSSEC et DANE sont disponibles sur un nouvel hôte, si vous adhérez et migrez, et l’hôte sur lequel se trouve réellement tout tenant existant ne sera pas, de l’aveu même de Microsoft, signé. La capacité a été livrée. Le défaut n’a pas bougé, et ne bougera pas.

Les deux plus grands domaines de Microsoft lui-même montrent la fracture, et l’un d’eux fait pire que les tenants qu’il sermonne :

outlook.com, le service de courrier grand public, publie DMARC p=none : il demande au monde de vérifier son courrier puis de ne rien faire d’un échec, ce qui est le réglage que l’article d’ouverture appelle un haussement d’épaules.⁴ Le domaine d’entreprise de Microsoft fait mieux. Ni l’un ni l’autre hôte n’est signé.

La documentation se dispute avec elle-même

Quand la documentation d’un fournisseur se contredit elle-même sur un contrôle de sécurité, ce n’est pas un détail. C’est un client à qui l’on dit deux choses incompatibles sur un élément qui décide si son courrier est sûr, et j’y prête attention comme je le ferais avec n’importe quel fournisseur payé pour faire les choses bien. Trois exemples, tous tirés de pages publiées par Microsoft, tous en ligne le 22 octobre 2026.

La page SPF recommande -all, « hard fail ».¹¹ Le billet sur Direct Send recommande « a Soft Fail SPF configuration ».¹² Les deux sont à jour, et un client qui suit l’un se fait reprendre par l’autre. Sur MTA-STS, la page entrante dit à un tenant de publier mx: *.mail.protection.outlook.com, dit sur la même page que « wildcards or ‘*’ must not be used as the MX prefix in all MTA-STS scenarios »,¹ puis imprime un exemple qui utilise exactement ce wildcard. Je ne demande pas à Microsoft d’inventer quoi que ce soit. Je demande pourquoi la page qui dit à un client comment protéger son flux de courrier ne peut pas être d’accord avec elle-même sur la seule ligne qui fait la protection.

Ensuite la faille Direct Send, qui est la règle d’identité, la règle six, qui lâche à la porte d’entrée.

Il existe un moyen d’envoyer du courrier dans un tenant au nom d’un de ses propres utilisateurs sans aucune authentification, car cela « does not require any form of authentication »,¹² et c’est actif par défaut. Le réglage pour le désactiver, RejectDirectSend, est désactivé par défaut, ne vérifie que l’expéditeur de l’enveloppe et non le From: visible, et dix-huit mois plus tard a toujours « no fixed date for General Availability ».¹² Une plateforme payante a livré un moyen non authentifié d’usurper le propre domaine d’un tenant, l’a laissé actif par défaut, et le correctif est une bascule sur adhésion sans date de sortie et avec un trou dans ce qu’il vérifie. C’est le registre que je réserve à un fournisseur qui prend la ligne que c’est difficile. Ce n’est pas difficile. Comme tel, je ne vais pas faire semblant que ça l’est. C’est un défaut qui a été mal réglé et laissé tel quel.

Peut-on le construire correctement là-dessus ? En grande partie non

Voici donc le compte honnête, et ce n’est pas que Microsoft 365 est un mauvais courrier. Il livre de façon fiable, sa sécurité sortante est vraiment bonne, et pour une organisation sans expertise courrier il est plus sûr que le serveur qu’elle aurait sinon mal configuré. Tout cela est vrai, et tout cela est à côté du point que fait cette série.

Le point, c’est le contrôle, et sur les contrôles qui comptent le plus face aux menaces de l’article d’ouverture, Exchange Online ne vous le donne pas. Vous ne pouvez pas exiger le TLS entrant depuis l’internet, rejeter un échec SPF en dur, rejeter une signature falsifiée, ni jeter le courrier d’un domaine qui n’existe pas. La seule protection de transport infalsifiable, DANE avec DNSSEC, est désactivée sur l’hôte où vous êtes et n’est pas prévue pour l’atteindre. Et la faille non authentifiée de la porte d’entrée est active par défaut sans date pour la fermer.

Voilà ce que veut dire l’édition Fisher-Price. Non pas que c’est pour les enfants, mais que les outils tranchants ont été retirés, qu’on vous tend les arrondis, et qu’on vous dit que c’est pour votre bien. Ce qui, pour beaucoup de boutiques, est vrai. Pour beaucoup d’organisations, ça l’est vraiment. Pour quiconque a lu jusqu’ici et compris à quoi servaient les outils tranchants, c’est une plateforme qui a décidé, à votre place, lesquels de vos réglages de sécurité vous avez le droit de toucher. Ceux que vous vouliez le plus sont derrière la vitre.

Vous payez de toute façon. Le moins que vous puissiez faire, c’est de savoir lesquelles de ces règles elle a discrètement décidé que vous n’aviez pas le droit de tenir.