Comment configurer les domaines acceptés et les objets MailUser dans un tenant Microsoft 365 cible

Dans tout projet de préparation du tenant cible Microsoft 365, la mise en place des domaines personnalisés dans Exchange Online conditionne directement la coexistence messagerie entre tenants. Les domaines acceptés définissent les espaces de noms que le tenant cible reconnaît, tandis que les objets MailUser permettent de maintenir une identité cohérente dans Microsoft Entra ID pour chaque utilisateur en cours de migration. Cette relation entre domaines, DNS et objets MailUser constitue le socle du routage mail cross-tenant. Maîtriser ce paramétrage dès le départ évite les erreurs de distribution et facilite une coexistence fluide entre les deux environnements tout au long du projet.

Comprendre le rôle et les types de domaines acceptés dans Microsoft 365

Un domaine accepté dans Exchange Online est tout espace de noms SMTP pour lequel votre organisation est autorisée à envoyer ou recevoir des e-mails. Sa configuration conditionne directement le comportement du flux de messagerie, notamment dans les scénarios de migration ou de coexistence inter-tenant.

Définition d’un domaine accepté dans Exchange Online

Dans Exchange Online, un domaine accepté est enregistré au niveau du tenant Microsoft 365 afin d’indiquer à la plateforme comment traiter les messages entrants et sortants associés à un espace de noms SMTP donné. Sans cette déclaration, Exchange Online rejette ou ne route pas correctement les messages destinés à ce domaine. La configuration des domaines acceptés s’appuie sur des enregistrements DNS vérifiés (enregistrement TXT de type MX ou SPF) qui attestent la propriété du domaine. Cette étape est donc préalable à tout déploiement de boîtes aux lettres, qu’il s’agisse d’une ouverture initiale ou d’une migration tenant to tenant. Pour approfondir la préparation technique de ces opérations, la configuration des modules PowerShell pour la migration Microsoft 365 constitue une étape complémentaire incontournable.

Les trois catégories de domaines : autoritatifs, relais interne et relais externe

Selon Microsoft, il existe trois types de domaines acceptés configurables dans Exchange Online : Faisant autorité (Authoritative), Relais interne (Internal Relay) et Relais externe (External Relay). (Source : Microsoft — 2025-05-09)

• Domaines autoritatifs : Exchange Online est responsable de la distribution finale des messages. Aucun relais vers un autre système n’est effectué. Tous les destinataires doivent disposer d’une boîte aux lettres active dans le tenant.
• Domaines internes relais : Le tenant Exchange Online accepte les messages pour ce domaine, mais peut les transférer vers un autre système de messagerie (par exemple, un serveur Exchange On-Premises ou un tenant tiers). Ce mode est courant en contexte de coexistence hybride.
• Domaines externes relais : Exchange Online reçoit les messages et les relaie vers un système externe sans assumer la responsabilité de la distribution finale. La gestion des non-délivrances (NDR) incombe au système cible.

Impact sur la coexistence et le routage mail inter-tenant

Le choix du type de domaine accepté a des répercussions directes sur la configuration du routage mail tenant to tenant. Durant une migration Microsoft 365, le domaine source est souvent configuré en relais interne dans le tenant cible afin que les messages adressés aux utilisateurs non encore migrés continuent d’être acheminés correctement. Ce mécanisme évite les ruptures de flux et garantit la continuité de service. Une mauvaise qualification — par exemple déclarer un domaine en mode autoritatif alors que des boîtes aux lettres résident encore dans le tenant source — génère des erreurs de non-délivrance immédiates. La documentation officielle de Microsoft sur la migration multi-tenant inter-tenant détaille les prérequis associés à cette configuration. Le chapitre suivant examine comment les objets MailUser s’articulent avec ces domaines pour représenter les destinataires distants dans le tenant cible.

Ajouter et valider les domaines personnalisés dans le tenant Microsoft 365 cible

L’ajout d’un domaine personnalisé dans un tenant Microsoft 365 cible repose sur une procédure guidée depuis le Centre d’administration, suivie d’une validation DNS obligatoire. Maîtriser ces étapes est indispensable pour garantir un routage de messagerie sans interruption lors d’une migration inter-tenant.

Procédure d’ajout depuis le Microsoft 365 Admin Center

Selon la documentation officielle de Microsoft, pour ajouter un domaine personnalisé à Microsoft 365, il faut accéder au Microsoft 365 Admin Center puis naviguer vers Paramètres > Domaines > Ajouter un domaine. Un assistant pas à pas guide l’administrateur tout au long du processus : saisie du nom de domaine, vérification de la propriété, puis configuration des enregistrements DNS. (Source : Microsoft — 2025-07-01)

