Transfert d’e-mails : copie IMAP et bascule DNS

Comprendre le transfert d'e-mails : DNS, copie IMAP et bascule

L'expression « transfert d'e-mails » est trompeuse. Dans le monde physique, transférer un fichier signifie qu'il quitte l'emplacement A pour arriver à l'emplacement B. Dans une infrastructure de messagerie, cela ne se passe jamais ainsi.

Un transfert d'e-mails correspond en réalité à deux opérations indépendantes menées en parallèle : la réplication d'une base de données par synchronisation IMAP et la redirection du trafic par bascule DNS. Confondre ces deux couches est la principale cause de pertes de données, d'acheminement scindé entre deux systèmes et de demandes d'assistance le lundi matin.

Ce guide explique ce que « transférer » signifie en pratique, ce qui est déplacé ou non et comment choisir la bonne méthode selon votre situation.

Les trois types de transfert d'e-mails

Avant de toucher à un serveur, définissez le périmètre. Le mot « transfert » désigne indifféremment trois opérations distinctes, alors que les confondre entraîne de vrais problèmes.

1. Transfert de domaine (changement de bureau d'enregistrement)

Vous transférez la gestion de example.com de GoDaddy à Namecheap. Cela change l'entité qui facture le nom de domaine. Impact sur la messagerie : aucun, à condition de reproduire correctement la zone DNS. Si vous changez les serveurs de noms sans recréer les enregistrements MX, la messagerie cesse immédiatement de fonctionner.

2. Migration de la messagerie (changement de fournisseur)

Vous quittez Google Workspace pour TrekMail, ou pour tout autre hébergeur. Il faut préparer un nouveau serveur, y copier les anciennes données et demander à Internet d'y acheminer les nouveaux messages. Impact sur la messagerie : total. Il s'agit d'une reconstruction minutieuse de vos données, et c'est le sujet principal de cet article.

Pour suivre le déroulement détaillé, consultez le guide de synchronisation IMAP.

3. Transfert de propriété d'un compte

Vous remplacez l'adresse d'administration d'un compte, de bob@ à alice@. C'est une mise à jour des autorisations dans la base de données. Impact sur la messagerie : nul.

Les deux couches à gérer pendant un transfert d'e-mails

La réussite d'un transfert exige de gérer deux calendriers simultanément. Une erreur dans l'un ou l'autre suffit à créer des problèmes.

La couche de données (copie IMAP)

Un nouveau fournisseur n'absorbe pas vos anciennes données. Vous les récupérez au moyen du protocole IMAP (RFC 3501). Il s'agit d'une copie, pas d'un déplacement : l'original reste sur le serveur source jusqu'à sa suppression explicite.

Le piège UIDVALIDITY : IMAP a été conçu pour consulter des messages, pas pour les répliquer en masse. Chaque dossier possède une valeur UIDVALIDITY. Si le serveur source tombe en panne ou réindexe ses données pendant la migration, cette valeur change. L'outil peut alors considérer chaque e-mail comme nouveau et tout télécharger de nouveau, laissant les utilisateurs avec 10,000 doublons. Utilisez un outil qui déduplique selon les en-têtes Message-ID, et pas uniquement les UID IMAP.

La couche d'acheminement (bascule DNS)

Pendant la copie des données, vous devez rediriger les nouveaux messages. Cette opération est contrôlée par l'enregistrement MX (Mail Exchange) :

Le risque d'acheminement scindé : les enregistrements DNS sont mis en cache par les fournisseurs d'accès du monde entier. Si votre TTL est de 86,400 secondes (24 heures) et que vous changez le MX le vendredi à 5 PM, certains serveurs continueront d'envoyer les messages à l'ancien fournisseur jusqu'au samedi à 5 PM.

La solution est la « règle des 300 secondes ». Abaissez le TTL du MX à 300 secondes au moins 24 heures avant la migration. Pour connaître toute la procédure, consultez la configuration des e-mails sur votre domaine.

Ce qui est transféré par IMAP et ce qui ne l'est pas

TrekMail est une plateforme spécialisée : IMAP et SMTP pour la messagerie, ainsi que la synchronisation des calendriers et contacts de chaque boîte par CalDAV et CardDAV. Ce n'est pas une suite de productivité : elle ne comprend ni documents, ni feuilles de calcul, ni appels vidéo. Lorsque vous quittez une suite comme Google ou M365 pour un hébergeur axé sur la messagerie, vous devez savoir exactement quelles données peuvent suivre.

L'obstacle de l'authentification moderne

Si vous migrez depuis un fournisseur qui impose OAuth, comme Google, les appareils anciens, par exemple de vieux scanners ou Outlook 2013, peuvent ne pas parvenir à se connecter à un serveur IMAP standard. La documentation de migration Google Workspace explique comment les mots de passe d'application peuvent combler cet écart. TrekMail prend en charge l'authentification IMAP/SMTP standard via TLS 1.2. Vérifiez que vos appareils sont compatibles.

Quelle méthode de transfert vous faut-il ?

Scénario A : réduire les coûts de Google Workspace

1. Configurez un compte TrekMail avec votre domaine
2. Utilisez l'outil de migration TrekMail pour copier les données de messagerie
3. Exportez les contacts (.vcf) et calendriers (.ics) dans des fichiers locaux
4. Remplacez les enregistrements MX par mx1.trekmail.net / mx2.trekmail.net
5. Résiliez Google Workspace après vérification de la copie et de la réception

Scénario B : transférer le domaine vers un autre bureau d'enregistrement

1. Autorisez le transfert auprès du bureau d'enregistrement actuel
2. Obtenez le code EPP ou d'autorisation
3. Lancez le transfert auprès du nouveau bureau d'enregistrement
4. Important : assurez-vous que les serveurs de noms ne changent pas ou reproduisez correctement toute la zone

Les outils intégrés de TrekMail pour transférer les e-mails

Les migrations IMAP manuelles sont sujettes aux erreurs. Un seul délai d'attente dépassé ou un changement de UIDVALIDITY peut produire une copie incomplète ou des doublons. TrekMail considère la migration comme une infrastructure essentielle, et non comme une fonction secondaire.

Moteur de migration

Le tableau de bord se connecte directement à l'ancien fournisseur, comme Gmail, cPanel ou Exchange, et gère la synchronisation IMAP de serveur à serveur. Les nouvelles tentatives, les délais progressifs en cas de limitation et la déduplication par en-têtes sont automatiques. Aucune ligne de commande n'est nécessaire.

Stockage mutualisé pour les agences

Si vous êtes un MSP qui transfère 50 clients, gérer 50 quotas de stockage distincts est inutile. TrekMail propose un stockage mutualisé, par exemple 200 GB partagés entre tous les domaines. Attribuez l'espace là où il est nécessaire.

Validation DNS

Un outil simple vérifie les enregistrements MX, SPF et DKIM afin de réduire le risque que vos propres e-mails se retrouvent sans destination pendant la bascule.

Toutes les offres payantes comprennent un essai gratuit de 14 jours qui nécessite une carte. L'offre Nano ne demande aucune carte.

Conclusion : déterminez le transfert d'e-mails dont vous avez réellement besoin

La plupart des échecs surviennent parce que les transferts de domaine, les migrations de messagerie et les changements de compte sont confondus. Séparez la couche de données, c'est-à-dire la copie IMAP, de la couche d'acheminement, la bascule DNS. Gérez-les selon des calendriers indépendants, puis comparez les décomptes et les éléments à la source.

Si vous êtes prêt à changer, créez votre compte TrekMail gratuit et laissez le moteur de migration se charger du travail le plus lourd.