Adresse mail professionnelle avec votre domaine : migrer sans couper la messagerie

Qui gère le domaine, le DNS, la messagerie et le site web ?

Une migration de messagerie professionnelle repose sur plusieurs éléments qui peuvent être confiés à des prestataires différents. Le nom de domaine identifie l’organisation. La zone DNS contient les enregistrements qui orientent les services. Le fournisseur de messagerie héberge les boîtes, tandis que l’hébergement web sert le site. Je commence toujours par distinguer ces rôles et par repérer les accès administratifs nécessaires, sans demander les mots de passe dans un document de travail.

Cette séparation évite une erreur classique : croire qu’un changement de messagerie oblige à déplacer le site. Microsoft précise que la configuration d’un domaine pour Microsoft 365 n’impose pas de transférer le site utilisant ce même domaine. En revanche, Microsoft 365 demande de vérifier la propriété du domaine et d’ajouter les enregistrements DNS correspondant aux services activés. Je prépare donc la modification de la messagerie sans toucher aux entrées du site qui n’ont aucune raison de changer.

Je relève le registraire, l’hébergeur DNS, le fournisseur de messagerie actuel, l’hébergement du site et la personne capable de valider chaque changement. Une mauvaise configuration DNS peut interrompre la messagerie ou un autre service ; la migration doit donc rester bornée aux enregistrements compris et documentés. Si personne ne sait où la zone DNS est administrée, je résous d’abord ce point au lieu d’improviser le jour de la bascule.

Quelles adresses et quels services envoient réellement des messages ?

La liste des salariés ou bénévoles ne suffit pas. J’inventorie les utilisateurs, les alias, les groupes, les boîtes partagées et les adresses de fonction. J’ajoute les appareils et applications qui utilisent encore l’ancienne messagerie : téléphone, logiciel de facturation, formulaire du site, scanner, imprimante ou outil de réservation lorsqu’ils envoient effectivement des courriels au nom du domaine. Cette cartographie évite qu’un expéditeur discret soit oublié.

Je distingue ce qui reçoit, ce qui envoie et ce qui sert seulement de redirection. Pour chaque élément, je note un responsable, les destinataires utiles et le besoin après migration, sans enregistrer de mot de passe. Une adresse ancienne peut encore alimenter un formulaire ou recevoir des factures. La supprimer parce qu’elle semble inactive dans la boîte principale peut donc couper un processus réel.

Cet inventaire devient également la base de l’authentification du domaine. Microsoft indique qu’un enregistrement SPF identifie les sources autorisées à envoyer au nom du domaine et que tous les services d’envoi réels doivent être recensés avant de le construire. Je refuse donc un modèle SPF générique copié d’un autre domaine : une valeur correcte dépend des expéditeurs effectivement conservés.

• utilisateurs, alias, groupes et boîtes partagées ;
• formulaires, logiciels, appareils et services expéditeurs ;
• adresses de récupération et responsables de chaque boîte ;
• éléments à conserver, remplacer ou retirer après vérification.

Que faut-il sauvegarder et préparer avant la bascule ?

Avant de modifier le DNS, je documente les enregistrements existants et les réglages utiles de l’ancienne messagerie. Je définis avec la structure quelles données doivent être conservées : messages, dossiers, contacts, calendriers et éventuelles boîtes partagées. La méthode de sauvegarde ou de transfert dépend des services concernés ; je ne promets pas qu’un export couvre tout sans l’avoir vérifié et relu.

Je crée ensuite toutes les boîtes nécessaires chez le nouveau fournisseur, avec leurs alias et groupes prévus. Microsoft indique explicitement que, pour une migration vers Microsoft 365, les utilisateurs et leurs boîtes doivent exister avant la bascule du MX. Chaque personne doit pouvoir se connecter au nouvel environnement et connaître sa méthode d’authentification avant que les nouveaux messages n’y arrivent.

Je prépare un tableau de contrôle qui ne contient aucun secret : adresse, type de boîte, propriétaire, appareil à reconfigurer, source d’envoi associée et résultat du test. Pour une TPE, une association ou un gîte en Dordogne, ce document simple vaut mieux qu’une bascule improvisée pendant une période d’activité. Il permet aussi de distinguer une boîte non préparée d’un problème DNS.

Dans quel ordre modifier les enregistrements DNS et le MX ?

Je ne commence pas par le MX. Je vérifie d’abord le domaine selon la procédure du fournisseur, puis je prépare les enregistrements requis pour les services réellement activés. Les boîtes et les accès utilisateurs sont contrôlés avant la bascule. Microsoft explique que le changement de MX fait commencer l’arrivée des nouveaux messages dans Microsoft 365 : ce changement marque donc un point opérationnel, pas une simple formalité administrative.

