Partager un domaine entre deux messageries, le temps d'une migration

Pourquoi cette technique décide des migrations

Une migration de messagerie fait peur parce qu'on l'imagine comme une nuit de bascule : tout le domaine, tout le monde, sans retour. Le partage de domaine (split domain, ou espace de noms partagé) est ce qui permet de ne pas faire ça. Deux systèmes servent la même adresse @domaine.gov, chaque compte vit sur l'un ou sur l'autre, et les correspondants extérieurs ne voient rien. Les boîtes se déplacent par groupes de la taille que vous choisissez. Après chaque vague, vous pouvez continuer, vous arrêter, ou revenir en arrière : une migration redevient une série de décisions réversibles plutôt qu'un pari.

Le mécanisme : une autorité, un relais

Un domaine n'a qu'un jeu d'enregistrements MX, donc un point d'entrée. Tout découle de là.

Le système qui porte le MX est primaire, et il a trois obligations : connaître tous les destinataires du domaine, y compris ceux dont la boîte est ailleurs ; livrer localement ceux qu'il héberge ; relayer vers le second système ceux qu'il ne détient pas. Le secondaire fait le miroir : il accepte le courrier du domaine, livre ce qu'il héberge, renvoie au primaire ce qu'il ne connaît pas.

Deux conséquences se paient cash. Chaque compte doit exister des deux côtés, boîte réelle d'un côté, entrée de routage de l'autre ; un compte oublié dans cette double déclaration produit un rejet immédiat. Et un seul des deux systèmes peut attraper les inconnus : si les deux acceptent tout et se renvoient ce qu'ils ignorent, un message adressé à une boîte inexistante fait l'aller-retour jusqu'à épuisement des compteurs. La documentation de Zimbra le dit sans détour : « Primary needs to be authoritative, and if it forwards unknown accounts, then we would have a mail loop. »

Basculer un compte n'est alors qu'un changement de décision de routage : on dit au primaire « celui-là, tu le livres chez toi maintenant », ou l'inverse. Une opération par compte, immédiate, sans toucher au DNS. C'est exactement ce qui rend le retour arrière possible.

Comment Zimbra le fait

Zimbra documente le mécanisme sous le nom de Split Domain, avec deux leviers.

Le routage par compte : zimbraMailTransport. Sur le primaire, chaque compte porte un attribut qui dit où livrer son courrier. Pour un utilisateur encore sur l'ancien système : zmprov ma bar@example.com zimbraMailTransport smtp:mail.example.com:25. Une fois sa boîte migrée, le même attribut pointe la livraison locale : lmtp:zimbra.example.com:7025. Du point de vue du routage, une vague de migration est cette commande répétée sur les comptes du lot.

Le relais de domaine et le catch-all. Côté secondaire, on ne déclare pas les comptes un par un. Trois attributs posés sur le domaine font accepter toutes ses adresses et renvoyer au primaire ce qui n'est pas local : zimbraMailCatchAllAddress @example.com, zimbraMailCatchAllForwardingAddress @example.com, zimbraMailTransport smtp:mail.example.com. Le courrier sortant part par le primaire (zimbraMtaRelayHost), recherches DNS désactivées (zimbraMtaDnsLookupsEnabled FALSE).

Le catch-all appartient au secondaire, jamais au primaire : c'est la règle anti-boucle. Quand le second système est joignable par un nom interne, c'est ce nom qu'il faut utiliser, sous peine de faire sortir et rentrer le courrier par le pare-feu. Et le MX se change en dernier : « Change the public MX record to point to Zimbra last, after the configuration is tested. »

Réserve de méthode : cette page du wiki est une contribution communautaire marquée work in progress, vérifiée sur ZCS 8.0 et 8.6 ; recoupez ses commandes avec le guide d'administration de votre version.

L'équivalent côté Microsoft

Microsoft nomme la même chose un espace d'adressage SMTP partagé, et tout tient au type du domaine accepté. Un domaine Authoritative : « Email is delivered to email addresses that are listed for recipients in Microsoft 365 or Office 365 for this domain. Emails for unknown recipients are rejected. » Un domaine en Internal relay : « Email is delivered to known recipients in Office 365 or is relayed to your own email server if the recipients aren't known to Microsoft 365 or Office 365. »

Un domaine partagé est donc en internal relay, jamais en authoritative : la page consacrée au cas le motive par « an organization shares the same SMTP address space between two or more different email systems ». La commande est Set-AcceptedDomain -Identity contoso.com -DomainType InternalRelay.

