Déployer DANE pour Exchange Online et Microsoft 365

Q: Combien de temps prend l'activation de DANE sur Exchange Online ?

L'activation se fait en deux phases. La migration MX ( Enable-DnssecForVerifiedDomain ) prend quelques minutes, mais la propagation DNS dépend de vos TTL. La publication TLSA ( Enable-SmtpDaneInbound ) prend 15 à 30 minutes. Comptez quelques heures au total, principalement pour les propagations DNS.

Par CaptainDNS
Publié le 24 février 2026

Schéma montrant le flux DANE entre un expéditeur SMTP et Exchange Online avec DNSSEC et TLSA

TL;DR

Microsoft 365 supporte DANE inbound (SMTP) depuis mars 2024 pour Exchange Online, avec publication automatique des enregistrements TLSA
Le prérequis principal est DNSSEC : votre domaine doit être signé et les enregistrements DS publiés chez votre registrar
L'activation migre votre MX de mail.protection.outlook.com vers o-v1.mx.microsoft, un domaine signé DNSSEC. Microsoft publie automatiquement les TLSA, vous n'avez pas à les gérer
Google Workspace ne supporte pas DANE inbound, seul le DANE outbound (vérification) est actif
Vérifiez votre déploiement avec notre inspecteur DANE/TLSA qui teste DNSSEC, TLSA et la chaîne de certificats en un seul clic

Microsoft a annoncé la disponibilité générale de DANE inbound pour Exchange Online en mars 2024. Concrètement, les domaines hébergés sur Microsoft 365 peuvent maintenant recevoir des emails protégés par DANE : les serveurs expéditeurs qui vérifient DANE/TLSA valident le certificat TLS d'Exchange Online via DNS signé, au lieu de faire confiance aveuglément aux autorités de certification.

Mais activer DANE sur Microsoft 365 ne se fait pas dans un bouton. Le prérequis fondamental est DNSSEC : sans zone DNS signée, les enregistrements TLSA publiés par Microsoft n'ont aucune valeur. Et la configuration DNSSEC dépend de votre registrar et de votre hébergeur DNS, pas de Microsoft.

Ce guide couvre la procédure complète : vérifier les prérequis, activer DNSSEC sur votre domaine, activer DANE dans Exchange Online, et valider le déploiement de bout en bout. Il compare aussi les différences avec Google Workspace (qui ne supporte pas DANE inbound) et les serveurs on-premise comme Postfix ou Exchange Server.

Public visé : administrateurs Microsoft 365, IT managers d'entreprise, MSPs gérant des tenants M365. Pour les fondamentaux de DANE et TLSA, consultez le premier article de cette série (lien en bas de page).

Comment fonctionne DANE avec Exchange Online ?

Quand un serveur expéditeur envoie un email vers un domaine hébergé sur Exchange Online et protégé par DANE :

Résolution MX : le serveur résout le MX de captaindns.com et obtient captaindns-com.o-v1.mx.microsoft (le nouveau format MX pour les domaines DANE)
Vérification DNSSEC : il vérifie que la réponse DNS est signée DNSSEC. La chaîne de confiance passe par root → .microsoft → mx.microsoft → o-v1.mx.microsoft, entièrement signée
Requête TLSA : il demande l'enregistrement TLSA à _25._tcp.captaindns-com.o-v1.mx.microsoft
Connexion TLS : il se connecte en STARTTLS sur le port 25 et compare le certificat présenté par Exchange Online avec le hash TLSA
Livraison : si tout correspond, l'email est livré. Sinon, il est rejeté ou différé selon la politique du serveur expéditeur

Un point important : outlook.com n'est pas signé DNSSEC. C'est pourquoi Microsoft a créé l'infrastructure mx.microsoft sous le TLD .microsoft, qui est signé DNSSEC de bout en bout. L'activation de DANE migre automatiquement votre MX de l'ancien format mail.protection.outlook.com vers le nouveau o-v1.mx.microsoft.

