Microsoft continue de renforcer la sécurité DNS autour d’Exchange Online.
Et c’est une évolution importante pour toutes les organisations qui gèrent de la messagerie d’entreprise.
Pendant longtemps, le DNS est resté un maillon fragile du transport email : souvent non chiffré par défaut, non authentifié par défaut et exposé à des scénarios de spoofing, de détournement MX ou d’interception.
Avec DNSSEC, SMTP DANE et MTA-STS, Microsoft pousse une idée simple : fiabiliser le chemin de livraison des emails, pas seulement l’identité de l’expéditeur.
Source officielle : Microsoft Exchange Team Blog.
Ce que Microsoft annonce
Microsoft met en avant plusieurs évolutions autour d’Exchange Online et de la sécurité DNS / SMTP.
Les points les plus importants :
- un assistant DNSSEC doit arriver dans l’Exchange Admin Center au troisième trimestre 2026 ;
- SMTP DANE et MTA-STS deviennent plus pilotables sur les connecteurs sortants ;
- les administrateurs peuvent choisir le niveau d’application selon les flux ;
- le mode opportuniste reste utile pour progresser sans bloquer brutalement les échanges ;
- le mode obligatoire pour SMTP DANE permet de renforcer certains chemins critiques ;
- les nouveaux endpoints DNSSEC-capable passent par des domaines sous
mx.microsoft.
Ce n’est pas seulement une nouveauté d’administration. C’est un signal clair : la sécurité email ne s’arrête plus à SPF, DKIM et DMARC.
Pourquoi le DNS compte autant pour l’email
Quand un serveur doit livrer un email, il s’appuie sur le DNS pour savoir où envoyer le message.
Il consulte notamment les enregistrements MX, puis établit une connexion SMTP avec le serveur destinataire.
Si cette couche DNS est manipulée ou mal sécurisée, un attaquant peut chercher à détourner le chemin du message, forcer une connexion moins sûre ou provoquer une remise vers une infrastructure non légitime.
C’est précisément là que DNSSEC, SMTP DANE et MTA-STS deviennent intéressants.
Ils ne remplacent pas SPF, DKIM et DMARC. Ils protègent un autre niveau : le transport et la résolution DNS utilisés pendant la livraison.
DNSSEC, SMTP DANE, MTA-STS : qui fait quoi ?
Ces mécanismes sont proches dans l’objectif, mais différents dans leur rôle.
DNSSEC permet de vérifier cryptographiquement que les réponses DNS n’ont pas été altérées. Il aide à réduire les risques de spoofing DNS ou de manipulation d’enregistrements.
SMTP DANE s’appuie sur DNSSEC pour publier et vérifier les informations TLS du serveur mail. L’objectif est de s’assurer que le serveur SMTP contacté présente bien un certificat attendu.
MTA-STS permet à un domaine de déclarer une politique TLS pour la réception des emails. Il aide les serveurs expéditeurs compatibles à refuser une livraison non sécurisée lorsque la politique l’exige.
En résumé :
- SPF, DKIM et DMARC répondent à la question : cet email est-il légitime pour ce domaine ?
- DNSSEC, SMTP DANE et MTA-STS répondent plutôt à la question : le chemin de transport est-il fiable et sécurisé ?
Le risque : une couche invisible, mais critique
Le DNS est souvent discret dans les projets email. On le modifie au moment d’une migration, on ajoute un MX, un SPF, une clé DKIM, puis il disparaît du radar.
Pourtant, c’est une couche critique.
Une mauvaise configuration ou une absence de protection peut ouvrir la porte à plusieurs scénarios :
- détournement ou manipulation d’enregistrements MX ;
- attaques de type adversary-in-the-middle ;
- dégradation de la sécurité TLS pendant le transport ;
- remise vers une mauvaise infrastructure ;
- erreurs de routage difficiles à diagnostiquer ;
- pertes de confiance entre partenaires techniques.
Ces sujets ne sont pas toujours visibles pour les utilisateurs. Mais lorsqu’ils cassent, l’impact est direct : emails bloqués, retards de livraison, erreurs SMTP, perte de confiance ou incident de sécurité.
Ce que cela change pour les administrateurs
La nouveauté intéressante est la granularité.
Microsoft donne plus de contrôle aux administrateurs sur les connecteurs sortants, notamment avec des modes permettant d’adapter le niveau d’exigence selon le contexte.
Dans la pratique, cela permet de distinguer :
- les flux standards, qui peuvent rester en mode opportuniste ;
- les partenaires sensibles, pour lesquels un niveau plus strict peut être pertinent ;
- les cas particuliers, où une compatibilité temporaire doit être maintenue ;
- les environnements en transition, où l’on veut avancer sans provoquer de coupure.
C’est une bonne approche, car la sécurité email ne se déploie pas toujours en un seul bloc.
Un flux critique avec un partenaire bien maîtrisé peut supporter une exigence forte. Un flux historique, peu documenté ou dépendant d’un ancien routeur SMTP devra souvent être analysé avant d’être durci.
Attention à l’effet domino
Ces mécanismes touchent au transport email. Ils ne doivent donc pas être activés à l’aveugle.
Un changement DNS, une politique MTA-STS trop stricte, une validation DANE obligatoire ou un mauvais endpoint peuvent provoquer des rejets ou des files d’attente.
Avant de durcir, il faut comprendre :
- quels domaines sont concernés ;
- quels MX sont réellement utilisés ;
- quels connecteurs sortants existent ;
- quels partenaires reçoivent des flux critiques ;
- quels services tiers interviennent dans la chaîne ;
- quels journaux et rapports permettent de vérifier les résultats ;
- comment revenir en arrière si une livraison échoue.
La bonne stratégie est progressive : tester, observer, durcir, superviser.
Une checklist avant d’activer
Avant d’aller vers DNSSEC, SMTP DANE ou MTA-STS sur Exchange Online, il est utile de poser une checklist simple.
Les points à vérifier :
- l’état des domaines acceptés dans Microsoft 365 ;
- les enregistrements
MXen production ; - la présence éventuelle de passerelles mail tierces ;
- les connecteurs entrants et sortants ;
- les politiques MTA-STS existantes ;
- les certificats TLS utilisés sur les chemins SMTP ;
- la capacité du registrar à gérer DNSSEC proprement ;
- les outils de supervision disponibles ;
- les erreurs visibles dans les journaux et traces de messages ;
- le plan de retour arrière en cas de blocage.
Cette préparation évite de transformer un progrès de sécurité en incident de production.
Ce que cela dit de l’évolution de l’email
L’email continue d’évoluer.
Ces dernières années, les exigences autour de SPF, DKIM, DMARC, des plaintes spam et de la réputation ont beaucoup progressé. Gmail, Yahoo, Microsoft et les grands fournisseurs poussent tous vers plus d’authentification et de qualité.
Mais la prochaine étape se joue aussi sur la couche transport.
La confiance email ne dépend plus seulement du contenu du message ou de la réputation d’un domaine. Elle dépend aussi de la manière dont les serveurs se trouvent, se connectent et vérifient la sécurité du chemin.
Pour les entreprises, cela veut dire qu’il faudra progressivement mieux maîtriser :
- les enregistrements DNS ;
- les
MX; - DNSSEC ;
- MTA-STS ;
- SMTP DANE ;
- les certificats TLS ;
- les connecteurs ;
- les impacts opérationnels d’une modification de routage.
Conclusion
L’annonce de Microsoft est une bonne nouvelle pour la sécurité email.
Elle rend des mécanismes avancés plus accessibles et plus pilotables dans Exchange Online. C’est important, car DNSSEC, SMTP DANE et MTA-STS peuvent réellement renforcer la confiance dans le transport des emails.
Mais ce type de changement doit rester maîtrisé.
La messagerie est une infrastructure critique : un durcissement DNS ou SMTP se prépare domaine par domaine, avec des tests, de la supervision, de la documentation et un plan de retour arrière.
SPF, DKIM et DMARC restent indispensables. Mais ils ne sont plus seuls dans l’équation.
La prochaine bataille de la délivrabilité et de la sécurité email se joue aussi au niveau DNS.