Le relais ne fonctionne pas sans connecteurs : il en faut deux, un par sens, faute de quoi « recipients on the domain who are not hosted in Microsoft 365 or Office 365 won't be able to receive mail ». Vous perdez aussi le rejet des destinataires invalides, puisqu'en internal relay « the external email system is responsible for generating NDRs for unresolved recipients ». Le Directory-Based Edge Blocking, qui rejette au périmètre le courrier adressé à une boîte inexistante, suppose un domaine authoritative, et Microsoft donne la règle de transition sans ambiguïté : « Until all of your valid recipients have been added to Exchange Online […], you should leave the accepted domain configured as Internal relay. » Pendant toute la cohabitation, le filtrage par annuaire au périmètre est donc désactivé, et c'est le second système qui porte la charge des rejets. On repasse en authoritative à la fin, pas au milieu.

Ce qui marche, ce qui se dégrade

Le courrier circule très bien : c'est son métier. Réception et émission vers l'extérieur, courrier interne entre les deux systèmes, et même les invitations de réunion, qui voyagent comme des messages portant une pièce iCalendar : une invitation émise d'un côté s'accepte de l'autre. Ce qui souffre, c'est ce qui ne passe pas par SMTP.

Les disponibilités d'agenda : le point noir. Consulter le planning libre/occupé d'un collègue n'est pas un envoi de courrier mais une interrogation de serveur à serveur, qui ne traverse pas spontanément la frontière. Microsoft ne l'obtient entre deux de ses propres systèmes qu'à travers un déploiement hybride complet, avec relation d'organisation et approbation de fédération. Zimbra propose une passerelle vers Exchange (attributs globaux zimbraFreebusyExchange*, compte de service, zimbraForeignPrincipal posé sur chaque compte avec le préfixe ad:), mais les pages qui la décrivent sont archivées et vérifiées sur des versions anciennes. Posez en hypothèse de projet que les disponibilités seront dégradées pendant la cohabitation, et faites-en un critère de découpage des vagues plutôt qu'un chantier d'intégration.

Les listes de distribution à cheval. Une liste vit sur un système ; la livraison aux membres d'en face fonctionne, par relais. Ne traversent pas les droits d'envoi, la modération, les propriétaires. Les listes dynamiques non plus : construites par requête sur l'annuaire local, elles ne voient que les objets locaux, et Microsoft le documente pour son propre hybride, où les groupes dynamiques créés sur site ne se synchronisent pas et sont bloqués. Enfin, une liste déclarée des deux côtés livre deux fois.

Les alias sont la première cause de rejet après une vague, parce qu'aucun écran de synthèse ne les montre. Chaque alias publié est pourtant une adresse comme une autre : s'il n'est ni déclaré sur le système qui porte le MX, ni couvert par la règle de relais, il est rejeté.

Les dossiers et agendas partagés cassent plus silencieusement encore. Un montage pointe vers un compte sur un serveur donné : propriétaire resté derrière, utilisateur passé devant, et le montage ne résout plus. Il n'y a pas de correctif élégant, seulement un découpage de vagues qui garde ensemble les gens qui partagent.

Les délégations et les « envoyer en tant que » se perdent discrètement. Même dans un hybride Microsoft entièrement pris en charge, seules les permissions explicitement posées sur la boîte sont reprises : « Inherited (non-explicit) mailbox permissions […] are not migrated ». Et Send As demande des étapes supplémentaires. Entre deux systèmes différents, considérez-les comme à recréer et à tester.

Les règles côté serveur, elles, restent attachées à la boîte et suivent le compte. Deux effets de bord : une règle qui classe dans un dossier partagé devenu non résolvable échoue sans rien dire, et les règles que le primaire applique à la livraison ne s'appliquent pas au courrier qu'il relaie, puisque c'est l'autre système qui livre.

Deux réglages se tiennent au niveau global. L'annuaire d'abord : gardez-le sur un seul système, comme le recommande Zimbra, avec une interrogation déléguée depuis l'autre, car deux annuaires actifs produisent des doublons. L'authentification de l'émetteur ensuite : deux systèmes émettent pour le même domaine, donc SPF doit autoriser les deux chemins de sortie, et une clé DKIM doit exister de chaque côté avec son sélecteur, avant la première vague.

Le déroulé : des vagues, et un chemin de retour

Découpez sur le graphe des partages, pas sur l'organigramme. La bonne vague n'est pas une direction : c'est un ensemble de personnes qui partagent entre elles agendas, dossiers et boîtes fonctionnelles. Extrayez ces partages avant de dessiner le plan ; c'est le seul découpage qui évite les montages cassés.

Avant chaque vague, vérifiez que les comptes du lot et tous leurs alias existent des deux côtés, que les listes dont ces comptes sont membres ou propriétaires sont recensées, que les partages du lot sont documentés avec leurs bénéficiaires, et qu'une boîte de test du lot reçoit et émet depuis l'extérieur. Après chaque vague, dans l'heure : un envoi et une réception depuis l'extérieur sur chaque alias du lot, un rendez-vous accepté dans les deux sens, un partage ouvert, une liste critique testée, la file du serveur de courrier vide.

