MX record : tout savoir sur cet en­re­gis­tre­ment DNS

L’en­re­gis­tre­ment MX (Mail Exchange record) est un en­re­gis­tre­ment DNS qui indique quel serveur de mes­sa­ge­rie est res­pon­sable de la réception des emails d’un domaine. Il permet de s’assurer que les emails entrants sont cor­rec­te­ment acheminés vers le bon serveur.

Qu’est-ce qu’un en­re­gis­tre­ment MX ? Ex­pli­ca­tion et exemple

On trouve les en­re­gis­tre­ments (records) DNS dans les fichiers de zone. Ce sont de simples fichiers texte qui compilent tous les en­re­gis­tre­ments pour la zone qui est prise en charge par le serveur cor­res­pon­dant. Si un client dépose une requête, le serveur qui répond ira d’abord chercher ses éléments de réponse dans ce fichier de zone. Chaque type d’en­re­gis­tre­ment a cependant sa fonction spé­ci­fique. L’abré­via­tion MX vient de Mail Exchange, ce qui indique clai­re­ment la fonction par­ti­cu­lière de ce type d’en­re­gis­tre­ment. Le record MX informe donc le client du domaine où est dis­po­nible le serveur de mes­sa­ge­rie élec­tro­nique via le DNS.

Un domaine est gé­né­ra­le­ment composé de plusieurs serveurs. En plus du serveur Web, utilisé pour la pu­bli­ca­tion du site, on a par exemple un serveur FTP, ainsi qu’un ou plusieurs serveurs de mes­sa­ge­rie. Tous ces serveurs sont ac­ces­sibles au moyen de dif­fé­rents sous-domaines. Pour connaître ces sous-domaines, on consulte l’en­re­gis­tre­ment MX. Le serveur mail émetteur du courrier élec­tro­nique procède gé­né­ra­le­ment à cette con­sul­ta­tion de manière au­to­ma­tique.

Champs et syntaxe des en­re­gis­tre­ments

Les records DNS ren­fer­ment gé­né­ra­le­ment plusieurs in­for­ma­tions réparties dans plusieurs champs. On y trouve une in­di­ca­tion sur le serveur de mes­sa­ge­rie, qui est associé à un domaine spé­ci­fique, mais aussi toutes sortes d’autres détails :

• <name> : le premier champ renferme le nom du domaine.
• <ttl> : « Time to live », précise la durée de validité des in­for­ma­tions.
• <class> : le champ de classe précise le type de réseau.
• <type> : ici, le type d’en­re­gis­tre­ment est MX.
• <priority> : plus la valeur est petite, plus la priorité du serveur de mes­sa­ge­rie sera grande.
• <rdata> : le champ Ressource Data précise le nom du serveur de mes­sa­ge­rie.

Les noms des en­re­gis­tre­ments DNS sont en­re­gis­trés au format Fully Qualified Domain Name (FQDN). Le contenu de chacun des champs est terminé par un point. Les FQDN composent en effet le chemin complet, depuis la plus petite unité à gauche, jusqu’à la plus grande unité à droite, à savoir le serveur-racine. Le niveau supérieur n’a cependant aucune dé­sig­na­tion, ce qui explique l’absence de données derrière le point qui le précède.

Le champ Time to Live précise la durée pendant laquelle les in­for­ma­tions seront valides et con­ser­vées dans le cache de votre or­di­na­teur. Ce champ permet de garantir que vous n’uti­li­se­rez pas d’en­re­gis­tre­ments périmés. Dès que ce délai est passé, le client doit re­nou­ve­ler sa requête auprès du serveur de noms. L’in­di­ca­tion TTL est exprimée en secondes. Très souvent, ce champ est tout sim­ple­ment ignoré dans un en­re­gis­tre­ment. Il est en effet possible d’en­re­gis­trer préa­la­ble­ment cette durée pour l’ensemble de la zone.

Le champ Class est fa­cul­ta­tif, pour la simple et bonne raison que le seul réseau dis­po­nible aujourd’hui est celui d’Internet. Lorsque les en­re­gis­tre­ments de res­sources ont vu le jour, il existait encore les classes Hesiod (HS) et Chaos (CH). Ces deux réseaux ne sont plus dis­po­nibles aujourd’hui. C’est pourquoi ce champ reste vide ou renferme uni­que­ment les lettres IN.

