Transférer une boîte mail : guide pratique de bascule DNS

Transférer une boîte mail vers un nouveau fournisseur : guide de bascule DNS

Lorsque vous transférez les données d'une boîte mail entre deux fournisseurs, votre stratégie DNS peut faire la différence entre une transition propre et une interruption allant jusqu'à 48 heures. Un TTL mal configuré ou un include SPF oublié risque de provoquer des rejets définitifs et une perte d'activité.

Cette opération ne laisse aucune place à l'improvisation. Elle repose sur une suite d'actions techniques précises. Ce guide explique comment transférer le contenu d'une boîte en limitant les risques : maîtriser les délais de propagation, réunir les identités d'authentification SPF, DKIM et DMARC, puis diriger le courrier vers le nouveau fournisseur sans promettre l'impossible absence de tout message perdu.

Pour la migration des données elle-même, consultez le guide de synchronisation IMAP.

Pourquoi la propagation DNS n'est pas immédiate lors du transfert d'une boîte

Le DNS est un système de cache distribué. Lorsque vous modifiez un enregistrement, vous dépendez de chaque résolveur récursif, qu'il s'agisse des serveurs DNS des fournisseurs d'accès, du 8.8.8.8 de Google ou des routeurs locaux, et de son respect de la durée de vie (TTL).

Si votre TTL conserve la valeur courante de 86,400 secondes (24 heures), le routage peut rester partagé jusqu'à l'expiration des caches. Certains messages arrivent alors dans la nouvelle boîte et d'autres dans l'ancienne.

La longue traîne et la mise en cache négative

Deux facteurs discrets perturbent régulièrement les bascules de boîtes mail :

• La longue traîne : même avec un TTL faible, on estime qu'entre 1 et 5% des résolveurs mondiaux ne respectent pas les valeurs inférieures à 60 minutes. Prévoyez donc un trafic résiduel vers l'ancien fournisseur pendant environ une heure après la bascule.
• La mise en cache négative (SOA) : si vous interrogez un enregistrement avant qu'il existe, par exemple un nouveau sélecteur DKIM trop tôt, la réponse NXDOMAIN est mise en cache selon le TTL minimal de l'enregistrement SOA, souvent 1 heure. L'enregistrement valide peut alors rester invisible jusqu'à l'expiration de ce cache, même après sa publication.

Phase 1 : le compte à rebours de 48 heures

Ne touchez pas encore aux enregistrements MX. Préparez d'abord l'environnement à accepter la modification.

Étape 1 : réduire les TTL (48 heures avant)

Repérez les enregistrements MX, SPF (TXT) et DMARC. Ramenez leur TTL à 300 secondes (5 minutes).

Vous raccourcissez ainsi la fenêtre de propagation attendue. Lors de la bascule finale, les caches qui respectent le TTL pourront se renouveler en 5 minutes environ au lieu d'attendre jusqu'à 24 heures.

Étape 2 : réunir les SPF (24 heures avant)

SPF (RFC 7208) autorise des adresses IP à envoyer des messages en votre nom. Pendant la transition, les deux fournisseurs doivent être autorisés simultanément.

Le piège : SPF vous limite à 10 recherches DNS. La réunion de deux fournisseurs, comme Google Workspace et TrekMail, peut dépasser ce seuil.

La solution : simplifiez l'enregistrement. Remplacez les instructions include: imbriquées par des mécanismes ip4: directs uniquement lorsque le fournisseur publie des adresses stables et prend en charge leur maintenance.

Exemple d'enregistrement de transition :

Si vous utilisez un SMTP externe avec TrekMail, comme Amazon SES ou SendGrid, incluez plutôt leurs enregistrements SPF.

Étape 3 : prépublier DKIM

DKIM utilise des sélecteurs, par exemple google._domainkey. Générez les clés DKIM chez le nouveau fournisseur avec un sélecteur unique, comme tm1._domainkey. Ne réutilisez jamais le nom d'un sélecteur. Vous pouvez publier le nouveau plusieurs jours à l'avance sans créer de conflit avec l'ancien fournisseur.

Étape 4 : assouplir DMARC

Si votre stratégie DMARC utilise p=reject ou p=quarantine, passez à p=none au moins 24 heures avant la bascule. Des échecs d'authentification sont possibles pendant les premières heures. p=none permet de les consigner dans les rapports RUA sans demander leur rejet par DMARC, mais la distribution dépend toujours des autres contrôles du destinataire. Le guide de configuration DMARC de Google explique comment définir correctement cette stratégie.

