Après une migration Microsoft 365, les mails peuvent sembler fonctionner, mais la recette n’est pas terminée. Pour une PME de moins de 50 utilisateurs, il faut encore vérifier Exchange Online, Outlook, les DNS, les boîtes partagées, les mobiles, les scanners et les preuves fournies par le prestataire.
Une migration mail ne se clôture pas quand les boîtes sont copiées. Elle se clôture quand les flux entrants et sortants fonctionnent, que l’ancien système est maîtrisé, que les utilisateurs peuvent travailler et que la recette post-migration est documentée.
Réponse courte :
Après une migration Microsoft 365, vérifiez les DNS, MX, Autodiscover, SPF, DKIM, DMARC, les flux entrants et sortants, Outlook, Outlook Web, les mobiles, les licences, les boîtes partagées, les alias, les groupes, les scanners, les logiciels métiers, l’ancien hébergeur et le rapport de recette.
Votre PME vient de migrer ses mails vers Microsoft 365, mais vous voulez vérifier que tout est réellement terminé ? Axorys peut contrôler les DNS, Outlook, les flux Exchange Online, les boîtes partagées, les alias, les groupes, les scanners, les anciens services mail et les preuves de recette.
Une migration mails vers Microsoft 365 consiste souvent à déplacer les boîtes vers Exchange Online. Mais ce transfert n’est qu’une partie du projet.
Microsoft décrit notamment des étapes post-migration comme l’attribution des licences, la configuration du domaine pour router les emails vers Microsoft 365, la vérification du routage, puis la suppression du lot de migration quand tout est validé. (Microsoft Learn)
Dans une PME, les incidents apparaissent souvent après la bascule : un utilisateur reçoit ses mails, mais pas son mobile ; Outlook Web fonctionne, mais Outlook classique ne se reconnecte pas, facturation@ n’a pas été testé, le scanner envoie encore via l’ancien SMTP…
La bonne question n’est donc pas : “Les boîtes sont-elles copiées ?”
La bonne question est : “Tout ce qui dépendait de l’ancienne messagerie fonctionne-t-il maintenant dans Microsoft 365 ?”
Dans une petite entreprise sans DSI interne, cette première checklist permet de voir rapidement si la migration est réellement stabilisée.
| Point à vérifier | Pourquoi c’est important | Preuve attendue |
|---|---|---|
| MX | Les mails doivent arriver chez Microsoft 365 | Capture DNS ou test public |
| Autodiscover | Outlook doit retrouver Exchange Online | Test Outlook / profil neuf |
| SPF | Microsoft 365 doit être autorisé à envoyer | Enregistrement TXT vérifié |
| DKIM | Les emails sortants doivent être signés | DKIM actif sur domaine |
| DMARC | La politique doit être cohérente | Enregistrement TXT contrôlé |
| Outlook Web | La boîte doit fonctionner en cloud | Test utilisateur réussi |
| Outlook classique | Les postes doivent se reconnecter | Test sur plusieurs profils |
| Mobiles | Les utilisateurs doivent recevoir sur smartphone | Test iOS / Android si utilisé |
| Boîtes partagées | Facturation, contact, support doivent fonctionner | Test réception et envoi |
| Alias / groupes | Les adresses secondaires doivent recevoir | Test par adresse |
| Scanners / CRM / ERP | Les envois métiers doivent repartir | Test réel avec destinataire |
| Ancien hébergeur | Il ne doit plus recevoir de nouveaux mails | Vérification MX et boîtes |
| Recette | Le projet doit être documenté | Rapport ou ticket de validation |
Cette checklist ne remplace pas une analyse technique, mais elle évite de clôturer une migration trop tôt.
Les DNS sont les enregistrements qui indiquent comment utiliser votre domaine. Après une migration mail, ils doivent pointer correctement vers Microsoft 365.
Le MX indique où livrer les emails entrants. Autodiscover aide Outlook à trouver automatiquement Exchange Online. SPF indique quels serveurs sont autorisés à envoyer des emails pour le domaine. Microsoft indique que les trois enregistrements principaux pour Exchange Online sont Autodiscover, MX et SPF. (Microsoft Learn)
| Enregistrement DNS | Rôle post-migration | À vérifier |
|---|---|---|
| MX | Route les emails entrants vers Microsoft 365 | L’ancien MX n’est plus prioritaire |
| Autodiscover | Aide Outlook à configurer Exchange Online | CNAME correct vers Microsoft |
| SPF | Autorise Microsoft 365 à envoyer | Microsoft 365 et services tiers inclus |
| DKIM | Signe les emails sortants | Domaine ajouté et DKIM activé |
| DMARC | Définit la politique si SPF/DKIM échouent | Politique adaptée au niveau de maîtrise |
| Ancien DNS mail | Peut encore recevoir ou perturber | À supprimer ou rendre non prioritaire |
Microsoft documente aussi la configuration DKIM pour les domaines personnalisés Microsoft 365. DKIM doit être vérifié après migration, surtout si l’entreprise veut réduire les problèmes d’authentification email. (Microsoft Learn)
Il ne faut pas transformer cette vérification en guide complet de délivrabilité. L’objectif est plus simple : s’assurer que les mails entrent et sortent correctement via Exchange Online. Pour un diagnostic plus détaillé SPF, DKIM et DMARC, consultez l’article emails Microsoft 365 qui n’arrivent pas.
Une migration peut sembler terminée alors que certains comptes n’ont pas la bonne licence, qu’une boîte n’a pas été migrée, ou qu’un utilisateur exclu a été oublié.
Microsoft documente l’attribution et le retrait de licences Microsoft 365 depuis le centre d’administration Microsoft 365. Les licences doivent être contrôlées après migration, car une boîte Exchange Online dépend du bon service activé. (Microsoft Learn)
| Élément | Test à faire | Risque si oublié |
|---|---|---|
| Utilisateur actif | Compte présent dans Microsoft 365 admin center | Utilisateur sans accès |
| Licence Exchange | Licence attribuée avec Exchange Online actif | Boîte inaccessible |
| Boîte migrée | Boîte visible et utilisable dans Exchange Online | Données manquantes |
| Compte exclu | Liste validée des comptes non migrés | Ancienne boîte oubliée |
| Calendrier | Rendez-vous visibles | Perte d’usage quotidien |
| Contacts | Contacts disponibles | Perturbation commerciale |
| Annuaire global | Recherche de collègues fonctionnelle | Difficulté d’envoi interne |
| Ancien utilisateur | Compte désactivé ou traité | Risque d’accès ou de mails perdus |
Pour une structure de 10 à 20 postes, il faut tester chaque profil clé : direction, comptabilité, commercial, support, accueil, facturation. Ne testez pas uniquement la boîte du dirigeant.
Outlook Web est le test le plus simple. Si Outlook Web fonctionne, la boîte Exchange Online est accessible côté cloud. Si Outlook classique ne fonctionne pas, le problème vient souvent du poste, du profil Outlook, d’Autodiscover ou du cache.
| Test | Objectif | Résultat attendu |
|---|---|---|
| Outlook Web | Vérifier l’accès cloud | Connexion, réception, envoi OK |
| Outlook classique | Vérifier le poste utilisateur | Profil connecté à Exchange Online |
| Nouveau profil Outlook | Tester une configuration propre | Autodiscover trouve la boîte |
| Mobile iOS | Vérifier réception et envoi | Mails, calendrier, contacts OK |
| Mobile Android | Vérifier réception et envoi | Mails, calendrier, contacts OK |
| Calendrier partagé | Vérifier usage quotidien | Accès et mises à jour OK |
| Pièces jointes | Tester flux réel | Envoi et réception OK |
| Recherche Outlook | Vérifier expérience utilisateur | Résultats cohérents |
Si Outlook ne se reconnecte pas, l’article Outlook ne se connecte plus à Exchange Online traite le dépannage sans mélanger le sujet avec la recette globale de migration.
Si Autodiscover semble en cause, consultez aussi Autodiscover Exchange Online et Outlook.
Message Trace permet de suivre les emails dans Exchange Online. C’est l’un des meilleurs moyens de savoir si un message a été reçu, livré, rejeté ou différé.
Microsoft indique que Message Trace permet aux administrateurs de suivre les messages lorsqu’ils passent par le service cloud, et de savoir si un message ciblé a été reçu, rejeté, différé ou livré. (Microsoft Learn)
À vérifier après migration :
Message Trace ne doit pas être utilisé seulement quand tout va mal. Il doit aussi servir de preuve de recette : “ce message est bien passé par Exchange Online”.
Les boîtes utilisateur principales sont souvent testées. Les oublis concernent plutôt les adresses collectives.
Une PME peut fonctionner avec des adresses comme contact@, facturation@, direction@, support@, rh@ ou compta@. Si elles sont oubliées, la migration est incomplète.
| Élément | Ce qu’il faut tester | Exemple |
|---|---|---|
| Boîte partagée | Réception, accès, envoi | facturation@ |
| Alias | Réception vers la bonne boîte | contact@ vers nom@ |
| Groupe de distribution | Tous les membres reçoivent | equipe@ |
| Groupe Microsoft 365 | Membres et droits corrects | projet@ |
| Redirection | Justification métier validée | ancien@ vers nouveau@ |
| Send As | Envoi au nom de la boîte | facturation@ |
| Send on Behalf | Envoi pour le compte de | assistante vers direction |
| Droits d’accès | Membres autorisés uniquement | comptabilité, RH, support |
Pour les droits et usages détaillés, consultez l’article boîte mail partagée Exchange Online PME.
Le test doit être réel : envoyer un message externe vers chaque adresse collective, puis répondre depuis l’adresse attendue.
Beaucoup de migrations échouent partiellement à cause des envois applicatifs.
Un scanner multifonction, un CRM, un ERP, un logiciel de facturation ou un site web peut continuer à utiliser l’ancien serveur SMTP. Résultat : les emails des utilisateurs fonctionnent, mais les factures, scans, devis ou formulaires ne partent plus.
Microsoft rappelle que SPF doit inclure les sources d’envoi autorisées. Si des services tiers envoient au nom du domaine, ils doivent être pris en compte dans la configuration du domaine. (Microsoft Learn)
| Source d’envoi | Test à faire | Point de vigilance |
|---|---|---|
| Scanner multifonction | Scan vers email interne et externe | Ancien SMTP encore configuré |
| CRM | Envoi devis ou notification | SPF ou connecteur |
| ERP / compta | Facture envoyée | Authentification du domaine |
| Site web | Formulaire contact | SMTP ou service transactionnel |
| Outil newsletter | Campagne test | Ne pas mélanger avec délivrabilité marketing |
| Logiciel métier | Notification automatique | Compte ou relais sécurisé |
| Application interne | Alerte ou email automatique | Compte autorisé et suivi |
| Copieur ancien | Test vers client externe | Méthode compatible Microsoft 365 |
Ne basculez pas tout en SMTP AUTH sans réflexion sécurité. Selon le contexte, un connecteur ou une méthode d’envoi plus adaptée peut être nécessaire.
L’ancien hébergeur ne doit pas être coupé immédiatement après la migration. Il peut encore contenir des boîtes oubliées, des redirections, des archives ou des comptes secondaires.
Le bon réflexe consiste à conserver l’accès quelques jours si possible, le temps de vérifier les flux et de traiter les points restants.
| Ancien service | À vérifier avant fermeture |
|---|---|
| Anciennes boîtes | Plus aucun mail actif |
| Redirections | Recréées ou supprimées |
| Alias | Repris dans Microsoft 365 |
| DNS | Plus prioritaire pour le mail |
| Archives | Exportées ou conservées selon besoin |
| Facturation | Résiliation planifiée |
| Accès admin | Conservé le temps de validation |
| Contrat fournisseur | Conditions de fermeture connues |
Ce point concerne autant une migration depuis OVH qu’une migration depuis Google Workspace, mais l’objectif ici n’est pas de refaire ces procédures. Pour ces cas spécifiques, consultez migration OVH vers Exchange Online ou migration Google Workspace vers Exchange Online.
Une migration mail est aussi un bon moment pour corriger les bases de sécurité. Le but n’est pas de refaire tout l’audit Microsoft 365, mais de vérifier les points minimaux.
À contrôler :
Pour approfondir cette partie, consultez les articles MFA Microsoft 365 en PME, comptes admin Microsoft 365 et Secure Score Microsoft 365 PME.
Si un incident Microsoft 365 est suspecté pendant la période de stabilisation, le sujet Service Health doit rester séparé. Voir Service Health Microsoft 365 et prestataire.
Une recette se fait dans le temps. Certains problèmes apparaissent le jour même. D’autres remontent après quelques jours, quand les utilisateurs reprennent leurs habitudes.
| Moment | Contrôles prioritaires | Objectif |
|---|---|---|
| Jour J | MX, réception, envoi, Outlook Web, Outlook classique | Vérifier que les mails fonctionnent |
| J+1 | Mobiles, boîtes partagées, alias, groupes | Corriger les oublis visibles |
| J+7 | Scanners, CRM, ERP, site web, Message Trace | Stabiliser les usages métier |
| J+30 | Ancien hébergeur, sécurité, documentation, support | Clôturer proprement la migration |
Ce planning évite deux extrêmes : considérer la migration terminée trop tôt, ou laisser le projet ouvert sans décision claire.
Dans une TPE/PME où l’informatique est souvent gérée à temps partiel, ces erreurs viennent rarement d’un manque de sérieux. Elles viennent surtout d’une recette trop courte ou mal documentée.
Erreurs courantes :
Une migration réussie n’est pas une migration sans aucun ajustement. C’est une migration où les ajustements sont identifiés, traités et documentés.
Une recette post-migration doit laisser des traces. Sans preuves, il devient difficile de savoir ce qui a été validé ou ce qui reste à corriger.
Preuves utiles à demander :
Ces preuves sont utiles même si tout fonctionne. Elles évitent de redécouvrir le projet six mois plus tard, quand un ancien compte, un alias ou un scanner pose problème.
Lors de reprises de migrations Microsoft 365, nous voyons souvent des boîtes utilisateurs fonctionnelles, mais des boîtes partagées, alias ou scanners encore oubliés.
Chez certaines PME, la migration semble terminée parce qu’Outlook reçoit des mails, alors que le SPF, DKIM ou Autodiscover ne sont pas encore correctement finalisés.
Nous avons déjà vu des anciens hébergeurs mail coupés trop vite, avant de vérifier les redirections, les archives ou les comptes secondaires.
Un cas fréquent : les dirigeants testent leur boîte principale, mais personne ne teste facturation@, contact@ ou les envois du logiciel de devis.
Notre approche consiste à clôturer une migration seulement après recette : flux mail, DNS, utilisateurs, mobiles, groupes, applications, sécurité et preuves.
Pour une PME, la différence entre une migration réussie et une migration stressante tient souvent à une checklist claire et à un support présent pendant la phase de stabilisation.
| Action | PME | Prestataire | Microsoft |
|---|---|---|---|
| Valider les utilisateurs à migrer | Responsable | Appui | Non concerné |
| Configurer DNS | Validation | Responsable | Documentation / plateforme |
| Tester mails entrants / sortants | Appui métier | Responsable | Service Exchange Online |
| Tester Outlook / mobiles | Responsable utilisateur | Appui | Service Microsoft 365 |
| Vérifier boîtes partagées | Responsable métier | Responsable technique | Non concerné |
| Vérifier scanners / SMTP | Appui métier | Responsable technique | Documentation |
| Vérifier Service Health | Appui | Responsable | Publie l’état des services |
| Documenter la recette | Validation | Responsable | Non concerné |
| Fermer l’ancien service | Validation | Appui | Non concerné |
| Assurer support post-migration | Responsable besoin | Responsable si mandat | Support plateforme selon contrat |
La PME valide les usages et les priorités métier. Le prestataire configure, teste et documente. Microsoft fournit Exchange Online, Microsoft 365 et les informations de service.
Une migration doit être validée ou corrigée si certains points restent flous après la bascule.
Déclencheurs fréquents :
Pour une entreprise qui utilise Microsoft 365 au quotidien sans administrateur dédié, une migration mail doit se terminer par une recette lisible. Un prestataire peut reprendre les points bloquants, vérifier les DNS, tester les flux et documenter ce qui reste à corriger.
La page migration mails vers Microsoft Exchange permet de faire valider ou corriger une migration Microsoft 365 déjà réalisée.
Si la checklist révèle un besoin de suivi régulier après migration, l’infogérance Microsoft 365 peut aussi cadrer le support, les preuves, les incidents et les revues périodiques.
Pour replacer cette checklist dans une vision plus large, consultez le guide principal sur Microsoft 365 en PME de moins de 50 utilisateurs ou l’ensemble des guides Microsoft 365 en PME.
Après une migration Microsoft 365, il faut vérifier les DNS, le routage mail, Outlook, Outlook Web, les mobiles, les licences, les boîtes partagées, les alias, les groupes, les scanners, les logiciels métiers, l’ancien hébergeur et les preuves de recette.
Une migration peut être considérée comme terminée lorsque les mails entrants et sortants fonctionnent, que les utilisateurs accèdent à leurs boîtes, que les DNS sont corrects, que les boîtes partagées et applications d’envoi sont testées, et qu’un rapport de recette existe.
Le MX route les emails vers Microsoft 365. Autodiscover aide Outlook à trouver automatiquement Exchange Online. Microsoft indique que MX, Autodiscover et SPF font partie des enregistrements DNS essentiels pour Exchange Online. (Microsoft Learn)
Utilisez Message Trace dans l’Exchange admin center. Microsoft indique que Message Trace permet de suivre les messages dans Microsoft 365 et de voir leur statut : livré, rejeté, différé ou reçu. (Microsoft Learn)
Non, pas trop vite. Il faut d’abord vérifier que les MX pointent vers Microsoft 365, que les anciennes boîtes ne reçoivent plus de messages, que les alias et redirections sont repris, et que les archives ou exports nécessaires sont conservés.
Parce qu’ils peuvent continuer à utiliser l’ancien serveur SMTP ou un compte non migré. Après migration, il faut tester les envois depuis scanners, CRM, ERP, logiciel de facturation et site web, puis vérifier SPF ou la méthode d’envoi retenue.
Demandez la liste des boîtes migrées, les tests entrants et sortants, les captures DNS, les tests Outlook, les résultats Message Trace, les boîtes partagées, les alias, les groupes, les applications SMTP testées, les incidents restants et la date prévue de fermeture de l’ancien service.
Contactez un prestataire si Outlook ne se reconnecte pas, si certains mails n’arrivent pas, si les boîtes partagées ou scanners ne fonctionnent plus, si les DNS sont incertains, si l’ancien hébergeur est encore actif, ou si aucune recette post-migration n’a été fournie.
Une migration Microsoft 365 ne s’arrête pas à la copie des boîtes. Elle doit être validée par une recette claire : DNS, flux mails, Outlook, mobiles, boîtes partagées, alias, groupes, scanners, logiciels métiers, ancien hébergeur, sécurité minimale et preuves.
Pour une PME, cette checklist évite les mauvaises surprises après la bascule. Elle permet de distinguer ce qui fonctionne, ce qui reste à corriger et ce qui doit être surveillé pendant la stabilisation.
L’ancien service mail ne doit être fermé qu’après validation. Les accès, les exports et les preuves doivent être conservés. C’est ce qui transforme une migration “techniquement faite” en migration réellement terminée.
Votre PME vient de migrer ses mails vers Microsoft 365, mais vous voulez vérifier que tout est réellement terminé ? Axorys peut contrôler les DNS, Outlook, les flux Exchange Online, les boîtes partagées, les alias, les groupes, les scanners, les anciens services mail et les preuves de recette.