Le champ Priority est une par­ti­cu­la­rité des en­re­gis­tre­ments MX. Dans les projets d’une certaine envergure, il n’est pas rare que les ad­mi­nis­tra­teurs utilisent plusieurs serveurs en parallèle. Cela leur permet d’anticiper d’éven­tuelles pannes ou des pics de con­sul­ta­tions, et d’éviter des problèmes, voire des pannes complètes de leur système de mes­sa­ge­rie élec­tro­nique. La ré­par­ti­tion ne doit cependant pas toujours se faire de manière égale. C’est pour cette raison que sont définies certaines priorités. Le serveur doté de la plus faible valeur prime sur les autres, et sera consulté en premier. S’il n’est pas dis­po­nible, on in­ter­ro­gera le serveur ayant la valeur suivante.

Le champ Data contient le nom du serveur de mes­sa­ge­rie élec­tro­nique. Celui-ci est aussi en­re­gis­tré en res­pec­tant la forme des FQDN. Tous les champs d’un en­re­gis­tre­ment sont saisis à la suite, sur une même ligne. Il n’est pas né­ces­saire de taper un caractère par­ti­cu­lier pour clore un en­re­gis­tre­ment : un retour à la ligne suffit.

Exemple d’en­re­gis­tre­ment MX

Prenons le cas fictif du serveur de mes­sa­ge­rie du site example.com. Inventons une adresse email qu’on appellera user@example.com. Le serveur Web de l’ex­pé­di­teur envoie sa requête DNS au domaine example.com. Les en­re­gis­tre­ments contenus dans le fichier de zone du serveur de nom se pré­sen­tent de la manière suivante :

$TTL 1200
example.com.	IN	A		93.184.216.34
example.com.	IN	MX	10	mail1.example.com.
example.com.	IN	MX	10	mail2.example.com.
example.com.	IN	MX	50	mail3.example.com.

Comme vous pouvez le voir, la durée de validité des données s’applique ici à l’ensemble de la zone. Il est donc inutile de ren­seig­ner ce champ pour chaque en­re­gis­tre­ment en par­ti­cu­lier. Cet exemple renferme tout d’abord un en­re­gis­tre­ment A qui associe un nom de domaine à une adresse IP. Suivent trois en­re­gis­tre­ments MX. Le seul élément qui les dif­fé­ren­cie, c’est leur sous-domaine.

Dans cet exemple, les deux premiers serveurs de mes­sa­ge­rie ont le même ordre de priorité (10). Les tâches sont donc équi­ta­ble­ment réparties sur ces deux serveurs. Le 3ème serveur prendra la relève uni­que­ment sur les deux autres qui ne peuvent pas assimiler le travail, en cas de surcharge ou de panne.

Créer des en­re­gis­tre­ments MX de manière sécurisée

Lorsque vous créez des en­re­gis­tre­ments MX, vous devez mettre l’accent sur la sécurité et la pré­ven­tion des erreurs. Ainsi, ils ne doivent jamais faire di­rec­te­ment référence à des adresses IP, mais toujours à des noms de domaine plei­ne­ment qualifiés, qui sont eux-mêmes résolus via des en­re­gis­tre­ments A ou AAAA. De plus, il est interdit d’utiliser un en­re­gis­tre­ment CNAME comme cible d’un en­re­gis­tre­ment MX, car cette pratique enfreint les normes DNS et peut donc entraîner des problèmes de dé­li­vra­bi­lité. Les serveurs de mes­sa­ge­rie cibles doivent être cor­rec­te­ment résolus et ac­ces­sibles via DNS, sinon, il existe un risque de messages d’erreur ou de perte des emails.

Pour éviter le spam et le spoofing, il faut également définir des en­re­gis­tre­ments SPF, DKIM et DMARC qui ga­ran­tis­sent l’au­then­ti­cité du domaine de l’ex­pé­di­teur. Ces trois en­re­gis­tre­ments sont des mé­ca­nismes de pro­tec­tion de l’email :

