Changer de plateforme mail, c’est rarement anodin. Quand une entreprise décide de quitter OVH pour Google Workspace, elle s’expose à un moment critique : celui où les enregistrements MX basculent, et où le moindre mauvais paramétrage peut faire disparaître des emails entrants dans la nature. Le Split Delivery existe précisément pour éviter ce scénario.
Le principe repose sur une transition progressive, adresse par adresse, sans jamais couper le fil. Google Workspace reçoit tous les emails entrants du domaine, identifie ceux qui correspondent à des comptes déjà migrés, et renvoie les autres vers le serveur OVH d’origine. Résultat : les utilisateurs non encore migrés continuent de recevoir leurs messages normalement, sans même savoir qu’une migration est en cours.
Comprendre le Split Delivery avant de se lancer
Le Split Delivery n’est pas une fonctionnalité cachée ou réservée aux experts. C’est une option de routage disponible dans la console d’administration Google Workspace, conçue pour les contextes où plusieurs systèmes de messagerie coexistent temporairement sur un même domaine. Comprendre son fonctionnement précis avant de toucher quoi que ce soit est la condition sine qua non d’une migration OVH vers Gmail qui se passe bien.
C’est quoi le Split Delivery ?
Le Split Delivery, littéralement “livraison partagée”, est un mode de routage des emails entrants dans lequel Google Workspace joue le rôle de point d’entrée unique pour l’ensemble du domaine, tout en déléguant la distribution de certains messages à un autre serveur de messagerie. Concrètement, dès que les enregistrements MX pointent vers Google, c’est lui qui reçoit tout. Il ne garde que ce qu’il reconnaît.
Pour les adresses qui existent déjà dans la console d’administration Google Workspace, le message est distribué normalement dans Gmail. Pour toutes les autres, celles dont le compte n’a pas encore été créé côté Google, le message est automatiquement renvoyé vers le serveur défini comme hôte secondaire : dans le cadre d’une migration OVH vers Gmail, cet hôte sera mx1.mail.ovh.net sur le port 25. Ce mécanisme est transparent pour les expéditeurs comme pour les destinataires, sans message d’erreur, sans notification, le routage se fait en coulisses.
Pourquoi éviter une bascule brutale ?
Basculer tous les MX d’un domaine vers Google Workspace en une seule opération, sans avoir préalablement créé tous les comptes utilisateurs, c’est prendre un risque réel et mesurable. Tout email entrant destiné à une adresse non encore provisionnée dans Google sera rejeté ou renvoyé en erreur. Sur un domaine actif, avec des dizaines de boîtes, cette fenêtre de risque peut durer plusieurs heures, le temps de tout créer, configurer et vérifier.
La bascule brutale pose aussi un problème de propagation DNS. Les enregistrements MX peuvent mettre jusqu’à 48 heures à se propager complètement selon les TTL en place. Pendant cette période, certains serveurs expéditeurs enverront encore vers OVH, d’autres vers Google. Le Split Delivery supprime cette contrainte de synchronisation parfaite : la migration OVH vers Gmail peut s’étaler sur plusieurs jours, voire plusieurs semaines, sans pression, chaque utilisateur étant migré quand son compte est prêt et ses données transférées.
Quels prérequis techniques ?
Avant de configurer quoi que ce soit, il faut disposer d’un accès administrateur complet à deux environnements distincts : la console d’administration Google Workspace d’un côté, et le panneau de gestion DNS du domaine de l’autre, que ce soit via l’interface OVH ou un registrar tiers. La validation de propriété du domaine se fait via un enregistrement TXT à ajouter dans la zone DNS, une étape qui ne modifie pas les MX et n’impacte donc pas la distribution des emails en cours.
Côté OVH, il faut connaître l’adresse exacte du serveur de messagerie entrant, généralement mx1.mail.ovh.net, ainsi que le port utilisé pour les connexions SMTP entrantes, qui est le port 25 dans la grande majorité des configurations standard. Il est également conseillé de noter les valeurs TTL actuelles des enregistrements MX afin de les réduire avant la bascule et d’accélérer la propagation DNS le moment venu.
Préparer la migration OVH vers Gmail sans risque
Une migration réussie ne commence pas le jour où l’on touche aux MX. Elle commence bien avant, dans un travail de recensement et d’organisation qui conditionne tout ce qui suit. Identifier ce qui existe, ce qui est actif, ce qui est critique : c’est ce travail préparatoire qui transforme une opération à risque en processus maîtrisé.
Comment identifier les boîtes à migrer en priorité ?
Toutes les boîtes mail ne se valent pas. Certaines reçoivent des dizaines de messages par jour et sont utilisées par des personnes dont l’activité dépend directement de leur messagerie. D’autres sont des alias dormants, des adresses de contact générique ou des boîtes partagées consultées une fois par semaine. Faire cette distinction en amont permet de définir un ordre de migration logique, où les comptes les moins critiques servent de terrain d’apprentissage avant de toucher aux boîtes sensibles.
Un tableau simple suffit : nom de la boîte, volume estimé d’emails, fréquence d’utilisation, utilisateur associé, niveau de criticité. Ce recensement peut se faire en interrogeant directement les équipes ou en consultant les logs de connexion disponibles depuis l’interface OVH. Les boîtes sans connexion depuis plus de six mois méritent une attention particulière : elles peuvent souvent être archivées plutôt que migrées, ce qui allège considérablement le périmètre de l’opération.
Comment choisir une adresse de test ?
L’adresse de test est la première boîte à provisionner dans Google Workspace avant même que les MX ne basculent. Son rôle est de valider que le Split Delivery fonctionne correctement : une fois configuré, un email envoyé à cette adresse doit arriver dans Gmail, tandis qu’un email envoyé à n’importe quelle autre adresse du domaine doit continuer d’arriver dans OVH. C’est ce comportement précis qu’il faut vérifier avant d’aller plus loin.
Le choix de cette adresse n’est pas anodin. Il faut privilégier une boîte réelle mais peu critique, utilisée par une personne disponible pour confirmer la réception des messages de test. Une adresse comme test@domaine.fr créée spécifiquement pour l’occasion peut aussi faire l’affaire, à condition de la supprimer proprement une fois la validation terminée. L’essentiel est de ne jamais utiliser une boîte stratégique pour cette phase de test : si quelque chose ne fonctionne pas comme prévu, mieux vaut que ce soit sur un compte sans enjeu.
Quelles données sauvegarder avant tout ?
Avant de lancer quoi que ce soit, une sauvegarde complète des boîtes mail OVH s’impose. Pas parce que la migration va nécessairement mal se passer, mais parce qu’en cas de problème, disposer d’une copie locale des données permet de repartir de zéro sans perte. L’outil OVH Mail Migrator peut transférer les emails directement vers Google Workspace, mais cette opération ne constitue pas une sauvegarde : si le transfert échoue à mi-chemin ou que des messages sont corrompus, il faut avoir un filet de sécurité.
La méthode la plus fiable consiste à exporter les boîtes au format MBOX ou PST via un client mail comme Thunderbird ou Outlook, configuré en IMAP. Ce fichier local, stocké sur un disque externe ou un espace cloud indépendant d’OVH et de Google, constitue la garantie ultime que rien ne sera perdu. Les contacts et les événements de calendrier méritent le même traitement : un export vCard pour les contacts, un fichier ICS pour les agendas, conservés soigneusement avant toute manipulation.
Configurer le Split Delivery dans Google Workspace
La configuration du Split Delivery se passe intégralement dans la console d’administration Google Workspace. C’est une manipulation qui demande de la rigueur et un ordre précis dans les étapes : chaque réglage conditionne le suivant, et une erreur de paramétrage à ce stade peut entraîner des pertes de messages sans que l’utilisateur en soit averti.
Comment paramétrer la passerelle sortante OVH ?
La passerelle sortante, ou “outbound gateway”, est l’adresse du serveur OVH vers lequel Google Workspace va renvoyer les emails destinés aux utilisateurs non encore migrés. Elle se configure depuis la console d’administration, dans la section Apps, puis Google Workspace, puis Gmail, puis Paramètres avancés. Il faut chercher le champ “Passerelle sortante” et y saisir l’adresse du serveur SMTP d’OVH, généralement ssl0.ovh.net ou mx1.mail.ovh.net selon la configuration en place.
Ce réglage s’applique au niveau du domaine et affecte donc l’ensemble des utilisateurs de l’organisation. Il est essentiel de le mettre en place avant de modifier les enregistrements MX. Sans ce paramètre, les emails destinés aux boîtes non encore provisionnées dans Google Workspace seraient simplement rejetés, sans aucun message d’erreur visible pour l’expéditeur.
Comment créer les comptes utilisateurs dans Google ?
Chaque adresse email qui doit recevoir ses messages dans Google Workspace doit correspondre à un compte utilisateur provisionné dans la console d’administration. Tant qu’un compte n’existe pas dans Google, les emails qui lui sont destinés seront renvoyés vers OVH via la passerelle configurée. C’est ce mécanisme qui permet la coexistence des deux systèmes pendant toute la période de transition.
La création des comptes peut se faire manuellement depuis la console, un par un, ce qui convient pour les petites structures. Pour des organisations plus importantes, Google propose une importation en masse via un fichier CSV contenant les informations de chaque utilisateur. Un point d’attention : la création du compte dans Google ouvre une boîte vide, prête à recevoir les nouveaux messages, mais ne transfère pas les emails existants depuis OVH, qui reste une étape distincte.
Comment modifier les enregistrements MX ?
La modification des enregistrements MX est le moment où Google Workspace devient officiellement le point d’entrée de tous les emails du domaine. Cette étape se réalise depuis l’interface de gestion DNS, que ce soit directement chez OVH ou chez un registrar tiers. Les enregistrements MX d’OVH doivent être remplacés par ceux fournis par Google, dont le principal est aspmx.l.google.com avec une priorité de 1.
Avant d’effectuer ce changement, il est fortement recommandé de réduire le TTL des enregistrements MX existants à une valeur basse, comme 300 secondes, au moins une heure avant la bascule. Une fois les MX modifiés, la propagation peut prendre de quelques minutes à plusieurs heures. Le Split Delivery étant déjà en place, Google sait exactement quoi faire avec chaque message entrant : le distribuer dans la boîte Gmail correspondante si le compte existe, ou le relayer vers OVH dans le cas contraire.
Tester et valider le Split Delivery
Avant de considérer la configuration comme opérationnelle, une phase de test structurée est indispensable. Un Split Delivery mal validé peut laisser passer des erreurs silencieuses, où des emails sont perdus sans rebond apparent, ce qui est le scénario le plus difficile à détecter et le plus dommageable pour une organisation.
Comment modifier les MX temporairement ?
La modification temporaire des MX sert à simuler les conditions réelles de la bascule sans s’y engager définitivement. L’idée est de pointer les enregistrements MX vers Google Workspace le temps d’un test, tout en gardant la passerelle OVH active. Cette manipulation se fait depuis l’interface DNS du domaine, en remplaçant provisoirement les MX OVH par les MX Google, avec un TTL très court pour faciliter le retour en arrière si nécessaire.
Il est conseillé de réaliser ce test sur une plage horaire à faible trafic, en soirée ou le week-end, pour limiter l’impact d’un éventuel dysfonctionnement. Un compte test doit avoir été créé au préalable dans Google Workspace pour pouvoir vérifier concrètement le routage. Si ce compte reçoit bien les messages qui lui sont envoyés, et que les adresses non provisionnées reçoivent les leurs dans OVH, le Split Delivery fonctionne correctement.
Comment vérifier la réception des deux côtés ?
La vérification consiste à envoyer des emails vers deux types d’adresses : une adresse déjà provisionnée dans Google Workspace et une adresse qui existe uniquement dans OVH. Le premier message doit arriver dans la boîte Gmail, le second doit arriver dans la boîte OVH. Ce double test confirme que le routage fonctionne dans les deux sens et que la passerelle sortante joue bien son rôle de relais.
Les logs de Gmail sont un outil précieux à ce stade. Depuis la console d’administration Google, la section Rapports puis Audit puis Email permet de consulter l’historique des messages traités, avec le statut de chaque distribution. Du côté OVH, les logs du serveur SMTP peuvent confirmer la réception des messages relayés par Google. Croiser ces deux sources d’information donne une vision complète et fiable du comportement du système.
Que faire si le test échoue ?
Un échec du test se manifeste généralement de deux façons : soit un message rebondit avec une erreur explicite, soit il disparaît sans trace côté destinataire. Le rebond est plus facile à traiter car il contient un code d’erreur SMTP qui oriente directement vers la cause du problème. Un code 550 indique souvent que le compte destinataire n’existe pas dans Google et que la passerelle n’a pas pris le relais, ce qui pointe vers un problème de configuration de l’outbound gateway.
La disparition silencieuse est plus délicate à diagnostiquer. Il faut alors consulter les logs de la console Admin Google pour identifier à quel moment le message a été traité et vers où il a été routé. Une erreur fréquente à ce stade est une adresse de passerelle mal saisie, ou un serveur OVH qui refuse les connexions depuis les IP Google. Vérifier ces deux points résout la majorité des cas d’échec rencontrés lors de cette phase.
Migrer les données et finaliser la bascule
La migration des données est l’étape qui transforme le Split Delivery en transition complète. Une fois les emails historiques transférés et les MX définitivement basculés, OVH n’est plus dans la boucle. Cette phase demande une coordination précise entre les outils de migration, les DNS et les paramétrages d’authentification des emails.
Comment utiliser OVH Mail Migrator ?
OVH Mail Migrator, accessible à l’adresse omm.ovh.net, est l’outil proposé par OVH pour transférer le contenu des boîtes email vers une autre destination. Il fonctionne en IMAP et permet de migrer les emails, les dossiers, les contacts et les événements de calendrier selon les options choisies. Pour une migration vers Google Workspace, il faut renseigner les identifiants de la boîte source chez OVH et les identifiants de la boîte de destination chez Google.
L’outil propose deux modes : la migration simple pour une seule boîte, et la migration par lot pour traiter plusieurs adresses simultanément via un fichier CSV. Il est recommandé de lancer les migrations adresse par adresse dans un premier temps pour valider le bon fonctionnement avant de traiter l’ensemble du parc. La durée de la migration dépend du volume de données : une boîte de plusieurs gigaoctets peut prendre plusieurs heures, et il est possible de relancer une migration pour synchroniser les messages reçus entre-temps.
Comment basculer les MX définitivement ?
La bascule définitive des MX intervient une fois que toutes les boîtes ont été provisionnées dans Google Workspace et que les données ont été migrées. À ce stade, les enregistrements MX OVH sont remplacés par les enregistrements Google de manière permanente, et la passerelle sortante configurée précédemment peut être supprimée puisqu’elle n’a plus de raison d’être.
Le TTL des enregistrements DNS doit être remonté à une valeur standard après la bascule, généralement 3600 secondes, pour stabiliser la propagation. Il est conseillé de surveiller les logs Gmail pendant les 24 à 48 heures suivant la bascule pour s’assurer qu’aucun message n’est rejeté ou mal routé. Les anciennes boîtes OVH peuvent être conservées en lecture seule pendant quelques semaines, le temps de s’assurer qu’aucun email important n’y arrive encore.
Comment déployer SPF et DKIM après la migration ?
Le SPF, ou Sender Policy Framework, est un enregistrement DNS de type TXT qui liste les serveurs autorisés à envoyer des emails au nom du domaine. Après la migration vers Google Workspace, cet enregistrement doit être mis à jour pour inclure les serveurs Google et retirer les serveurs OVH. La valeur à utiliser est include:_spf.google.com, à intégrer dans l’enregistrement SPF existant ou à créer s’il n’existe pas encore.
Le DKIM, quant à lui, est une signature cryptographique ajoutée aux emails sortants pour prouver leur authenticité. Google Workspace génère une clé DKIM depuis la console d’administration, dans la section Gmail puis Authentification. Une fois la clé générée, elle doit être publiée sous forme d’enregistrement DNS TXT dans la zone du domaine. La vérification de ces deux enregistrements peut se faire via des outils en ligne comme MXToolbox, qui confirment en quelques secondes que SPF et DKIM sont correctement déployés et actifs.