La différence clé avec un serveur self-hosted (Postfix, Exchange Server on-premise) : Microsoft gère la migration MX, les enregistrements TLSA et les certificats TLS. Vous ne publiez pas vous-même les TLSA. Votre seule responsabilité est d'activer DNSSEC sur votre domaine.

Flux DANE entre un serveur expéditeur et Exchange Online

Prérequis avant d'activer DANE

Domaine avec DNSSEC actif

DANE repose entièrement sur DNSSEC. Sans signatures DNS valides, les enregistrements TLSA sont ignorés par les serveurs expéditeurs. Vérifiez l'état actuel :

dig +dnssec captaindns.com SOA +short

Si la réponse inclut un flag ad (Authenticated Data) dans le header, votre domaine est signé. Sinon, vous devez activer DNSSEC.

Registrar compatible DNSSEC

Tous les registrars ne supportent pas DNSSEC de la même manière :

Registrar	DNSSEC	Méthode
Cloudflare	Automatique	Un clic dans le dashboard, DS publié automatiquement
OVH	Supporté	Activation manuelle, DS à publier chez le registrant
Gandi	Supporté	Clé KSK à fournir, DS publié automatiquement
GoDaddy	Supporté	Activation manuelle dans les paramètres DNS avancés
Route 53 (AWS)	Supporté	Création de la chaîne KSK/ZSK, DS à publier manuellement

Si votre registrar ne supporte pas DNSSEC, vous devrez migrer votre DNS vers un fournisseur compatible avant de pouvoir activer DANE.

MX pointant vers Exchange Online

Avant d'activer DANE, vos MX pointent vers *.mail.protection.outlook.com. Vérifiez :

dig MX captaindns.com +short

Le résultat doit ressembler à :

0 captaindns-com.mail.protection.outlook.com.

Lors de l'activation de DANE, Microsoft vous demandera de migrer ce MX vers un nouveau format : captaindns-com.o-v1.mx.microsoft. Ce nouveau domaine est hébergé sous le TLD .microsoft, signé DNSSEC de bout en bout. L'ancien outlook.com n'étant pas signé DNSSEC, la chaîne de confiance serait impossible sans cette migration.

Si vos MX passent par un relais tiers (Proofpoint, Mimecast, Barracuda), DANE protégera uniquement le dernier saut vers Exchange Online. Le relais lui-même doit aussi supporter DANE pour une protection de bout en bout.

Activer DNSSEC sur votre domaine

La procédure varie selon votre hébergeur DNS. Voici les grandes étapes communes.

Si votre DNS est chez Cloudflare

Connectez-vous au dashboard Cloudflare
Sélectionnez votre domaine
Allez dans DNS → DNSSEC
Cliquez Enable DNSSEC
Cloudflare affiche les informations DS à publier chez votre registrar
Si Cloudflare est aussi votre registrar, c'est automatique

Cloudflare signe la zone et publie le DS en quelques minutes. Vérifiez ensuite :

dig +dnssec captaindns.com DNSKEY +short

Si votre DNS est chez un autre fournisseur

Le processus se décompose en deux étapes :

Activer la signature de zone chez votre hébergeur DNS (génération des clés KSK/ZSK, signature automatique)
Publier l'enregistrement DS chez votre registrar (la clé DS fait le lien entre votre zone signée et la zone parente)

Le DS doit correspondre exactement à la clé KSK de votre zone. Une erreur dans le DS cassera la résolution DNS de votre domaine. Testez toujours en environnement de staging ou avec un sous-domaine d'abord.

Guide en 4 étapes pour déployer DANE sur Microsoft 365

