Une migration d'e-mails sur domaine depuis cPanel déplace les boîtes d'un hébergement cPanel groupé (Bluehost, HostGator, Hostinger ou équivalent) vers un hébergeur spécialisé sans perdre de courrier entrant pendant la bascule. La clé est la réception en parallèle : configurer le nouvel hébergeur pendant que l'ancien reçoit encore, puis modifier les enregistrements MX avec un TTL DNS faible afin que la transition dure quelques minutes plutôt que plusieurs heures.
La plupart des guides de migration depuis cPanel omettent la réception en parallèle et décrivent une bascule à froid susceptible de perdre des messages pendant la propagation DNS. Une bascule à froid perd généralement 10-50 messages selon le volume entrant. L'approche parallèle ci-dessous vise à éviter cette perte. La préparation supplémentaire prend 30 minutes et contribue à protéger ces messages.
Ce guide présente la bascule en six étapes avec des blocs de code pour les enregistrements DNS. Pour une vue plus large, consultez déplacer l'e-mail vers un nouvel hébergeur.
Pourquoi une migration cPanel propre est importante
Une migration propre est importante, car le courrier en transit pendant la propagation DNS représente un véritable risque commercial. Lors d'une bascule à froid avec une propagation de plusieurs heures, tout message arrivant sur l'ancien MX après l'arrêt de la réception est perdu. La plupart des responsables n'en mesurent le coût que lorsqu'un client se plaint.
La méthode en six étapes évite cette fenêtre de perte grâce à la réception en parallèle : l'ancien et le nouvel hébergeur reçoivent simultanément pendant la bascule, et le responsable déclenche manuellement la désactivation seulement après avoir confirmé que tout le courrier en transit est arrivé. Cette discipline supplémentaire demande 30 minutes de préparation et peut éviter une perte difficile à chiffrer.
La bascule en six étapes en bref
Six étapes couvrent la migration depuis cPanel avec réception en parallèle. Leur ordre est important : le résultat de chaque étape rend la suivante possible. Le délai total est d'environ une semaine, de la réduction du TTL à la désactivation complète ; le travail actif représente environ 3-4 heures réparties sur la semaine.
- Réduisez le TTL DNS 48 heures à l'avance. Cela ramène le délai de propagation du MX de plusieurs heures à quelques minutes pendant la bascule.
- Créez les boîtes chez le nouvel hébergeur. Créez des boîtes correspondantes tout en maintenant les anciennes en service.
- Copiez l'historique par IMAP. Un outil de migration IMAP côté serveur copie les messages existants des anciennes boîtes vers les nouvelles.
- Modifiez les enregistrements MX. Mettez le DNS à jour pour pointer vers le nouvel hébergeur ; les deux reçoivent pendant la propagation.
- Vérifiez l'authentification et le trajet aller-retour. Confirmez que SPF, DKIM et DMARC passent chez trois destinataires depuis le nouvel hébergeur.
- Désactivez les anciennes boîtes. Attendez 48-72 heures après le changement de MX, puis désactivez-les une fois le courrier en transit écoulé.
Chaque étape est un point de contrôle ; le retour en arrière reste simple jusqu'à l'étape 4 incluse. Après l'étape 4, le changement de MX, il reste possible, mais devient coûteux sur le plan opérationnel, car les messages commencent à s'accumuler chez le nouvel hébergeur. Une bascule standard ne devrait pas nécessiter de retour en arrière si les étapes 1-3 ont été correctement réalisées.
Étape 1 : réduire le TTL DNS 48 heures à l'avance
Réduisez le TTL DNS des enregistrements MX existants 48 heures avant la bascule prévue. Le TTL par défaut est généralement de 3600 secondes (1 heure) ou 86400 (24 heures). Réglez-le sur 300 secondes (5 minutes), afin que le changement de MX de l'étape 4 se propage en quelques minutes plutôt qu'en plusieurs heures.
La modification s'effectue dans le tableau de bord de l'hébergeur DNS. Modifiez la valeur TTL de chaque enregistrement MX, saisissez 300 et enregistrez. Attendez 48 heures pour que le TTL actuel expire et que la nouvelle valeur faible se propage. Après l'étape 6, remontez le TTL à 3600 pour le fonctionnement normal. Exemple de modification DNS dans Cloudflare :
; before: MX record with default TTL
yourcompany.com. 3600 IN MX 10 mail.oldhost.example.com.
; after: MX record with low TTL for migration window
yourcompany.com. 300 IN MX 10 mail.oldhost.example.com.
Étape 2 : créer les boîtes chez le nouvel hébergeur
Créez des boîtes correspondantes chez le nouvel hébergeur. Ajoutez le domaine dans TrekMail, vérifiez-en la propriété au moyen de l'enregistrement TXT et créez une boîte pour chaque adresse présente sur l'ancien hébergement cPanel. À ce stade, les nouvelles boîtes sont prêtes, mais le MX pointe toujours vers l'ancien hébergeur.
Générez les valeurs SPF, DKIM et DMARC fournies par le nouvel hébergeur. Ne les publiez pas encore ; cela se fera à l'étape 4 en même temps que le changement de MX. Les générer à l'avance garantit que les valeurs seront prêtes quand arrivera l'étape 4. Ce préprovisionnement rend possible la réception en parallèle ultérieure. Consultez migration IMAP pour les détails sur l'outil.
Étape 3 : copier l'historique par IMAP
Utilisez l'outil de migration IMAP du nouvel hébergeur pour copier le courrier historique des anciennes boîtes cPanel vers les nouvelles. L'outil côté serveur de TrekMail (Starter et offres supérieures) le fait depuis le tableau de bord : fournissez les identifiants IMAP de l'ancien hébergeur et laissez-le copier dossier par dossier pendant quelques heures.
La migration s'exécute en arrière-plan alors que le MX pointe encore vers l'ancien hébergeur. Celui-ci continue de recevoir les nouveaux messages ; le nouveau possède la copie historique. À la fin de la migration, les deux ont la même arborescence de dossiers et les mêmes messages, exactement l'état requis pour la bascule avec réception en parallèle de l'étape 4. Consultez liste de contrôle de migration d'e-mails pour une feuille de route structurée.
Étape 4 : modifier les enregistrements MX
La quatrième étape met à jour les enregistrements MX chez l'hébergeur DNS pour qu'ils pointent vers le nouvel hébergeur de boîtes. Publiez les nouvelles valeurs MX ainsi que les enregistrements SPF, DKIM et DMARC de l'étape 2. La propagation DNS prend environ 5 minutes grâce au faible TTL de l'étape 1. Pendant cette fenêtre, les deux hébergeurs reçoivent en parallèle.
; new MX records pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; published SPF, DKIM, DMARC TXT records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
La fenêtre de réception en parallèle évite l'intervalle habituel de perte. Tout message envoyé pendant la propagation arrive soit chez l'ancien hébergeur, toujours actif, soit chez le nouveau, qui vient d'être activé, plutôt que de rebondir dans un intervalle entre les deux. Maintenez les anciennes boîtes actives et accessibles pendant au moins 48 heures après le changement de MX afin de récupérer les derniers messages en transit.
Étape 5 : vérifier l'authentification et le trajet aller-retour
Vérifiez l'authentification des messages sortants depuis le nouvel hébergeur. Envoyez des messages de test depuis chaque nouvelle boîte vers des comptes Gmail, Outlook.com et Yahoo. Confirmez que les en-têtes indiquent SPF=PASS, DKIM=PASS et DMARC=PASS chez les trois. Tout FAIL signifie que les enregistrements publiés à l'étape 4 doivent être corrigés avant de considérer la bascule comme terminée.
Vérifiez également que les messages arrivent correctement chez le nouvel hébergeur. Envoyez un message de test depuis une adresse externe vers une nouvelle boîte et confirmez son arrivée dans la nouvelle boîte de réception en quelques minutes. S'il arrive chez l'ancien hébergeur, la propagation DNS n'est pas encore terminée ; attendez encore 10-15 minutes, puis recommencez le test.
Étape 6 : désactiver les anciennes boîtes
Désactivez les anciennes boîtes 48-72 heures après le changement de MX. À ce stade, la propagation DNS devrait être terminée mondialement et les expéditeurs ne devraient plus acheminer leurs messages vers l'ancien MX. Désactivez les anciennes boîtes dans le tableau de bord cPanel ; gardez l'abonnement cPanel actif pour le site si nécessaire, mais coupez la réception du courrier.
Si cPanel héberge aussi le site et que vous ne souhaitez plus payer ce service, c'est le moment de migrer le site vers un hébergeur web séparé. La migration d'e-mails depuis cPanel est terminée lorsque l'ancienne messagerie est désactivée et que le nouvel hébergeur reçoit correctement depuis plusieurs jours. Remontez le TTL DNS à 3600 secondes pour le fonctionnement normal.
Étapes suivantes
La migration depuis cPanel avec réception en parallèle prend environ une semaine de délai total et 3-4 heures de travail actif. Elle vise à éviter la perte de messages et à assurer une bascule propre vers un hébergeur spécialisé, avec une authentification correcte sur chaque message sortant.
Le cadre en six étapes est reproductible : appliquez-le de la même manière à chaque domaine cPanel supplémentaire, et le processus s'accélérera à chaque répétition.
Testez TrekMail Nano gratuitement sur trekmail.net/pricing, sans carte. Starter à $4/mois comprend l'outil de migration IMAP côté serveur nécessaire à l'étape 3. La plateforme prend en charge les opérations d'hébergement des boîtes que les hébergeurs cPanel vous laissaient gérer vous-même dans leur offre groupée.
Une remarque opérationnelle : la fenêtre de réception en parallèle de l'étape 4 est la raison structurelle pour laquelle cette approche vise à ne perdre aucun message. Les bascules à froid en perdent, car un intervalle sépare l'arrêt de l'ancien hébergeur du début de la réception mondiale chez le nouveau, et les messages rebondissent alors. La réception en parallèle supprime cet intervalle en maintenant les deux hébergeurs actifs pendant la propagation.
La migration depuis cPanel est généralement plus simple en pratique que ne l'imaginent les responsables. La crainte d'une panne de messagerie peut retarder le déplacement de plusieurs mois tandis que le coût de délivrabilité de l'hébergement cPanel groupé s'accumule. La méthode en six étapes réduit le risque de perte à l'origine de ce retard, ce qui explique pourquoi ceux qui l'effectuent une fois hésitent rarement à la répéter pour d'autres domaines.
Pour les responsables de plusieurs domaines personnalisés répartis entre des hébergeurs cPanel, le modèle s'applique domaine par domaine : les mêmes six étapes avec des entrées DNS différentes. Planifiez les bascules sur des jours distincts plutôt que simultanément. L'attention nécessaire pendant chaque migration est limitée mais réelle ; enchaîner les bascules crée une charge cognitive inutile et augmente le risque d'omettre une étape.