Il est important de noter que le domaine doit au préalable être enregistré auprès d’un bureau d’enregistrement (registrar). Microsoft propose de détecter automatiquement le registrar pour simplifier les étapes suivantes. Pour approfondir la compréhension du cadre global des migrations inter-tenants, la documentation sur la migration multi-tenant Microsoft 365 constitue une référence utile.

Validation et enregistrement DNS : Domain Connect ou saisie manuelle

Une fois le domaine déclaré, Microsoft 365 propose deux méthodes de validation DNS. La première, Domain Connect, automatise la création des enregistrements directement auprès des registrars compatibles (GoDaddy, OVH, etc.) en quelques clics. La seconde requiert une saisie manuelle des enregistrements DNS au niveau du registrar.

La validation via l’Exchange Admin Center permet aussi de vérifier que les enregistrements MX et SPF sont correctement propagés avant de basculer le flux de messagerie.

Meilleures pratiques pour éviter les erreurs de routage

Plusieurs précautions limitent les risques lors de la validation DNS dans le cadre de la création d’un domaine personnalisé Office 365. Il est conseillé de ne pas supprimer les anciens enregistrements MX du tenant source avant la confirmation que le tenant cible reçoit bien les e-mails. Le TTL (Time To Live) des enregistrements DNS doit être abaissé à 300 secondes minimum 24 à 48 heures avant la bascule, afin d’accélérer la propagation. La vérification des enregistrements CNAME Autodiscover est également recommandée pour éviter les problèmes de connectivité Outlook post-migration.

La configuration DNS pour domaines personnalisés étant validée, l’étape suivante consiste à préparer les objets MailUser dans le tenant cible afin d’assurer la continuité du routage pour chaque utilisateur migré.

Créer et configurer les objets MailUser pour la coexistence entre tenants

Les objets MailUser permettent de maintenir le routage des e-mails vers les utilisateurs sources durant toute la période de migration cross-tenant. Leur configuration correcte dans le tenant cible est une condition indispensable à la coexistence entre environnements Microsoft 365.

Comprendre les attributs clés d’un objet MailUser

Un objet MailUser est une représentation légère d’un destinataire externe dans Exchange Online. Contrairement à une boîte aux lettres active, il ne stocke pas de messages : il sert uniquement à acheminer les communications vers l’adresse cible. Ses attributs principaux incluent l’adresse SMTP principale, les adresses proxy (alias), le ExternalEmailAddress qui pointe vers le tenant source, ainsi que l’ImmutableId utilisé pour l’appairage avec Microsoft Entra ID. Cet identifiant immuable est essentiel pour garantir la continuité de l’objet lors de la conversion future en boîte aux lettres. Sans lui, la migration échoue ou génère des objets dupliqués difficiles à réconcilier.

Création manuelle ou automatisée via PowerShell

Pour des migrations à petite échelle, la création manuelle d’objets MailUser dans le Centre d’administration Microsoft 365 reste envisageable. Cependant, dès que le volume dépasse une dizaine d’utilisateurs, le recours à Exchange Online PowerShell s’impose. Les scripts d’automatisation permettent de lire un fichier CSV exporté depuis le tenant source, puis de créer chaque objet avec les attributs requis en une seule exécution. La commande New-MailUser associée à Set-MailUser couvre la création initiale et l’enrichissement des attributs secondaires. Des solutions tierces ou des scripts maison peuvent également orchestrer ces opérations à grande échelle, avec journalisation des erreurs et reprise sur incident. Pour aller plus loin sur les scénarios de migration multi-tenant supportés, la migration cross-tenant Microsoft 365 documente les prérequis et les étapes validées par Microsoft.

Alignement des UPN et adresses SMTP entre source et cible

L’un des points de friction les plus fréquents dans la création en masse d’objets MailUser concerne la cohérence des adresses. L’UPN (User Principal Name) dans le tenant cible doit correspondre au format attendu par Microsoft Entra ID, généralement basé sur le domaine cible. En parallèle, l’adresse SMTP principale doit refléter le domaine source pour préserver la délivrabilité pendant la coexistence. Il est recommandé d’ajouter le domaine source en tant qu’adresse proxy sur chaque objet MailUser du tenant cible. Selon Microsoft, les domaines acceptés peuvent être configurés de manière unitaire ou inclure des sous-domaines (Source : Microsoft — 2025-05-09), ce qui offre une flexibilité appréciable pour couvrir plusieurs espaces de noms sans multiplier les déclarations.

