MX

MX est un terme informatique lié aux emails, et qui signifie “Mail eXchange“.

 

Il s’agit d’un enregistrement spécifique dans la zone DNS d’un domaine internet, qui permet de définir quel est le serveur SMTP chargé de recevoir les emails de ce domaine. Il représente donc un champ très important pour tout domaine internet qui dispose d’adresses emails et qui souhaite être en mesure de recevoir des emails de la part d’autres personnes.

 

Si ce champ vient à manquer et ne pas être déclaré sur la zone DNS d’un domaine internet, alors il sera impossible pour ce dernier de recevoir un quelconque email. Ainsi, si quelqu’un tente l’envoi d’un message par email sur une adresse email de ce domaine internet, la remise de ce dernier ne pourra pas aboutir et le serveur SMTP source émettra alors une notification de type hard bounce à l’adresse émettrice.
Ce cas de figure arrive également lorsque le champ MX existe mais contient une valeur erronée : adresse IP non routable, ou valeur FQDN cible invalide.

 

L’enregistrement MX d’un domaine ne constitue pas une information cachée ou confidentielle d’un domaine : tout le monde peut librement connaître sa valeur, ce qui est normal car cette information est nécessaire afin de pouvoir envoyer un message sur une adresse email appartenant à ce domaine.

 

Voici pour exemple l’entrée MX du domaine mailnjoy.com :

 

1 aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

 

On voit ici qu’un enregistrement MX se matérialise par une (ou plusieures) ligne commençant par un nombre, et suivi d’un nom FQDN (ou d’une adresse IP) :

 

– Le nombre représente le poid associé à l’entrée MX en question, et à une importance uniquement dans le cadre de multiples entrées MX présentes, afin de déterminer quelle est le serveur SMTP prioritaire à contacter parmis ceux existants

Le champ FQDN (ou adresse IP) qui suis le nombre, représente le nom du serveur SMTP concerné par l’entrée MX. C’est ce serveur qui sera utilisé par le serveur SMTP source pour envoyer le message à destination de l’adresse email cible

 

Il est donc possible (et même recommandé) de définir plusieurs entrées MX sur un domaine, afin d’indiquer plusieurs serveurs SMTP capables de recevoir les emails adressés sur ce domaine, et ainsi assurer la haute disponibilité du service email en cas ou un serveur serait éteint ou dysfonctionnel. Les différents poids (priorités) associés à chaque ligne sont également utiles pour donner un ordre préférentiel de contact et définir ainsi les serveurs primaires et les serveurs secondaires.

 

Par exemple lors de l’envoi d’un message à destination de l’adresse “example@france.com”, la séquence d’envoi du serveur SMTP source est la suivante :

 

a) déterminer quel est le domaine (ou le sous domaine) concerné : ici il s’agit de “france.com”

b) déterminer quel est la valeur du champ MX de ce domaine :

 

1 mx4.mail.ovh.net.
10 mx3.mail.ovh.net.

 

c) comme il y a plusieurs enregistrements MX sur ce domaine, le serveur doit déterminer lequel il va utiliser en priorité : il s’agit de celui ayant le poid le plus faible : mx4.mail.ovh.net.

d) envoyer le message au destinataire en contactant le serveur SMTP choisi (ici : mx4.mail.ovh.net)

 

Il n’est pas possible de définir dans son champ MX plusieurs providers emails différents (pour un domaine internet donné) : par exemple les MX de Google et en même temps les MX de Microsoft. Même si techniquement parlant rien n’empêche de réaliser ce type de configuration dans les entrées MX du domaine, le fonctionnement résultant sera dysfonctionnel car il ne sera pas possible de prévoir de manière sûre ou seront acheminés les emails reçus : certains seront envoyés sur Google, alors que d’autres envoyés sur Microsoft, résultant en une perte de certains d’entre eux.
Cependant, le champs MX est parfois utilisé dans une manière un peu similaire avec de “fausses entrées”, afin d’implémenter des techniques antispam, notamment au travers du mécanisme de nolisting

 

Contrairement aux idées reçues, le serveur faisant office de MX dans un domaine internet n’est pas forcément le même serveur qui servira dans l’envoi des emails sortant de ce même domaine. En effet, même si dans une configuration simplifiée cela peut en effet être le cas, la majorité du temps le serveur de réception (MX) sera différent du serveur d’envoi (MTA).
Il est d’ailleurs courant que l’architecture globale de la chaîne Emailing d’un domaine soit plus complexe et fasse appel à des serveurs de relais internes, ou des passerelles antispam spécifiques (telle que le service mailinblack) qui servent de relai vers les véritables MX d’un domaine après avoir vérifié le contenu des email reçus.

 

Le bon routage des emails au travers d’internet étant basé sur les informations définies dans le champs MX du DNS, il est donc primordial que ce dernier soit sécurisé et ne puisse pas être modifié ou piraté par une tierce personne, car cela entraînerait alors la réception de l’ensemble des emails nouvellement reçus sur le domaine par les personnes malveillantes. La sécurisation du DNS pour éviter le cache poisoning, ainsi que l’utilisation du mécanisme de DNSSEC devenant alors des éléments quasi-incontournables pour s’affranchir de ce type de risques.