Le retour arrière, lui, se prépare avant la première vague. Repointer le routage du compte vers l'ancien système rétablit la livraison en quelques minutes, mais le courrier reçu depuis la bascule est resté sur la nouvelle plateforme, et le rapatrier suppose une synchronisation en sens inverse. D'où deux règles : gardez l'ancienne boîte intacte et en lecture seule, et dimensionnez les vagues pour qu'un retour arrière complet tienne dans une matinée. Une vague dont vous ne sauriez pas revenir est trop grosse.

Quand ne pas partager le domaine

Quand tout le domaine tient dans une vague. Du routage à configurer, des comptes à déclarer deux fois, le filtrage au périmètre désactivé, deux consoles à administrer : pour un domaine qui bascule entièrement en une opération, cette plomberie est un risque ajouté, pas un risque retiré.

Quand le second système ne sait pas relayer les inconnus, aussi. Le mécanisme repose entièrement sur cette capacité, que la documentation de Zimbra pose en préalable. À vérifier avant de planifier, pas pendant.

Quand le graphe des partages n'est pas découpable. Certaines organisations partagent tout avec tout le monde : agendas de direction, boîtes collectives, délégations croisées. Aucune vague n'y est propre, et chaque semaine de cohabitation est une semaine de fonctions dégradées pour tous. Une bascule courte et préparée, avec permanence sur place, est alors plus honnête qu'une longue cohabitation.

Dernier cas, le plus gênant : un ancien système en fin de vie. Le partage de domaine le laisse dans le chemin du courrier entrant pendant toute la durée du projet. S'il ne reçoit plus de correctifs de sécurité, la cohabitation prolonge exactement l'exposition que la migration devait fermer. Elle reste possible, mais avec le nouveau système en primaire, et l'ancien retiré du chemin d'entrée au plus tôt.

Et si vous êtes soumis à une obligation d'archivage ou de journalisation : pendant la cohabitation, la capture est répartie sur deux systèmes et deux journaux. Une collecte exhaustive en un point unique est alors un prérequis du plan de vagues, pas une surprise de recette.

Sources

Toutes les pages ont été consultées le 8 novembre 2026.

Zimbra

• Split Domain, wiki Zimbra, KB 1293 : rôles primaire et secondaire, zimbraMailTransport, zimbraMailCatchAllAddress, zimbraMailCatchAllForwardingAddress, zimbraMtaRelayHost, boucle de courrier, ordre de bascule du MX, provisionnement des deux côtés, annuaire global sur un seul système. Contribution communautaire marquée work in progress, vérifiée sur ZCS 8.0 et 8.6 ; prise en charge complète annoncée depuis ZCS 8.5.
• Free Busy Interop for Exchange, wiki Zimbra : attributs zimbraFreebusyExchange*, zimbraForeignPrincipal et préfixe ad:. Page archivée, vérifiée sur ZCS 5.0.3, 6.0 et 7.0.
• Exchange 2010 Free/Busy Interop et Exchange 2013 Free/Busy Interop, wiki Zimbra : variante EWS de la même passerelle.
• Zmprov, wiki Zimbra : syntaxe des commandes citées.

Microsoft

• Manage accepted domains in Exchange Online, Microsoft Learn : définitions Authoritative et Internal relay, obligation de connecteur, Set-AcceptedDomain.
• Set-AcceptedDomain, Microsoft Learn : responsabilité des rapports de non-livraison selon le type de domaine.
• Configure accepted domain for business unit with mailboxes outside your Exchange organization, Microsoft Learn : cas de l'espace d'adressage SMTP partagé, préalable sur l'enregistrement MX public.
• Set up connectors to route mail between Microsoft 365 or Office 365 and your own email servers, Microsoft Learn : deux connecteurs, un par sens ; ordre de sélection entre connecteurs.
• Use Directory-Based Edge Blocking to reject messages sent to invalid recipients, Microsoft Learn : conduite pendant une migration, groupes de distribution dynamiques bloqués, MX devant pointer vers le service.
• Exchange Server hybrid deployments, Microsoft Learn : espace de noms partagé, annuaire global unifié, partage des disponibilités, relation d'organisation et approbation de fédération, reprise des permissions de boîte.
• Shared free/busy in Exchange hybrid deployments, Microsoft Learn : partage des disponibilités entre les deux organisations.
• Enable mail flow for subdomains in Exchange Online, Microsoft Learn : le routage des sous-domaines exige un domaine en internal relay.

Oworks

• États et administrations : « Oworks et votre Zimbra partagent le même domaine ; les comptes basculent à votre rythme. »