La migration d’un site web comporte deux aspects : les fichiers et les bases de données du site, ainsi que vos serveurs de messagerie. Un problème courant est la défaillance des serveurs de messagerie due à une mauvaise compréhension du fonctionnement de vos enregistrements MX et de votre hébergement web, qui fonctionnent de manière indépendante, mais en harmonie.
Cette indépendance architecturale signifie que vos e-mails sont acheminés vers votre fournisseur de messagerie, quel que soit l’emplacement de vos fichiers de site web ou la plateforme d’hébergement qui sert vos pages aux visiteurs.
Ainsi, votre migration vers Kinsta n’interrompra aucun service de messagerie si vous configurez tout correctement.
Vos enregistrements MX et votre hébergement web fonctionnent indépendamment
Le système de noms de domaine (DNS) gère chaque type d’enregistrement séparément lors des transitions d’hébergement.
Lorsque vous changez d’hébergeur, vous mettez à jour les enregistrements A qui dirigent les navigateurs vers la nouvelle adresse IP du serveur. Vos enregistrements MX restent inchangés à moins que vous ne les modifiez délibérément, de sorte que les serveurs de messagerie continuent d’acheminer les e-mails vers votre fournisseur de messagerie existant sans aucun changement de configuration.
Le processus de migration de Kinsta clone votre site tandis que votre hébergeur d’origine continue de gérer le trafic. Cela permet aux deux environnements d’afficher le même contenu simultanément. Pendant la propagation DNS, certains visiteurs voient des versions différentes de votre site en fonction de la requête de connexion au serveur DNS. Les valeurs TTL déterminent la durée de cette période (généralement jusqu’à quelques heures).
Pendant toute cette période, vos enregistrements MX redirigent les e-mails vers votre serveur de messagerie sans interruption : en résumé, le routage des e-mails fonctionne sur un chemin de recherche DNS distinct du trafic web.
3 scénarios de migration et implications sur les enregistrements MX
Les configurations d’hébergement de messagerie déterminent le comportement des enregistrements MX pendant les migrations. Vous devez adopter une approche différente selon l’emplacement actuel de votre messagerie et selon que vous prévoyez ou non de changer de fournisseur de messagerie pendant la migration du site.
1. E-mails hébergés séparément de votre site web (le plus courant)
Les services de messagerie tels que Google Workspace ou Microsoft 365 fonctionnent sur une infrastructure totalement distincte de l’hébergement web. Votre site web fonctionne sur une seule plateforme, tandis que la messagerie passe par un fournisseur spécialisé disposant de serveurs de messagerie dédiés.
Lors de la migration vers Kinsta, seuls vos enregistrements A changent pour rediriger les visiteurs vers votre nouvel hébergeur. Vos enregistrements MX continuent de pointer vers Google Workspace ou Microsoft 365 sans modification. Les e-mails transitent par l’infrastructure de votre fournisseur de messagerie exactement comme avant, sans qu’aucune modification de configuration ne soit nécessaire pendant la transition.
Cornershop Creative, client de Kinsta, gère des centaines de sites clients, ce qui implique des centaines de migrations de sites sans interruption de la messagerie. Son processus permet de conserver la messagerie sur Google Workspace tout en transférant les sites web vers Kinsta.
C’est la configuration recommandée par Kinsta pour tous les sites. Elle sépare la messagerie de l’hébergement, de sorte que lorsque vous migrez des sites, mettez à jour des serveurs ou apportez des modifications à l’infrastructure, le service de messagerie continue de fonctionner sans nécessiter de coordination supplémentaire.
2. E-mails et site web sur le même serveur
Kinsta ne fournit pas d’hébergement de messagerie dans le cadre de son hébergement WordPress infogéré. C’est la solution optimale, car cela permet de conserver la messagerie sur une infrastructure dédiée, conçue pour la livraison des messages, le filtrage des spams et la conformité aux normes d’authentification des e-mails.
Cependant, certains hébergeurs regroupent la messagerie avec l’hébergement web, ce qui crée des dépendances complexes. Comme vos comptes de messagerie se trouvent sur le même serveur que les fichiers et les bases de données de votre site web, cela lie directement le service de messagerie à l’infrastructure de votre hébergeur.
Vous devez donc prendre une décision lorsque vous migrez depuis un hébergement e-mail groupé : utiliser un fournisseur de messagerie distinct avant de déplacer votre site, ou ne déplacer que les fichiers de votre site web vers Kinsta.
Migrer votre messagerie vers un fournisseur tiers avant la migration de votre site implique de créer de nouveaux comptes, de configurer les enregistrements MX pour qu’ils pointent vers le nouveau fournisseur et de tester la livraison des e-mails avant de mettre à jour vos enregistrements A. Une fois que votre messagerie est fiable, vous pouvez procéder à la migration de votre site. L’alternative consiste à conserver un compte chez votre ancien hébergeur spécialement pour la messagerie, ce qui est coûteux et inefficace.
3. Changer à la fois de fournisseur web et de fournisseur de messagerie
Vous devez vous préparer à l’avance lorsque vous transférez vos e-mails pendant une migration de site. Cela implique de faire fonctionner les deux systèmes de messagerie en parallèle pendant une brève période de test avant de modifier les enregistrements DNS pour que la nouvelle configuration soit effective.
Commencez par créer un compte chez votre nouveau fournisseur de messagerie et configurez les enregistrements MX dans votre panneau de gestion DNS. Ces nouveaux enregistrements MX coexistent avec votre configuration actuelle, avec des valeurs de priorité initialement plus faibles pour empêcher les e-mails de production de passer pendant les tests.
Ensuite, testez la nouvelle configuration de messagerie à l’aide d’un outil tel que MXToolbox pour vérifier que les enregistrements existent et pointent vers les bons serveurs de messagerie :
À ce stade, envoyez des messages de test, vérifiez les délais de livraison et assurez-vous que l’envoi et la réception fonctionnent correctement via le nouveau fournisseur avant d’effectuer les modifications.
Une fois que vous avez confirmé que la nouvelle infrastructure de messagerie fonctionne correctement, coordonnez les modifications DNS. Pour cela, vous devez mettre à jour les priorités des enregistrements MX afin de diriger l’e-mail vers le nouveau fournisseur, et les enregistrements A pour qu’ils pointent vers Kinsta. Certains e-mails peuvent encore être acheminés vers votre ancien fournisseur en raison d’enregistrements DNS mis en cache ; par conséquent, en conservant l’accès aux deux systèmes de messagerie pendant 48 heures maximum, vous pourrez récupérer les messages retardés.
Gestion des enregistrements MX pendant les migrations vers Kinsta
Chaque site sur Kinsta reçoit un domaine kinsta.cloud temporaire. L’outil « Aperçu du site » vous permet d’accéder à cette URL temporaire pour tester votre site migré avant d’effectuer toute mise à jour DNS.
Cette URL vous donne un accès complet pour vous connecter à WordPress, parcourir les pages du frontend, envoyer des formulaires et vérifier les fonctionnalités, tandis que votre site de production continue de servir le trafic via l’hébergeur d’origine.
Vous devrez effectuer un processus de vérification pour identifier tout problème avant la propagation DNS. Si des problèmes surviennent, les résoudre ici permet de ne pas affecter votre site de production. Ce n’est qu’après avoir confirmé que tout fonctionne correctement que vous pouvez procéder aux mises à jour DNS.
L’équipe de support de Kinsta fournit des conseils et de la documentation pour l’ensemble du processus post-migration et est disponible 24/7 pour répondre à vos questions.
Fonctionnalités DNS de Kinsta pour la gestion des e-mails
Le DNS Kinsta propose un hébergement DNS en option si vous souhaitez gérer les enregistrements de domaine directement dans MyKinsta plutôt que chez votre registraire ou un fournisseur DNS tiers. Le service inclut des fonctionnalités spécialement conçues pour la gestion des enregistrements de messagerie.
Vous pouvez configurer des enregistrements MX en quelques clics dans Google Workspace. Lorsque vous ajoutez un nouveau domaine depuis l’écran DNS dans MyKinsta, cochez la case « Ajouter des enregistrements MX Gmail ». Cela crée automatiquement les cinq enregistrements MX nécessaires avec les valeurs de priorité et les noms d’hôte corrects.
Pour les domaines déjà configurés dans Kinsta DNS, accédez à la section DNS, sélectionnez votre domaine, puis cliquez sur le bouton « Ajouter des enregistrements MX Gmail » en haut de la page. Cela vous permet de voir les cinq enregistrements MX Google Workspace avant de terminer le processus :
aspmx.l.google.com(priorité1)alt1.aspmx.l.google.com(priorité5)alt2.aspmx.l.google.com(priorité5)alt3.aspmx.l.google.com(priorité10)alt4.aspmx.l.google.com(priorité10)
La valeur par défaut du TTL est de 3600 secondes (une heure) pour ces enregistrements, ce qui détermine la durée pendant laquelle les serveurs DNS du monde entier mettent les informations en cache avant de vérifier s’il y a des mises à jour. Cela permet d’équilibrer l’efficacité de la mise en cache DNS et la possibilité d’apporter des modifications quand vous en avez besoin.
Ajouter des enregistrements MX pour d’autres fournisseurs de messagerie
Pour les fournisseurs de messagerie autres que Google Workspace,vous devez configurer manuellement les enregistrements MX. Votre fournisseur vous fournit ces valeurs, généralement les noms d’hôte des serveurs de messagerie et les numéros de priorité.
Dans MyKinsta, cliquez sur DNS, sélectionnez votre domaine, puis dans Ajouter un enregistrement DNS, cliquez sur Ajouter un enregistrement. Sélectionnez le type d’enregistrement MX et remplissez les champs obligatoires :
- Nom d’hôte. Indiquez le nom d’hôte de votre adresse e-mail (souvent laissé vide pour les configurations de domaine racine).
- Pointe vers. Saisissez ici le nom d’hôte du serveur de messagerie de votre fournisseur de messagerie.
- Priorité. Définissez le numéro de priorité ; les nombres les plus bas indiquent une priorité plus élevée.
- TTL (Time to Live). Utilisez le réglage par défaut recommandé, soit une heure.
Enfin, cliquez sur « Ajouter un enregistrement DNS » pour enregistrer la configuration.
Microsoft 365 utilise généralement un seul enregistrement MX pointant vers un serveur de messagerie régional, tandis que Zoho nécessite plusieurs enregistrements MX avec des valeurs de priorité différentes. La plupart des fournisseurs prennent en charge plusieurs enregistrements MX ; ajoutez-les séparément en suivant le même processus.
Vous n’êtes pas obligé d’utiliser le DNS de Kinsta non plus. Vous pouvez plutôt gérer le DNS via votre registraire de domaine ou un autre fournisseur tout en hébergeant votre site sur Kinsta. Cela simplifie parfois le dépannage et facilite les mises à jour lorsque vous modifiez les configurations d’hébergement web ou de messagerie.
Problèmes courants liés aux enregistrements MX et comment les résoudre
Quelles que soient les mesures de planification et d’atténuation que vous mettez en place, il y a toujours un problème à résoudre. Voici quelques-uns des problèmes les plus courants liés aux enregistrements MX:
- Pointage vers des enregistrements CNAME.
- Définition de valeurs de priorité incorrectes.
- Mauvaise configuration des serveurs de secours.
Tout d’abord, les enregistrements MX qui pointent vers des enregistrements CNAME entraînent des échecs de livraison. En effet, les serveurs de messagerie interrogent les enregistrements MX et s’attendent à trouver des enregistrements A ou AAAA contenant des adresses IP. Lorsqu’un enregistrement MX pointe vers un CNAME, le serveur de messagerie ne peut pas terminer la chaîne de recherche, ce qui entraîne le renvoi des messages.
La solution consiste à vous assurer que vos enregistrements MX pointent directement vers des noms d’hôte disposant d’enregistrements A. Une configuration correcte montre que ton enregistrement MX pointe vers mail.example.com, qui possède un enregistrement A contenant l’adresse IP de votre serveur de messagerie.
Des valeurs de priorité incorrectes peuvent également causer des problèmes de routage du courrier lorsqu’il existe plusieurs enregistrements MX pour un domaine. Les numéros de priorité les plus bas reçoivent l’e-mail en premier, donc votre serveur principal devrait avoir une valeur telle que 10, tandis que les serveurs de secours utilisent des numéros plus élevés (20 ou 30). Confondre ces valeurs entraîne des retards si un serveur de secours doit transférer des messages vers le serveur principal.
Si votre serveur de messagerie principal est hors ligne, un serveur de secours mal configuré ne parvient pas à traiter tes e-mails. Un enregistrement MX pointant vers une infrastructure inexistante ou sous-optimale crée un faux sentiment de redondance. Pour y remédier, ajustez temporairement les valeurs de priorité sur le serveur de secours pour le rendre principal, puis envoyez des messages de test pour vérifier la livraison.
Planifier votre migration en tenant compte de la messagerie
La migration d’un site peut prendre du temps, surtout si vous devez également gérer tes enregistrements MX. L’approche optimale consiste à documenter vos enregistrements avant la migration, y compris les valeurs de priorité, afin de créer une sauvegarde complète de tous les enregistrements DNS.
Dans le tableau de bord MyKinsta, vous pouvez créer des enregistrements MX en quelques clics (pour les utilisateurs de Google Workspace). Une fois la migration réussie, il est prioritaire de tester que tout fonctionne. L’équipe d’assistance de Kinsta dispose de l’expertise nécessaire pour vous accompagner tout au long du processus.
En plus de cette assistance experte en matière de migration, l’hébergement WordPress infogéré de Kinsta comprend une infrastructure fiable conçue pour les sites de toutes tailles et des outils de gestion DNS qui simplifient la configuration des e-mails.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