Activez la signature DNSSEC chez votre hébergeur DNS et publiez l'enregistrement DS chez votre registrar. Vérifiez avec dig +dnssec captaindns.com SOA que le flag ad apparaît dans la réponse. Comptez 24 à 48 heures pour la propagation complète du DS.
Baissez le TTL de votre MX actuel au minimum (pas moins de 30 secondes) et attendez l'expiration de l'ancien TTL. Lancez Enable-DnssecForVerifiedDomain -DomainName captaindns.com dans Exchange Online PowerShell. La commande retourne la nouvelle valeur MX : captaindns-com.o-v1.mx.microsoft. Ajoutez ce nouveau MX en priorité 20, vérifiez qu'il fonctionne, puis passez-le en priorité 0 et supprimez l'ancien MX mail.protection.outlook.com.
Une fois le MX migré et fonctionnel, lancez Enable-SmtpDaneInbound -DomainName captaindns.com. Microsoft génère et publie automatiquement les enregistrements TLSA sous _25._tcp.captaindns-com.o-v1.mx.microsoft. La propagation prend 15 à 30 minutes.
Utilisez dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft pour confirmer la présence du TLSA. Testez la connexion TLS avec openssl s_client -starttls smtp -connect captaindns-com.o-v1.mx.microsoft:25. Validez le tout avec l'outil de vérification DANE/TLSA de CaptainDNS.

Activer DANE dans Exchange Online

L'activation se fait en deux phases distinctes : d'abord la migration DNSSEC (nouveau MX), puis l'activation DANE (publication TLSA). La procédure se gère via Exchange Online PowerShell.

Phase 1 : migration MX vers mx.microsoft

Cette première phase active DNSSEC et migre votre MX vers l'infrastructure mx.microsoft, signée DNSSEC.

# Connexion à Exchange Online
Connect-ExchangeOnline -UserPrincipalName admin@captaindns.com

# Activer DNSSEC pour le domaine
Enable-DnssecForVerifiedDomain -DomainName captaindns.com

La commande retourne la nouvelle valeur MX :

Result	DnssecMxValue
`Success`	`captaindns-com.o-v1.mx.microsoft`

Procédure de migration MX :

Baisser le TTL de votre MX actuel au minimum (pas moins de 30 secondes)
Attendre l'expiration de l'ancien TTL
Ajouter le nouveau MX captaindns-com.o-v1.mx.microsoft en priorité 20
Vérifier que le nouveau MX reçoit du courrier correctement
Basculer les priorités : nouveau MX en 0, ancien en 30
Supprimer l'ancien MX captaindns-com.mail.protection.outlook.com
Passer le TTL du nouveau MX à 3600 secondes

Si vous utilisez MTA-STS, passez la politique en mode testing et ajoutez le nouveau hostname dans le fichier de politique avant la migration. Restaurez le mode enforce une fois terminé.

Phase 2 : activation DANE (publication TLSA)

Une fois le MX migré et fonctionnel :

# Activer DANE (publication des TLSA)
Enable-SmtpDaneInbound -DomainName captaindns.com

# Vérifier le statut complet
Get-DnssecStatusForVerifiedDomain -DomainName captaindns.com

Le statut passe par plusieurs phases :

Statut	Signification
`DnssecFeatureNotEnabled`	DNSSEC non activé
`DnssecValidationPending`	Microsoft vérifie DNSSEC sur votre domaine
`DnssecEnabled`	DNSSEC validé, MX migré, TLSA pas encore publié
`DaneEnabled`	DANE actif, TLSA publié et fonctionnel
`DnssecValidationFailed`	Échec de la validation DNSSEC, vérifiez votre DS

Délais

Migration MX : quelques minutes pour la commande, puis le temps de la propagation DNS (variable selon le TTL)
Publication TLSA : 15 à 30 minutes après Enable-SmtpDaneInbound
Bout en bout : comptez quelques heures, principalement à cause des propagations DNS

Vérifier le déploiement

Vérifier les TLSA avec dig

dig TLSA _25._tcp.captaindns-com.o-v1.mx.microsoft +short

Résultat attendu :

3 1 1 A4B5C6D7E8F9...  (hash SHA-256 du certificat Exchange Online)