Phase 2 : exécuter la bascule

Les TTL sont faibles et l'authentification couvre les deux systèmes. Il est temps de transférer le routage de la boîte vers le nouvel hébergeur.

Étape 1 : comparer les réponses autoritatives et récursives

Vérifiez que les nouveaux enregistrements sont visibles sur votre serveur de noms autoritatif avant de les contrôler depuis des résolveurs publics :

Étape 2 : mettre à jour les enregistrements MX

Ajoutez et contrôlez les nouveaux MX avant de retirer les anciens, ou appliquez la modification de façon atomique si votre fournisseur DNS le permet. Pour les utilisateurs de TrekMail :

Conservez un TTL de 300 secondes. Ne l'augmentez pas encore.

Étape 3 : vider le cache et vérifier

Videz votre cache DNS local avec ipconfig /flushdns sous Windows ou sudo dscacheutil -flushcache sous macOS. Relancez ensuite dig. Cette opération ne vide que votre cache local, et les nouveaux MX apparaîtront lorsque le résolveur interrogé aura actualisé le sien.

Phase 3 : stabiliser le service après la bascule

Surveiller les erreurs d'attribution du tenant (550 5.7.64)

Cette erreur survient fréquemment lorsque vous transférez l'hébergement d'une boîte vers Microsoft 365 ou une suite similaire. Si la destination n'a pas encore entièrement provisionné le domaine dans son annuaire interne, elle peut refuser le courrier avec le message « Relay Access Denied ». Vérifiez que le domaine porte l'état « Verified » ou « Healthy » dans le tableau de bord du nouveau fournisseur avant de modifier les MX.

Surveiller les rapports DMARC (72 heures)

Examinez vos rapports RUA pendant trois jours :

• Réussite : le trafic provenant des adresses IP du nouveau fournisseur passe les contrôles SPF et DKIM.
• Échec : un trafic légitime, provenant par exemple de systèmes de facturation ou de plateformes marketing, échoue à l'authentification. Corrigez immédiatement SPF ou DKIM.

Nettoyage (72 heures après)

Une fois le trafic stabilisé :

1. Retirez l'include: de l'ancien fournisseur de votre enregistrement SPF.
2. Retirez les anciens enregistrements DKIM CNAME/TXT seulement après un délai sûr pour les messages encore munis des anciennes signatures.
3. Remontez les TTL à 3,600s (1 heure) ou 86,400s (24 heures).
4. Réactivez une stratégie DMARC avec p=quarantine ou p=reject.

La checklist de transfert d'une boîte en un coup d'œil

TrekMail simplifie le transfert des boîtes mail

La gestion manuelle du DNS est propice aux erreurs. Une seule faute de syntaxe dans un enregistrement TXT peut invalider toute votre stratégie SPF.

Pour les petites entreprises

TrekMail propose un contrôle de l'état du DNS en temps réel. Le tableau de bord interroge vos serveurs de noms autoritatifs et compare les enregistrements MX, SPF et DKIM avec la configuration requise. Il confirme leur publication autoritative, pas leur propagation auprès de tous les résolveurs, et signale les erreurs de syntaxe avant qu'elles puissent provoquer des rejets.

Découvrez comment configurer la messagerie sur votre propre domaine.

Pour les agences

La gestion de plus de 50 domaines exige une méthode standard. TrekMail permet d'appliquer un modèle DNS cohérent à tous les tenants clients. Avec les offres Starter et Agency, le SMTP géré prend en charge la réputation IP et les en-têtes de distribution, ce qui peut éviter un aplatissement SPF complexe ou un programme interne de chauffe des IP.

Découvrez le fonctionnement de l'hébergement de messagerie multidomaine pour les agences.

Toutes les offres payantes comprennent un essai gratuit de 14 jours avec carte bancaire requise. L'offre Nano ne demande aucune carte.

Conclusion

Lorsque vous transférez une boîte vers un nouveau fournisseur, la bascule DNS est l'une des étapes les plus délicates. Réduisez les TTL suffisamment tôt, réunissez les enregistrements d'authentification, modifiez les MX pendant une fenêtre de maintenance et surveillez les rapports DMARC pendant 72 heures. Voilà la méthode.

Si vous préférez éviter la gestion manuelle de multiples enregistrements DNS, essayez TrekMail gratuitement et utilisez le tableau de bord pour valider votre configuration.