# Un enregistrement MX fiable : héberger ses emails ailleurs que son hébergeur web > Site web et messagerie professionnelle n'ont pas besoin de vivre chez le même prestataire. Voici comment déclarer des MX propres sans casser la réception des emails. - Auteur : Clément Hadrot - Publié le : 2022-03-25 - Mis à jour le : 2022-03-25 - Catégorie : Hébergement & serveurs - URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/mx-emails-hebergeur-web-separe/ ## L’essentiel - Le MX pointe vers le serveur de messagerie, pas vers le site - La priorité MX ordonne les serveurs de secours - Un TTL bas évite une longue coupure en cas d'erreur Un client de l'agence gérait jusqu'ici son site WordPress et ses emails professionnels chez le même hébergeur mutualisé. En migrant le site vers un VPS dédié pour gagner en performance, il posait une question simple en apparence : « et mes emails, ils suivent où ? » La réponse la plus saine consistait justement à ne pas les faire suivre — à les laisser où ils étaient, sur un service de messagerie distinct, et à ne déplacer que la partie web. Séparer hébergement web et messagerie n'a rien d'exotique. C'est même la pratique la plus robuste : un problème sur le serveur qui sert les pages WordPress n'a alors aucun impact sur la réception des emails, et inversement. Le lien entre les deux se fait uniquement via la zone DNS du domaine, à travers un type d'enregistrement précis : le MX, pour « Mail Exchanger ». ## Ce qu'est réellement un enregistrement MX Un enregistrement MX indique, pour un nom de domaine donné, quel serveur est chargé de recevoir les emails adressés à ce domaine. Contrairement à un enregistrement A ou AAAA, qui pointe vers une adresse IP, un MX pointe vers un nom d'hôte (un FQDN), qui doit lui-même être résolu par un enregistrement A ou AAAA. Il ne pointe jamais directement vers une IP. Chaque MX porte aussi une priorité, un entier positif. Plus le nombre est bas, plus la priorité est haute : un serveur en priorité 10 sera contacté avant un serveur en priorité 20. Cette mécanique permet de déclarer un serveur de secours qui ne prend le relais que si le principal ne répond pas, sans configuration supplémentaire côté serveur expéditeur. ## Le fonctionnement interne, étape par étape Quand un serveur d'envoi doit livrer un email à contact@exemple.fr, il interroge le DNS pour les MX de exemple.fr, trie les réponses par priorité croissante, puis tente une connexion SMTP sur le port 25 vers le premier hôte. En cas d'échec, il retente sur l'hôte suivant, puis met le message en file d'attente pendant plusieurs heures avant d'abandonner et de renvoyer un message d'erreur (« bounce ») à l'expéditeur. ``` exemple.fr. 3600 IN MX 10 mx1.messagerie-pro.fr. exemple.fr. 3600 IN MX 20 mx2.messagerie-pro.fr. ``` Ce comportement de repli explique pourquoi il est risqué de ne déclarer qu'un seul MX en production : une panne, même brève, du serveur unique se traduit par des emails en attente plutôt que perdus, mais aussi par des délais de livraison qui peuvent atteindre plusieurs heures selon la politique de réessai de l'expéditeur. > L'essentiel à retenir : Le MX pointe vers le serveur de messagerie, pas vers le site ; La priorité MX ordonne les serveurs de secours ; Un TTL bas évite une longue coupure en cas d'erreur ## Cas d'usage : séparer le site et la messagerie Pour ce client, la bascule tenait en trois actions distinctes, réalisées dans le bon ordre. D'abord, vérifier auprès du prestataire de messagerie (ici un service dédié, indépendant de l'hébergeur web d'origine) les valeurs MX exactes à déclarer, généralement fournies telles quelles dans sa documentation. Ensuite, modifier la zone DNS du domaine — chez le registrar ou le prestataire DNS, peu importe qui héberge le site — pour y ajouter ces MX, sans toucher aux enregistrements A du site. Un point mérite une attention particulière : si l'ancien hébergeur avait lui-même posé des MX par défaut au moment de l'achat du domaine, il faut les supprimer complètement, pas seulement en ajouter de nouveaux. Deux jeux de MX actifs simultanément provoquent une répartition imprévisible des emails entrants entre deux boîtes différentes, un scénario de perte de courrier redouté à juste titre. - Réduire le TTL des MX à 300 secondes une semaine avant la bascule, pour limiter la durée de propagation d'une éventuelle erreur - Confirmer la réception de test sur chaque adresse professionnelle avant de couper l'ancien service - Remonter le TTL à sa valeur normale une fois la bascule stabilisée ## Les pièges qui coûtent des emails Le piège le plus fréquent reste la confusion entre l'enregistrement MX et les enregistrements qui authentifient l'expéditeur — SPF, DKIM, DMARC — qui sont eux aussi nécessaires mais répondent à une question différente : ils ne disent pas où arrive un email, ils garantissent qu'un email envoyé « depuis » le domaine n'est pas une usurpation. Les deux sujets se croisent dans la même zone DNS mais ne se substituent jamais l'un à l'autre. Un autre piège classique concerne le nom d'hôte cible du MX : il doit exister et posséder son propre enregistrement A, sans être lui-même un CNAME. La RFC impose qu'un MX pointe vers un nom canonique, et de nombreux résolveurs rejettent silencieusement une cible qui n'est qu'un alias, ce qui se traduit par des rebonds difficiles à diagnostiquer. > Sur ce type de bascule, nous ne coupons jamais l'ancien MX le jour même : nous le laissons vivre 48 heures en priorité basse, le temps que la propagation DNS soit uniforme chez tous les résolveurs concernés. ## En résumé Un enregistrement MX se manipule avec précaution mais ne demande aucune magie : une cible valide, une priorité cohérente, un TTL abaissé pendant la bascule et l'ancien jeu d'enregistrements proprement retiré. Séparer le site de la messagerie est une décision d'architecture saine, à condition de traiter le DNS comme une opération planifiée, jamais improvisée en urgence un vendredi soir.