Microsoft publie plusieurs enregistrements TLSA 3 1 1 (DANE-EE, SPKI, SHA-256) et 3 1 2 (DANE-EE, SPKI, SHA-512) pour assurer la redondance. Il est normal que certains ne correspondent pas au certificat actuel : un seul match suffit pour valider DANE.

Vérifier la connexion TLS

openssl s_client -starttls smtp \
  -connect captaindns-com.o-v1.mx.microsoft:25 \
  -servername captaindns-com.o-v1.mx.microsoft

Vérifiez que le certificat présenté correspond à l'un des hash TLSA publiés.

Vérifier avec CaptainDNS

L'inspecteur DANE/TLSA mentionné dans le TL;DR teste automatiquement :

La présence et la validité DNSSEC sur votre domaine
La résolution MX vers o-v1.mx.microsoft
La présence des enregistrements TLSA sous la zone signée
La correspondance entre le TLSA et le certificat TLS

Matrice de compatibilité DANE par fournisseur de messagerie

Erreurs courantes et solutions

DNSSEC validation failed

Cause : l'enregistrement DS chez votre registrar ne correspond pas à la clé KSK de votre zone.

Solution : vérifiez la correspondance entre le DS publié et la clé KSK avec dig DNSKEY captaindns.com +short et comparez avec le DS chez votre registrar. Régénérez le DS si nécessaire.

TLSA non publié après activation

Cause : le MX n'a pas été migré vers o-v1.mx.microsoft, Microsoft n'a pas pu valider DNSSEC, ou la propagation est encore en cours.

Solution : vérifiez que votre MX pointe bien vers *.o-v1.mx.microsoft et que l'ancien mail.protection.outlook.com est supprimé. Vérifiez le statut avec Get-DnssecStatusForVerifiedDomain. Si le statut est DnssecValidationFailed, corrigez votre configuration DNSSEC avant de réessayer.

Ancien MX non supprimé

Cause : l'ancien MX mail.protection.outlook.com coexiste avec le nouveau o-v1.mx.microsoft, ce qui empêche DANE de fonctionner correctement.

Solution : suivez la procédure de migration MX complète. Le nouveau MX doit être en priorité 0 et l'ancien doit être supprimé avant d'activer Enable-SmtpDaneInbound.

Relais tiers bloquant DANE

Cause : un service de filtrage (Proofpoint, Mimecast) intercepte les MX et ne supporte pas DANE.

Solution : DANE ne protège que le dernier saut SMTP. Si votre relais ne supporte pas DANE, vous devrez choisir entre le filtrage tiers et DANE. Certains relais commencent à supporter DANE en 2025-2026, vérifiez avec votre fournisseur.

Emails rejetés par des serveurs stricts

Cause : votre DANE est mal configuré et les serveurs expéditeurs qui appliquent une politique DANE stricte rejettent les messages.

Solution : utilisez la méthodologie de dépannage décrite dans notre guide de troubleshooting DANE/TLSA (lien en bas de page) pour diagnostiquer l'erreur exacte. Vérifiez en priorité la chaîne DNSSEC et la correspondance TLSA/certificat.

Microsoft 365 vs Google Workspace vs on-premise