Au moment prévu, je modifie uniquement les entrées documentées, puis je conserve une copie des valeurs précédentes et de l’heure de chaque action. Je ne supprime pas dans le même mouvement tout ce qui appartient à l’ancien service. Le plan indique quels éléments doivent rester temporairement disponibles pour contrôler la transition et lesquels ne seront retirés qu’après validation.

Le site web reste un contrôle séparé. Après chaque étape DNS importante, je vérifie que son adresse publique répond toujours et que les enregistrements qui le desservent n’ont pas été modifiés par erreur. Une migration réussie ne se résume pas à recevoir un message dans la nouvelle boîte : elle préserve aussi les autres services du domaine.

• documenter la zone actuelle ;
• vérifier le domaine et préparer les services ;
• créer et tester toutes les boîtes ;
• modifier le MX au moment prévu ;
• contrôler messagerie et site avant de retirer l’ancien service.

Comment adapter SPF, DKIM et DMARC aux vrais expéditeurs ?

SPF, DKIM et DMARC ne sont pas trois lignes universelles à copier. Microsoft précise que les enregistrements SPF d’un domaine personnalisé sont gérés chez le registraire ou l’hébergeur DNS. SPF décrit les sources d’envoi autorisées, mais Microsoft indique qu’il ne suffit pas seul et recommande également DKIM et DMARC. L’ANSSI recommande elle aussi d’utiliser conjointement ces trois mécanismes afin de contrôler l’authenticité des messages et de réduire le risque d’usurpation d’adresse.

Pour Microsoft 365, le domaine doit d’abord être ajouté et vérifié avant d’activer sa signature DKIM. Microsoft demande ensuite deux enregistrements CNAME. Je ne considère pas l’opération terminée parce qu’ils ont été saisis : la documentation demande d’attendre leur détection et de confirmer l’état de signature. Pour un autre fournisseur, je suis sa documentation officielle et je n’invente pas d’équivalence.

DMARC vérifie l’alignement entre le domaine visible de l’expéditeur et les résultats SPF ou DKIM. Microsoft demande de configurer SPF et DKIM pour les domaines et sous-domaines d’envoi avant d’appliquer DMARC. Il recommande un déploiement progressif, avec observation des rapports avant une politique de rejet. Une politique trop stricte appliquée sans inventaire ni test peut faire refuser des messages légitimes ; je commence donc par comprendre les sources observées au lieu de rechercher immédiatement la règle la plus sévère.

Quels tests confirment la réception, l’envoi et la continuité du site ?

Je teste plusieurs chemins au lieu d’envoyer un seul message à moi-même. Une adresse extérieure écrit à chaque type de boîte ; les utilisateurs répondent vers l’extérieur ; les alias, groupes et boîtes partagées sont vérifiés selon leur usage. Les formulaires et services expéditeurs recensés sont contrôlés séparément. Chaque résultat est associé à l’adresse et au service concernés pour éviter de conclure trop vite que « tout fonctionne ».

Je vérifie l’authentification avec les outils et états fournis par les services concernés, sans publier dans l’article des valeurs propres au domaine. Si un compte Microsoft présente déjà des signes de compromission, une migration DNS ne suffit pas à le sécuriser : la procédure de reprise de contrôle d’un compte Microsoft piraté doit être traitée depuis un appareil fiable avant de réutiliser les accès.

Je contrôle aussi le site public, ses formulaires et les appareils qui doivent continuer à envoyer. Si une personne demande une prise en main distante pour corriger la messagerie, je conserve la même prudence que pour toute assistance : après un accès suspect, le guide sur le faux support informatique et l’accès à distance explique les vérifications à effectuer avant de confier de nouveaux identifiants à la machine.

Que surveiller après la migration et comment préparer le retour ?

La bascule n’est pas terminée dès que les premiers messages arrivent. Je garde une période de surveillance avec une liste des tests réussis, des appareils reconfigurés et des expéditeurs encore à confirmer. Les retours des utilisateurs sont comparés à l’inventaire initial : une absence de message peut venir d’une boîte oubliée, d’un service d’envoi non recensé ou d’une règle qui demande encore une vérification.

Les rapports DMARC sont observés avant de renforcer la politique, conformément à l’approche progressive recommandée par Microsoft. Je ne promets jamais une migration sans aucune interruption : l’objectif réaliste est de préparer, tester, observer et disposer d’éléments suffisants pour diagnostiquer rapidement. Les anciens réglages ne sont retirés qu’après confirmation des fonctions attendues et selon le calendrier établi avec le responsable du domaine.

Le plan de retour décrit les valeurs DNS précédentes, les accès administratifs nécessaires, la décision qui déclencherait un retour et la personne autorisée à l’effectuer. Il ne garantit pas que toute situation sera instantanément réversible, mais évite de chercher les informations essentielles sous pression. Pour une petite structure, je préfère une migration mesurée et documentée à une bascule rapide impossible à expliquer ensuite.