Recherche MX

Un enregistrement MX (Mail Exchange) indique au reste d'internet quel serveur reçoit les emails pour un domaine. Il n'envoie rien et n'a aucun rapport avec l'hébergement du site : un domaine peut très bien pointer son enregistrement A vers un hébergeur et ses enregistrements MX vers un service de messagerie totalement différent. C'est pour cela qu'un changement d'hébergeur web ne casse jamais la messagerie, et qu'un passage chez Google Workspace ou Microsoft 365 se limite à modifier les MX - rien d'autre.

Chaque enregistrement MX associe un nom de serveur (l'"exchange") à une priorité numérique. Quand un serveur expéditeur veut livrer un message, il interroge les enregistrements MX du domaine destinataire, les trie par priorité, et essaie d'abord le chiffre le plus bas. Si ce serveur refuse la connexion ou ne répond pas, la livraison bascule sur la priorité suivante. La RFC 5321 définit ce comportement comme faisant partie du standard SMTP.

Un domaine sans enregistrement MX n'est pas forcément injoignable : la RFC 5321 autorise un repli sur l'enregistrement A du domaine, port 25, en l'absence de MX. En pratique, presque aucun fournisseur de messagerie ne s'appuie sur ce repli, donc un MX absent équivaut, pour l'essentiel des cas, à une messagerie non configurée.

• Le chiffre de priorité le plus bas l'emporte - 10 est essayé avant 20
• Plusieurs enregistrements à la même priorité sont utilisés en round-robin pour répartir la charge
• Le nom de serveur d'un enregistrement MX doit résoudre via un A ou un AAAA - jamais un CNAME (RFC 2181, section 10.3)
• Un enregistrement MX ne transporte pas d'adresse IP directement ; le résolveur interroge séparément le nom du serveur de destination

Une recherche sur un domaine fonctionnel renvoie une ligne par serveur de messagerie, avec sa priorité et son nom d'hôte. L'outil résout également chaque nom d'hôte pour vérifier qu'il possède bien un enregistrement A ou AAAA valide - un MX qui pointe vers un nom sans enregistrement d'adresse est une erreur de configuration, puisque le serveur expéditeur n'a alors rien vers quoi se connecter.

Les valeurs de priorité ne suivent aucune échelle standardisée au-delà du principe "le plus bas gagne" - un fournisseur utilisera 1 et 10, un autre 5 et 20, un troisième 0 et 50. Seul l'ordre relatif entre les enregistrements d'un même domaine compte.

La panne la plus courante est un enregistrement MX resté en place après un changement de fournisseur de messagerie - les emails continuent d'être acheminés vers un serveur mis hors service, et selon ce que fait ce serveur avec les connexions inattendues, ils rebondissent ou disparaissent silencieusement.

Juste derrière : un MX qui pointe vers un CNAME au lieu d'un enregistrement A ou AAAA. La RFC 2181 l'interdit explicitement, et même si certains résolveurs tolèrent la chaîne de CNAME par indulgence, de nombreux agents de transport de messagerie rejettent purement et simplement l'enregistrement et refusent la livraison.

Un troisième cas fréquent : un unique enregistrement MX sans aucun secours. Si ce serveur tombe en panne, les emails entrants s'accumulent côté expéditeur (la plupart des serveurs bien configurés réessaient pendant plusieurs jours selon la RFC 5321), mais rien n'est livré tant que le serveur n'est pas revenu - aucune redondance sur laquelle se rabattre.

Une égalité de priorité involontaire arrive aussi souvent : deux enregistrements à la priorité 10 alors que l'intention était un ordre strict principal/secours. Comme les enregistrements de même priorité sont utilisés indifféremment, cela annule silencieusement une bascule qui supposait qu'un serveur serait toujours préféré à l'autre.