• SPF garantit que seuls les serveurs autorisés peuvent envoyer des emails au nom d’un domaine.
• DKIM garantit que les emails sont signés nu­mé­ri­que­ment et protégés contre les ma­ni­pu­la­tions.
• DMARC donne aux des­ti­na­taires des règles sur la manière de traiter les emails non au­then­ti­fiés.

Con­fi­gu­rer un en­re­gis­tre­ment MX

Si vous souhaitez gérer vos com­mu­ni­ca­tions mail pro­fes­sion­nelles avec Google Workspace ou Microsoft 365, il est obli­ga­toire de con­fi­gu­rer un en­re­gis­tre­ment MX correct dans la zone DNS de votre domaine. C’est la seule façon de s’assurer que les emails entrants sont délivrés de manière fiable aux serveurs de mes­sa­ge­rie du four­nis­seur concerné.

Con­fi­gu­rer un en­re­gis­tre­ment MX sur Google Workspace

Si vous souhaitez envoyer des emails via l’outil de col­la­bo­ra­tion Google Workspace, vous devez en­re­gis­trer le serveur de mes­sa­ge­rie officiel de Google en tant que record MX dans la zone DNS de votre domaine. La marche à suivre est très simple :

1. Supprimez tous les en­re­gis­tre­ments MX existants.
2. Ajoutez l’en­re­gis­tre­ment MX suivant pour le serveur de mes­sa­ge­rie de Google :

@	IN	MX	1	smtp.google.com.

3. Connectez-vous à la console d’ad­mi­nis­tra­tion Google avec votre compte admin et accédez à vos domaines via les pa­ra­mètres du compte. Activez Gmail pour le domaine dont vous souhaitez mettre à jour l’en­re­gis­tre­ment MX.

L’en­re­gis­tre­ment MX peut prendre jusqu’à 72 heures avant d’être actif.

Con­fi­gu­rer un en­re­gis­tre­ment MX avec Microsoft 365

Avec Microsoft 365 aussi, vous pouvez fa­ci­le­ment con­fi­gu­rer un en­re­gis­tre­ment MX pour votre domaine, afin que les emails envoyés aux personnes utilisant ce domaine soient redirigés vers Microsoft 365. La procédure est similaire à celle déjà décrite.

1. Supprimez tous les en­re­gis­tre­ments MX existants.
2. Connectez-vous au centre d’ad­mi­nis­tra­tion de Microsoft 365. Cliquez sur « Tout afficher » > « Pa­ra­mètres » > « Domaines ». Vous y trouverez l’en­re­gis­tre­ment MX à utiliser.
3. Copiez l’en­re­gis­tre­ment MX, collez-le chez votre four­nis­seur d’hé­ber­ge­ment et en­re­gis­trez les mo­di­fi­ca­tions.

Comment faire pour vérifier un record MX ?

Pour procéder à une recherche d’en­re­gis­tre­ments MX, vous pouvez recourir à dif­fé­rents services en ligne. Le service Public DNS de Google constitue une option facile à utiliser. Sur la page d’accueil, il vous suffit d’indiquer le nom du domaine dont vous souhaitez connaître les records MX. Sur la page suivante, modifiez le type d’en­re­gis­tre­ment de A à MX. Il est inutile de modifier les options EDNS Client Subnet et DNSSEC. La première de ces options permet d’accélérer la recherche des in­for­ma­tions DNS. La deuxième option garantit le fait que les données n’ont pas été ma­ni­pu­lées par une tierce partie à des fins cri­mi­nelles.

Vé­ri­fi­ca­tion d’un record MX avec Google Public DNS

Dans cet exemple, on retrouve le serveur de mes­sa­ge­rie en dessous de la ligne « Answer ». Sous la ligne intitulée Data se trouvent les FQDN per­met­tant d’accéder à ces serveurs. On y trouve aussi une précision quant au degré de priorité : ici, l’en­re­gis­tre­ment a une priorité de 10. Le champ Type renferme la même valeur 15. Cette valeur cor­res­pond à l’en­re­gis­tre­ment MX. L’Internet Assigned Numbers Authority (IANA) a assigné à chaque type d’en­re­gis­tre­ment DNS une valeur spé­ci­fique, per­met­tant ainsi à chaque type d’avoir son propre numéro.