Enregistrement MX : définition et routage des e-mails
ChatGPT
Claude
Gemini
Perplexity
GrokL’essentiel
Ce qu’est un enregistrement MX, comment la priorité route les e-mails, les valeurs exactes pour Google Workspace et Microsoft 365, et comment vérifier les vôtres.
Qu’est-ce qu’un MX ?
Un enregistrement MX (Mail Exchange) est un enregistrement DNS qui désigne les serveurs chargés de recevoir les e-mails envoyés à votre domaine. C’est l’adresse de la boîte aux lettres du domaine : quand on écrit à you@yourdomain.com, le serveur de l’expéditeur lit vos enregistrements MX pour savoir où livrer.
Les enregistrements MX ne régissent que le courrier entrant. Ils ne disent pas qui peut envoyer au nom de votre domaine : c’est le rôle de SPF, DKIM et DMARC. Publier des MX ne protège pas de l’usurpation.
Comment fonctionne un MX ?
Un MX associe un numéro de préférence au nom d’hôte d’un serveur. Format fichier de zone :
yourdomain.com. 3600 IN MX 10 mail1.yourdomain.com.
Lecture : le courrier pour yourdomain.com va à mail1.yourdomain.com, avec la préférence 10 et un TTL de 3600 secondes.
Un serveur d’envoi qui a un message pour votre domaine :
- Interroge le DNS sur les MX du domaine.
- Trie les résultats par préférence. Selon la RFC 5321, les petits numéros passent avant les grands : la préférence 10 est essayée avant la 20.
- Tente la livraison à l’hôte préféré. Si celui-ci est injoignable, il descend la liste.
- Met en file et réessaie si rien ne répond, au lieu de rejeter aussitôt.
Les enregistrements en pratique
Google Workspace utilise désormais un seul MX : smtp.google.com en priorité 1. Les domaines configurés avant 2023 ont peut-être encore l’ancien jeu de cinq enregistrements commençant par aspmx. Selon Google, ils fonctionnent toujours, sans changement.
Microsoft 365 utilise un enregistrement sur le modèle yourdomain-com.mail.protection.outlook.com, avec une priorité plus basse que tout autre MX du domaine. Le nom d’hôte est généré par tenant : copiez-le depuis le centre d’administration Microsoft 365 au lieu de le deviner.
Prenez toujours les valeurs exactes dans la console de votre fournisseur. Vérifiez ce qui est publié avec l’outil de recherche MX.
Les règles qui piègent
Un MX doit pointer vers un nom d’hôte doté d’un enregistrement A ou AAAA, jamais un CNAME. La RFC 5321 exige que la cible MX renvoie au moins une adresse, et précise qu’une cible renvoyant un CNAME « sort du cadre de cette norme ». Certains résolveurs le tolèrent ; le comportement est indéfini, n’en dépendez pas.
Une cible MX est un nom d’hôte, jamais une IP. Si vous n’avez qu’une IP, publiez d’abord un enregistrement A et pointez le MX vers ce nom.
Pas de MX ne veut pas dire pas de courrier. Selon la RFC 5321, si la liste MX est vide, l’expéditeur traite l’adresse du domaine comme un MX implicite de préférence 0. Supprimer vos MX n’arrête donc pas le courrier entrant. Il est redirigé sans bruit vers la cible de votre enregistrement A, souvent votre serveur web.
Pour vraiment refuser tout courrier, publiez un MX nul. La RFC 7505 le définit comme un seul enregistrement de préférence 0 ciblant le label racine :
yourdomain.com. IN MX 0 .
Il indique aux expéditeurs que le domaine n’accepte aucun e-mail : ils échouent aussitôt au lieu de réessayer des jours. Un domaine avec un MX nul ne doit publier aucun autre MX. Utilisez-le sur les domaines parqués ou de protection de marque, avec v=spf1 -all et un DMARC à p=reject, pour que personne n’envoie non plus au nom du domaine.
Pourquoi les MX comptent
- Livraison fiable. Des MX corrects mènent le courrier au bon serveur, pas dans un trou noir.
- Secours. Plusieurs MX à préférences différentes offrent une voie de secours si le principal tombe.
- Portabilité. Vous changez de messagerie en modifiant les MX, sans toucher à l’hébergement web.
- Un prérequis, pas un contrôle. L’authentification s’ajoute au MX, elle n’en fait pas partie. Vérifiez tout d’un coup avec l’outil Email Security Score.
Problèmes courants avec les MX
Pourquoi le courrier va-t-il encore à l’ancien fournisseur après le changement de MX ?
Parce qu’un changement ne se « propage » pas selon un minuteur global. Il dépend du TTL de l’enregistrement remplacé. Les résolveurs qui ont mis l’ancien en cache le servent jusqu’à expiration de leur copie, soit au plus ce TTL. Avec un TTL de 300 secondes, tout le monde voit le changement en cinq minutes environ ; avec 24 heures, cela peut prendre un jour. Le chiffre répandu de « jusqu’à 48 heures » est une marge héritée et prudente, pas une règle technique. Baissez le TTL un ou deux jours avant une migration prévue, puis remontez-le ensuite.
MX supprimés : pourquoi le courrier a-t-il cessé ?
Il n’a sans doute pas cessé : il est allé ailleurs, et c’est pire. Sans MX, les expéditeurs se rabattent sur l’enregistrement A du domaine et y livrent, selon la règle du MX implicite. Le courrier vise alors votre serveur web, qui le refuse en général. Si un domaine ne doit rien recevoir, publiez un MX nul au lieu de supprimer les enregistrements.
D’où vient l’alerte « MX points to a CNAME » ?
Un fournisseur DNS qui aplatit ou crée un alias pour la cible MX le déclenche. Cela viole l’exigence de la RFC 5321 : la cible MX doit renvoyer une adresse. Pointez le MX vers un nom d’hôte doté d’un vrai A/AAAA. Cela peut marcher aujourd’hui et casser demain chez un destinataire plus strict.
Pourquoi notre MX de secours reçoit-il tout le spam ?
C’est l’hôte le moins préféré, les spammeurs le visent exprès, et les serveurs de secours filtraient historiquement moins. Appliquez le même filtrage à chaque hôte du jeu MX, ou supprimez le secours. Les fournisseurs de messagerie modernes mettent en file et réessaient d’eux-mêmes : un MX secondaire vaut rarement l’exposition.
Pour une mise en œuvre propre à un fournisseur de ces contrôles, voir Comment corriger l’erreur SMTP Microsoft 5.4.1 ?.
À lire aussi
Questions des lecteurs
Questions fréquentes
Un domaine peut-il avoir des MX vers deux fournisseurs différents ?
Techniquement oui, mais évitez. Le premier hôte qui répond accepte le message : les boîtes se retrouvent réparties au hasard entre les deux. Une migration bascule, elle ne tourne pas en parallèle.
La priorité influe-t-elle sur la délivrabilité ou la réputation ?
Non. Elle ne fait qu’ordonner les tentatives. Le plus petit numéro passe en premier ; la valeur ne pèse rien pour les filtres anti-spam, et 1 n’a aucun avantage sur 10.
Faut-il des MX propres aux sous-domaines ?
Seulement s’ils reçoivent du courrier. mail.yourdomain.com a besoin de son propre MX si on lui écrit. Rien n’est hérité du domaine parent. Un sous-domaine qui ne reçoit jamais rien doit publier un MX nul.
Changer les MX affecte-t-il SPF, DKIM ou DMARC ?
Pas directement, mais changer de fournisseur le fait presque toujours. Le nouveau fournisseur envoie depuis d’autres serveurs et signe avec d’autres clés DKIM : mettez à jour SPF et DKIM dans la même migration. Vérifiez une fois la bascule terminée.
Qu’est-ce que le mécanisme mx d’un SPF ?
Il autorise les hôtes listés dans vos MX à envoyer pour votre domaine. C’est pratique quand les mêmes serveurs envoient et reçoivent, et il compte dans la limite SPF de dix requêtes. La plupart des messageries cloud n’en ont pas besoin.
Rédigé par
Dominic LandryDélivrabilité et DNS
Dominic Landry s’occupe de délivrabilité et de configuration DNS chez Palisade, des enregistrements SPF et DKIM à l’application DMARC.
Lire Dominic →