Migration MX Microsoft 365 vers mx.microsoft : DNSSEC automatique, Graph API obligatoire et actions à mener avant juillet 2026
Par CaptainDNS
Publié le 6 mars 2026
- 1er juillet 2026 : Microsoft provisionne les MX des nouveaux Accepted Domains sous
mx.microsoftau lieu demail.protection.outlook.com(MC1048624, reporté depuis février 2026) - Si votre domaine a DNSSEC actif, la chaîne de confiance s'étend automatiquement au MX sous
mx.microsoft: DANE devient possible sans action supplémentaire - Toute automatisation basée sur le pattern
<domaine>.mail.protection.outlook.comcassera après le 1er juillet - L'API Graph
serviceConfigurationRecordsdevient la seule source de vérité pour récupérer la valeur MX - Les domaines existants ne sont pas affectés immédiatement, mais Microsoft prévoit une migration progressive après juillet 2026
- Vérifiez dès maintenant si votre domaine est prêt pour DNSSEC avec un diagnostic DNSSEC : c'est le prérequis pour bénéficier de la protection DANE
Le 4 avril 2025, Microsoft a publié l'annonce MC1048624 : à partir du 1er juillet 2026, tous les nouveaux Accepted Domains ajoutés à Exchange Online recevront leurs enregistrements MX sous le domaine mx.microsoft et non plus sous mail.protection.outlook.com. La date initiale de février 2026 a été reportée à juillet après les retours de la communauté.
Ce n'est pas un changement cosmétique. Le domaine mail.protection.outlook.com n'est pas signé DNSSEC. Le TLD .microsoft, lui, l'est de bout en bout. En migrant les MX sous mx.microsoft, Microsoft supprime le principal obstacle technique à l'adoption de DNSSEC et DANE pour les emails entrants sur Exchange Online. Les administrateurs n'ont plus besoin de déclencher manuellement la migration du MX.
Pour les équipes IT, l'impact est double. D'un côté, c'est une bonne nouvelle : DNSSEC "gratuit" si votre domaine est déjà signé. De l'autre, toute automatisation basée sur le pattern <domaine>.mail.protection.outlook.com va casser. Seule l'API Graph serviceConfigurationRecords fournira la valeur MX correcte.
Public visé : administrateurs Microsoft 365, MSPs gérant des tenants multi-domaines, équipes DevOps avec des workflows de provisionnement DNS automatisés.
Ce qui change concrètement au 1er juillet 2026
Avant : mail.protection.outlook.com
Jusqu'à présent, quand vous ajoutez un domaine personnalisé à Exchange Online, Microsoft provisionne le MX sous un format prévisible :
captaindns.com. 3600 IN MX 0 captaindns-com.mail.protection.outlook.com.
Ce format permettait de deviner la valeur MX à partir du nom de domaine : remplacez les points par des tirets, ajoutez .mail.protection.outlook.com. Beaucoup d'automatisations (scripts PowerShell, workflows Terraform, outils de provisionnement MSP) exploitent ce pattern.
Après : mx.microsoft
À partir de juillet 2026, les nouveaux Accepted Domains recevront un MX sous le format :
captaindns.com. 3600 IN MX 0 captaindns-com.o-v1.mx.microsoft.
Le suffixe o-v1.mx.microsoft n'est pas devinable à partir du nom de domaine seul. La valeur exacte doit être récupérée via le centre d'administration Exchange ou l'API Graph.
Timeline détaillée
| Date | Événement |
|---|---|
| 4 avril 2025 | Publication de l'annonce MC1048624 |
| Février 2026 | Date initiale prévue (reportée) |
| 2 février 2026 | Mise à jour : report à juillet 2026 |
| Début juillet 2026 | Début du basculement progressif |
| Fin juillet 2026 | Tous les nouveaux Accepted Domains sous mx.microsoft |
| Après juillet 2026 | Migration progressive des domaines existants (date non communiquée) |
Qui est affecté ?
| Situation | Impact |
|---|---|
| Domaine existant, MX déjà configuré | Aucun impact immédiat. Le MX actuel sous mail.protection.outlook.com continue de fonctionner |
| Nouveau domaine ajouté après juillet 2026 | Le MX sera sous mx.microsoft. Les automatisations basées sur l'ancien pattern échoueront |
| Automatisation de provisionnement DNS | Action requise : migrer vers l'API Graph serviceConfigurationRecords |
| DNSSEC déjà actif sur votre domaine | Bonus : DNSSEC s'étend automatiquement au MX, DANE activable sans friction |
Pourquoi ce changement ? Le problème DNSSEC d'outlook.com
Le domaine outlook.com, et par extension mail.protection.outlook.com, n'est pas signé DNSSEC. C'est un choix historique de Microsoft : signer un domaine aussi massif avec autant de sous-domaines dynamiques pose des défis opérationnels.
Le problème : sans DNSSEC sur le MX, DANE est impossible. Un serveur expéditeur veut vérifier le certificat TLS d'Exchange Online via DANE. Il doit valider la chaîne DNSSEC de bout en bout, du MX jusqu'au TLSA. Si le MX pointe vers un domaine non signé, la chaîne est brisée.
La solution de Microsoft : le TLD .microsoft. Ce TLD de marque (brand TLD) est signé DNSSEC de bout en bout. En créant l'infrastructure mx.microsoft, Microsoft obtient une zone DNS entièrement sous son contrôle et signée, sans les contraintes héritées d'outlook.com.
La chaîne DNSSEC complète devient :
root (.) → .microsoft → mx.microsoft → o-v1.mx.microsoft → captaindns-com.o-v1.mx.microsoft
Chaque maillon est signé. Les enregistrements TLSA publiés par Microsoft sous _25._tcp.captaindns-com.o-v1.mx.microsoft sont vérifiables par tout serveur expéditeur compatible DANE.
Pour comprendre en détail le fonctionnement de la chaîne de confiance DNSSEC, consultez notre guide sur la chaîne de confiance DNSSEC.
DNSSEC automatique : ce que vous obtenez gratuitement
Le changement MC1048624 a un effet de bord majeur : si votre domaine est déjà signé DNSSEC, vous bénéficiez automatiquement de la protection DNSSEC de bout en bout pour vos emails entrants, sans aucune action dans le centre d'administration Exchange.
Scénario 1 : votre domaine n'a pas DNSSEC
Rien ne change fonctionnellement. Le MX pointe vers mx.microsoft au lieu de mail.protection.outlook.com, mais la résolution DNS fonctionne normalement. Pas de DANE, pas de vérification TLSA : le comportement est identique à aujourd'hui.
Scénario 2 : votre domaine a DNSSEC actif
La magie opère :
- Le serveur expéditeur résout le MX de
captaindns.com→captaindns-com.o-v1.mx.microsoft - La réponse est signée DNSSEC (votre domaine est signé,
mx.microsoftest signé) - Le serveur demande le TLSA pour
_25._tcp.captaindns-com.o-v1.mx.microsoft - Microsoft publie automatiquement les enregistrements TLSA correspondant aux certificats d'Exchange Online
- Le serveur vérifie le certificat TLS via DANE : authentification du serveur sans dépendre des autorités de certification
Résultat : protection contre les attaques man-in-the-middle sur le transport email, automatiquement. Avant ce changement, obtenir DANE sur Exchange Online nécessitait une procédure manuelle d'activation. Après juillet 2026, pour les nouveaux domaines, c'est transparent.
L'API Graph devient la seule source de vérité
C'est le point d'action critique de l'annonce MC1048624. Microsoft le dit explicitement :
"After July 1, 2026, List serviceConfigurationRecords Graph API will be the only source of truth for your Accepted Domains' MX record value."
Le problème des automatisations actuelles
Beaucoup de scripts de provisionnement construisent le MX par convention :
# AVANT : pattern prévisible (CASSERA après juillet 2026)
$domain = "captaindns.com"
$mx = $domain.Replace(".", "-") + ".mail.protection.outlook.com"
# Résultat : captaindns-com.mail.protection.outlook.com
Ce pattern ne fonctionne plus avec mx.microsoft. Le suffixe peut varier et n'est pas devinable.
La solution : serviceConfigurationRecords
# APRÈS : utiliser l'API Graph (OBLIGATOIRE après juillet 2026)
Connect-MgGraph -Scopes "Domain.Read.All"
$records = Get-MgDomainServiceConfigurationRecord -DomainId "captaindns.com"
$mxRecord = $records | Where-Object \{ $_.RecordType -eq "Mx" \}
$mxValue = $mxRecord.AdditionalProperties.mailExchange
# Résultat : captaindns-com.o-v1.mx.microsoft (valeur réelle, pas devinée)
L'endpoint REST correspondant :
GET https://graph.microsoft.com/v1.0/domains/captaindns.com/serviceConfigurationRecords
Authorization: Bearer {token}
La réponse JSON contient la valeur MX exacte dans le champ mailExchange de l'objet domainDnsMxRecord :
{
"@odata.type": "microsoft.graph.domainDnsMxRecord",
"isOptional": false,
"label": "captaindns.com",
"recordType": "Mx",
"supportedService": "Email",
"ttl": 3600,
"mailExchange": "captaindns-com.o-v1.mx.microsoft",
"preference": 0
}
Permissions requises : Domain.Read.All (minimum). L'utilisateur connecté doit avoir le rôle Administrateur de nom de domaine ou Lecteur général.
Autres records retournés par l'API
L'API retourne aussi les CNAME DKIM, l'Autodiscover, le SPF et les SRV Teams. C'est l'occasion de migrer toutes vos automatisations DNS vers cette source unique :
| Type OData | Record | Champs clés |
|---|---|---|
domainDnsMxRecord | MX | mailExchange, preference |
domainDnsTxtRecord | TXT (SPF) | text |
domainDnsCnameRecord | CNAME (DKIM, Autodiscover) | canonicalName |
domainDnsSrvRecord | SRV (Teams) | nameTarget, port, priority |
Préparer la transition : MTA-STS et TLS-RPT
En parallèle de DNSSEC et DANE, Microsoft recommande de déployer MTA-STS et TLS-RPT pour une couverture complète de la sécurité du transport email.
MTA-STS force les serveurs expéditeurs à utiliser TLS pour livrer les emails, même s'ils ne supportent pas DANE. C'est un filet de sécurité complémentaire :
_mta-sts.captaindns.com. 3600 IN TXT "v=STSv1; id=20260306T000000"
TLS-RPT vous envoie des rapports quand un serveur expéditeur échoue à établir une connexion TLS avec votre domaine :
_smtp._tls.captaindns.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"
Pour la configuration détaillée, consultez nos guides : MTA-STS pour Microsoft 365 et TLS-RPT complet.
🎯 Plan d'action avant juillet 2026
- Auditer vos automatisations : recherchez tout script, workflow Terraform, playbook Ansible ou outil MSP qui construit un MX à partir du pattern
mail.protection.outlook.com. C'est la priorité absolue - Migrer vers l'API Graph : remplacez la construction par convention par un appel à
serviceConfigurationRecords. Testez dès maintenant sur un domaine de test - Activer DNSSEC sur vos domaines : chez votre registrar ou hébergeur DNS. C'est le prérequis pour bénéficier de DANE automatique après la migration
- Vérifier votre configuration DNSSEC : utilisez
dig +dnssec captaindns.com SOApour confirmer que le flag AD est présent - Déployer MTA-STS et TLS-RPT : complétez le dispositif de sécurité du transport avant la migration
- Surveiller les annonces Microsoft : le MC1048624 a déjà été reporté une fois. Suivez les mises à jour dans le centre de messages Microsoft 365
FAQ
Mes domaines existants sont-ils affectés par ce changement ?
Non, pas immédiatement. Le MC1048624 ne concerne que les nouveaux Accepted Domains ajoutés après le 1er juillet 2026. Vos domaines existants conservent leur MX sous mail.protection.outlook.com. Cependant, Microsoft prévoit une migration progressive des domaines existants après cette date, sans calendrier précis. Il est prudent de préparer vos automatisations dès maintenant.
Que se passe-t-il si mon automatisation utilise encore l'ancien pattern après juillet 2026 ?
Si vous ajoutez un nouveau domaine à Exchange Online après juillet 2026 et que votre automatisation construit le MX à partir de mail.protection.outlook.com, le MX sera incorrect. Le mail flow ne fonctionnera pas pour ce domaine tant que vous n'aurez pas corrigé la valeur MX pour correspondre à celle affichée dans le centre d'administration Exchange ou retournée par l'API Graph.
Faut-il activer DANE manuellement après ce changement ?
Pour les nouveaux domaines provisionnés après juillet 2026, si votre domaine a DNSSEC actif, la chaîne DNSSEC s'étend automatiquement au MX sous mx.microsoft et Microsoft publie les TLSA. Vous n'avez pas d'action supplémentaire pour le DANE inbound. Pour les domaines existants encore sous mail.protection.outlook.com, la procédure manuelle reste nécessaire.
Quelle est la différence entre DANE automatique et DANE activé manuellement ?
Le résultat final est identique : un enregistrement TLSA signé DNSSEC qui authentifie le certificat TLS d'Exchange Online. La différence est le chemin. Avec l'activation manuelle (domaines existants), vous devez déclencher la migration MX via PowerShell. Avec les nouveaux domaines après juillet 2026, le MX est déjà sous mx.microsoft et les TLSA sont publiés automatiquement si DNSSEC est actif sur votre domaine.
L'API Graph serviceConfigurationRecords est-elle disponible dans les clouds souverains ?
Oui. L'endpoint est disponible dans le cloud global, US Government L4, US Government L5 (DoD) et 21Vianet (Chine). Les permissions requises sont identiques : Domain.Read.All minimum.
Comment vérifier si mon domaine est prêt pour DNSSEC ?
Exécutez dig +dnssec captaindns.com SOA et vérifiez que le flag ad (Authenticated Data) apparaît dans la réponse. Si ce n'est pas le cas, activez DNSSEC chez votre registrar. Consultez notre guide d'activation DNSSEC pour la procédure détaillée selon votre fournisseur DNS.
Ce changement affecte-t-il SPF, DKIM et DMARC ?
Non. SPF (include:spf.protection.outlook.com), DKIM (CNAME vers *.onmicrosoft.com) et DMARC ne sont pas affectés. Seul l'enregistrement MX change de suffixe. Les mécanismes d'authentification email continuent de fonctionner comme avant.
Pourquoi Microsoft a-t-il reporté la date de février à juillet 2026 ?
Microsoft n'a pas communiqué de raison officielle. Le report a été annoncé le 2 février 2026 dans une mise à jour du MC1048624 avec la mention "Thank you for your patience". Il est probable que les retours de la communauté sur le manque de préparation des automatisations aient motivé ce délai supplémentaire.
Télécharger les tableaux comparatifs
Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.
📖 Glossaire
- Accepted Domain : domaine personnalisé ajouté à un tenant Microsoft 365 dans le centre d'administration Exchange et configuré pour recevoir des emails.
- MC1048624 : identifiant de l'annonce Microsoft dans le centre de messages Microsoft 365 décrivant la migration DNS des MX vers mx.microsoft.
- serviceConfigurationRecords : endpoint de l'API Microsoft Graph qui retourne la liste des enregistrements DNS requis pour activer les services Microsoft 365 sur un domaine donné.
- Brand TLD : domaine de premier niveau correspondant à une marque (ex:
.microsoft,.google,.amazon), géré par l'entreprise propriétaire et souvent signé DNSSEC. - DANE (DNS-based Authentication of Named Entities) : mécanisme qui lie un certificat TLS à un nom de domaine via un enregistrement TLSA signé DNSSEC, éliminant la dépendance aux autorités de certification.