Une fois les objets MailUser créés et alignés, l’étape suivante consiste à valider la résolution des adresses et à tester le flux de messagerie entre les deux tenants avant de déclencher les migrations de boîtes aux lettres.

Tests, sécurité et gouvernance après configuration des domaines et MailUser

Après la configuration des domaines acceptés et des objets MailUser, trois actions prioritaires conditionnent la réussite opérationnelle : valider le flux de messagerie, sécuriser les domaines configurés et instaurer une gouvernance Exchange Online durable. Ces étapes transforment une migration techniquement complète en environnement stable et conforme.

Effectuer des tests de flux mail Microsoft 365 et de résolution DNS

La validation du flux de messagerie constitue le premier jalon post-configuration. Avant de déclarer la migration terminée, il est indispensable d’envoyer des messages tests depuis et vers chaque domaine migré, en couvrant les scénarios internes (tenant à tenant) et externes (partenaires, clients). L’outil Analyseur de connectivité à distance Microsoft ainsi que la commande PowerShell Test-MailFlow permettent d’identifier les ruptures de routage avant qu’elles n’impactent les utilisateurs finaux.

La résolution DNS doit également être vérifiée : les enregistrements MX, SPF, DKIM et DMARC doivent pointer vers le tenant cible. Un enregistrement MX mal propagé ou un SPF resté sur l’ancien tenant sont les causes les plus fréquentes de rejet silencieux de messages. D’après Microsoft, un domaine accepté permet aux utilisateurs d’envoyer et de recevoir des messages — ce qui suppose que l’ensemble de la chaîne DNS soit cohérente avec la configuration du tenant. (Source : Microsoft — 2025-04-23)

Contrôler les permissions et délégations des administrateurs de domaine

La sécurisation des domaines acceptés passe par un audit rigoureux des permissions attribuées pendant la migration. Les comptes temporaires créés pour automatiser la configuration des objets MailUser — comptes de service, connecteurs partenaires, rôles Exchange délégués — doivent être révoqués ou réservés à un usage strictement contrôlé. Le Centre de messages Microsoft 365 constitue un point de surveillance central : il signale les modifications de configuration sensibles et les alertes liées aux domaines.

Les administrateurs de domaine doivent se voir attribuer des rôles au moindre privilège selon le principe de séparation des tâches. Il est recommandé de revoir les membres des groupes de rôles Exchange Online (notamment Organization Management et Recipient Management) et de documenter chaque délégation résiduelle dans un registre de gouvernance. Cette traçabilité est indispensable pour toute revue de sécurité ultérieure.

Mettre en place un reporting et une gouvernance continue post-projet

La gestion post-migration Microsoft 365 ne s’arrête pas au jour J. Le Centre de conformité Microsoft 365 offre des capacités de surveillance des politiques de rétention, des journaux d’audit et des alertes de conformité applicables aux domaines nouvellement intégrés. Il est conseillé d’activer l’audit unifié dès la fin de la migration pour capturer les événements liés aux modifications d’objets MailUser.

La migration cross-tenant Microsoft 365 implique une phase post-projet structurée qui détermine la pérennité des configurations. Le chapitre suivant aborde les erreurs courantes et les actions correctives associées à la configuration des domaines acceptés et des objets MailUser.

Conclusion

Une migration réussie vers Microsoft 365 repose avant tout sur une configuration rigoureuse des domaines acceptés et des objets MailUser dans le tenant cible. Ces étapes conditionnent directement la stabilisation du routage mail après migration et préviennent toute interruption du service de messagerie.

Tout au long de ce guide, trois piliers se dégagent : la préparation DNS et la déclaration correcte des types de domaines dans Exchange Online, la création et la synchronisation précise des objets MailUser, et les vérifications de sécurité permettant de sécuriser la gouvernance du flux de messagerie. Selon Microsoft, chaque organisation Microsoft 365 peut avoir jusqu’à cinq domaines onmicrosoft.com, un paramètre à anticiper dès la phase de planification pour éviter des blocages lors de la coexistence tenant to tenant. (Source : Microsoft — 2025-07-01)

La documentation de chaque étape et le transfert de connaissances aux équipes opérationnelles sont indispensables pour garantir la réussite migration Exchange Online sur le long terme. Enfin, un suivi post-migration Microsoft 365 structuré, intégrant la validation configuration des domaines et l’audit des flux dans le Centre d’administration, reste la clé pour consolider un environnement stable et sécurisé. Pour aller plus loin sur les scénarios de migration inter-tenant, consultez la documentation officielle sur la migration multi-tenant Microsoft 365.