Enregistrements MX : le routage du courrier entrant, expliqué

Ce que contient réellement un enregistrement MX

Une ligne de fichier de zone suffit à tout comprendre : `example.com. 3600 IN MX 10 mail.example.com.` Le 10 est la préférence, `mail.example.com.` le serveur qui accepte le courrier pour ce domaine, 3600 le TTL en secondes. Rien d'autre. Un MX ne transporte ni adresse IP, ni numéro de port, ni identifiant de compte.

Le type MX porte le code 15 dans le registre des types DNS et existe depuis la RFC 1035, publiée en 1987. Sa partie données tient en deux champs : un entier non signé sur 16 bits (valeurs de 0 à 65535) et un nom de domaine. Ce nom doit se résoudre en A ou AAAA, sinon le serveur expéditeur n'a aucune adresse à contacter et la remise échoue avant même l'ouverture de la session SMTP sur le port 25.

Le MX répond à une question, et une seule, posée par la machine qui expédie : à quelle adresse dois-je livrer un message destiné à quelqu'un@example.com ? Il ne dit rien de la boîte, du quota, du webmail ou du protocole de relève.

Champ	Valeur dans l'exemple	Contrainte
Nom	example.com.	la partie droite de l'adresse e-mail, pas le nom du serveur
TTL	3600	durée de mise en cache chez les résolveurs, en secondes
Préférence	10	entier de 0 à 65535, essayé par ordre croissant
Cible	mail.example.com.	nom d'hôte avec A ou AAAA, jamais une IP ni un CNAME

La préférence ordonne les essais, elle ne répartit pas la charge

Le serveur expéditeur trie les MX par préférence croissante et contacte le plus bas en premier. 0 passe avant 10, qui passe avant 50. Il ne bascule sur le suivant que si la connexion échoue ou si le serveur répond par un code temporaire 4xx.

Quand plusieurs MX partagent la même préférence, la RFC 5321 demande de tirer l'ordre au hasard entre eux. C'est la seule répartition que le MX sait faire, et elle est grossière : pas de poids, pas de notion de charge réelle, contrairement au champ weight d'un enregistrement SRV. Si vous voulez envoyer 80 % du trafic vers un site et 20 % vers l'autre, le MX n'est pas l'outil.

Le MX de secours à préférence haute vient des époques où les liaisons tombaient souvent. Il pose aujourd'hui un problème concret : beaucoup d'expéditeurs indésirables visent directement la préférence la plus élevée, en pariant que ce relais filtre moins bien que le principal. Si votre secours ne connaît pas la liste exacte des destinataires valides, il accepte des messages pour des adresses inexistantes puis génère des rebonds vers des expéditeurs falsifiés. Mieux vaut alors n'avoir aucun secours.

• `10 mx1.example.com.` et `10 mx2.example.com.` : les deux reçoivent, dans un ordre aléatoire d'un expéditeur à l'autre
• `10 mx1.example.com.` et `50 backup.example.com.` : le second n'est contacté que si le premier ne répond pas
• `1 smtp.google.com.` : la configuration Google Workspace recommandée depuis 2023, un seul enregistrement au lieu des cinq ASPMX historiques
• `0 .` : le null MX, qui annonce que le domaine ne reçoit pas de courrier

Les quatre erreurs qui font rebondir le courrier

Un MX qui pointe vers un CNAME. La RFC 2181, section 10.3, l'interdit sans ambiguïté. Certains serveurs suivent quand même l'alias, d'autres abandonnent. Vous obtenez alors une messagerie qui fonctionne depuis Gmail et échoue depuis un Postfix strict, avec un utilisateur qui vous jure que « ça marche chez lui ».

Le point final oublié. Dans un fichier de zone BIND, `mail.example.com` sans point devient `mail.example.com.example.com`. Les interfaces DNS hébergées ajoutent souvent le point à votre place, BIND non.

L'absence totale de MX. La RFC 5321, section 5.1, prévoit un repli sur l'enregistrement A ou AAAA du domaine, traité comme un MX de préférence 0. Un domaine sans MX mais avec un A qui pointe vers le serveur web recevra donc son courrier sur ce serveur web, où en général rien n'écoute sur le port 25. Le message reste en file chez l'expéditeur, qui réessaie pendant quatre à cinq jours (durée que la RFC 5321 recommande comme minimum) avant d'émettre un rapport de non-remise définitif. Quatre jours de silence, puis un rebond : le pire des scénarios pour un client qui vous écrit.

Le domaine qui ne doit jamais recevoir de courrier et qui ne le dit pas. Pour une marque défensive ou un domaine de redirection, publiez `example.com. IN MX 0 .` : c'est le null MX de la RFC 7505. La cible est la racine, les expéditeurs conformes rejettent tout de suite avec un code 5xx au lieu de faire patienter le message cinq jours.

Vérifier ses MX avant d’appeler l’hébergeur

La première commande à taper est `dig MX example.com +short`. Elle renvoie une ligne par enregistrement, préférence puis nom d'hôte, exactement ce qu'un serveur expéditeur voit. Sur gmail.com par exemple, vous obtenez une cible principale en préférence 5 et quatre alternatives en 10, 20, 30 et 40 : refaites le test chez vous, ces valeurs peuvent changer.