Fonctionnalité	Microsoft 365	Google Workspace	On-premise (Postfix)
DANE inbound	Oui (depuis mars 2024)	Non	Oui (natif)
DANE outbound	Oui	Oui	Oui (natif)
Migration MX	Oui (`o-v1.mx.microsoft`)	N/A	Non (MX inchangé)
Gestion TLSA	Automatique (Microsoft)	N/A	Manuelle
Gestion certificat	Automatique (Microsoft)	N/A	Manuelle (Let's Encrypt, etc.)
Prérequis	DNSSEC + migration MX	-	DNSSEC + TLSA + certificat
Complexité	Moyenne (DNSSEC + migration)	N/A	Élevée (tout à gérer)
Rotation certificat	Transparente	N/A	Deploy-hook nécessaire

Google Workspace

Google supporte DANE en sortie (vérification des TLSA des destinataires) depuis 2023, mais ne supporte pas DANE en entrée. Les domaines hébergés sur Google Workspace ne peuvent pas publier de TLSA via Google. Si vous utilisez Google Workspace et souhaitez DANE inbound, il n'existe actuellement aucune solution.

Exchange Server on-premise

Pour un serveur Exchange on-premise (2016, 2019), DANE fonctionne comme pour tout serveur SMTP auto-hébergé :

Vous gérez vous-même DNSSEC, les TLSA et les certificats
La configuration est similaire à Postfix (voir notre tutoriel Postfix/Bind/Let's Encrypt dans les guides connexes)
Vous devez automatiser la rotation TLSA lors du renouvellement des certificats

Compléter DANE avec MTA-STS et TLS-RPT

DANE et MTA-STS sont complémentaires, pas concurrents :

DANE vérifie le certificat via DNS/DNSSEC (fort, mais nécessite DNSSEC)
MTA-STS impose TLS via une politique HTTPS (plus simple, mais dépend des CA)
TLS-RPT rapporte les échecs TLS et DANE par email quotidien

Microsoft 365 supporte les trois protocoles. Pour une sécurité email maximale :

Activez DANE (ce guide)
Publiez une politique MTA-STS avec notre générateur MTA-STS
Activez TLS-RPT pour recevoir les rapports d'échec

FAQ

Microsoft 365 supporte-t-il DANE ?

Oui. Microsoft a lancé le support DANE inbound pour Exchange Online en disponibilité générale en mars 2024. L'activation migre votre MX de mail.protection.outlook.com vers o-v1.mx.microsoft, un domaine sous le TLD .microsoft signé DNSSEC. Microsoft publie ensuite automatiquement les enregistrements TLSA.

Faut-il publier les enregistrements TLSA manuellement avec Microsoft 365 ?

Non. Contrairement à un serveur self-hosted, Microsoft gère automatiquement la publication et la rotation des enregistrements TLSA sous la zone o-v1.mx.microsoft. Votre responsabilité est d'activer DNSSEC sur votre domaine et de migrer le MX vers le nouveau format.

Google Workspace supporte-t-il DANE inbound ?

Non. Google Workspace supporte uniquement DANE en sortie (vérification des TLSA des destinataires). Il n'existe pas de moyen d'activer DANE inbound pour les domaines hébergés sur Google Workspace.

Combien de temps prend l'activation de DANE sur Exchange Online ?

L'activation se fait en deux phases. La migration MX (Enable-DnssecForVerifiedDomain) prend quelques minutes, mais la propagation DNS dépend de vos TTL. La publication TLSA (Enable-SmtpDaneInbound) prend 15 à 30 minutes. Comptez quelques heures au total, principalement pour les propagations DNS.

Que se passe-t-il si DNSSEC tombe en panne sur mon domaine ?

Si DNSSEC échoue (signature expirée, DS incorrect), la résolution DNS de votre domaine sera compromise. Les serveurs DANE-aware ne pourront plus valider les TLSA et rejetteront ou différeront les emails. C'est pourquoi le monitoring DNSSEC est critique.

DANE fonctionne-t-il avec un relais tiers (Proofpoint, Mimecast) ?

Partiellement. DANE protège uniquement le dernier saut SMTP. Si vos MX pointent vers un relais tiers qui retransmet ensuite vers Exchange Online, DANE ne protège que le saut relais → Exchange. Le saut expéditeur → relais n'est pas couvert sauf si le relais supporte aussi DANE.

Peut-on utiliser DANE et MTA-STS en même temps ?

Oui, et c'est recommandé. DANE vérifie le certificat via DNS/DNSSEC, MTA-STS impose TLS via HTTPS. Les deux protocoles sont complémentaires. Microsoft 365 supporte les deux simultanément.