Le piège du diagnostic est le cache. Votre box ou votre résolveur d'entreprise peut servir l'ancienne réponse pendant toute la durée du TTL précédent. Interrogez un résolveur public pour trancher, et testez aussi depuis l'extérieur du réseau qui héberge le serveur : une vue DNS interne (split horizon) renvoie parfois un MX différent de la vue publique, et c'est la vue publique qui décide.

Avant une migration de messagerie, abaissez le TTL des MX à 300 secondes au moins 24 heures avant la bascule, laissez les anciens caches expirer, puis remontez à 3600 une fois la nouvelle configuration validée.

• `dig MX example.com +short` : la liste brute, préférence et cible
• `dig MX example.com @1.1.1.1` : contourne le cache local pendant une migration
• `dig A mail.example.com +short` : confirme que la cible a bien une adresse, l'oubli le plus fréquent
• `dig MX example.com +trace` : remonte depuis la racine quand la délégation elle-même est suspecte
• `nslookup -type=mx example.com` : l'équivalent sous Windows sans outil supplémentaire
• `openssl s_client -starttls smtp -connect mail.example.com:25` : vérifie qu'un MTA répond vraiment et présente son certificat

MX, SPF, DKIM : qui fait quoi

Confusion la plus répandue : le MX gouverne le courrier entrant, SPF le courrier sortant. Changer vos MX n'autorise personne à envoyer en votre nom, et un SPF parfait n'aidera pas un domaine dont les MX pointent vers un serveur éteint. Les deux enregistrements ne se remplacent jamais.

Le mécanisme `mx` d'une politique SPF (`v=spf1 mx -all`) autorise les adresses IP de vos serveurs MX à émettre. Pratique quand la même machine envoie et reçoit, mais chaque `mx` consomme des requêtes DNS dans la limite de dix évaluations fixée par la RFC 7208, et cette limite arrive vite dès que plusieurs `include:` de prestataires s'empilent.

Le MX ne dit rien du chiffrement de la session. C'est STARTTLS, annoncé par le serveur receveur, qui l'apporte, et MTA-STS (RFC 8461) ou DANE (RFC 7672) qui empêchent un attaquant de le retirer pendant la négociation. Un MX correct devant un serveur sans TLS reste un MX correct, techniquement.

Ne confondez pas non plus MX et PTR. Le PTR, résolution inverse de l'IP sortante, pèse sur votre réputation à l'envoi ; le MX n'a aucun effet dessus. Et le port 25 concerne les échanges entre serveurs : vos utilisateurs, eux, soumettent leur courrier sur 587 (RFC 6409) ou 465, jamais via le MX.

Besoin	Enregistrement	Type DNS
Recevoir du courrier	MX	MX (type 15)
Autoriser vos serveurs d'envoi	SPF	TXT à la racine du domaine
Signer les messages sortants	DKIM	TXT sur selecteur._domainkey
Dire quoi faire en cas d'échec	DMARC	TXT sur _dmarc
Imposer TLS à l'entrant	MTA-STS	TXT sur _mta-sts + fichier servi en HTTPS

Questions fréquentes

Combien d’enregistrements MX faut-il publier ?

Un seul suffit si le service derrière est redondant, ce qui est le cas des offres hébergées : Microsoft 365 ne demande qu'un `0 votredomaine.mail.protection.outlook.com.`, Google Workspace qu'un `1 smtp.google.com.` Sur une infrastructure que vous gérez, deux MX de même préférence sur deux machines distinctes valent mieux qu'un principal et un secours mal tenu.

Un enregistrement MX peut-il pointer vers une adresse IP ?

Non. La partie droite d'un MX est un nom de domaine, pas une adresse. Publiez d'abord un A ou AAAA pour `mail.example.com`, puis faites pointer le MX vers ce nom. Une IP écrite directement sera soit rejetée par l'interface DNS, soit interprétée comme un nom d'hôte impossible à résoudre.

Combien de temps une modification de MX met-elle à se propager ?

Au maximum la durée du TTL de l'ancien enregistrement, telle qu'elle était servie au moment où les résolveurs l'ont mise en cache. Avec un TTL de 3600, comptez jusqu'à une heure après la modification ; avec 86400, jusqu'à 24 heures. Baisser le TTL après le changement ne sert à rien, il faut le faire avant.

Faut-il un MX distinct pour un sous-domaine ?

Oui. Un MX sur `example.com` ne couvre pas `factures.example.com` : les sous-domaines n'héritent de rien en DNS. Pour recevoir sur `contact@factures.example.com`, publiez un MX au nom exact `factures.example.com`. Un joker `*.example.com IN MX` existe, mais il ne s'applique qu'aux noms qui n'ont aucun autre enregistrement, ce qui produit des surprises.

Que se passe-t-il si je supprime tous mes enregistrements MX ?

Le courrier n'est pas rejeté proprement : les expéditeurs se rabattent sur l'enregistrement A ou AAAA du domaine (RFC 5321, section 5.1) et tentent une connexion sur le port 25 de votre serveur web. Si rien n'écoute, les messages restent en file pendant quatre à cinq jours puis rebondissent. Pour signifier clairement que le domaine ne reçoit pas, publiez un null MX `0 .` plutôt que de tout supprimer.

Testez vos connaissances

À lire aussi

commande dig · client email · chiffrement email · cache