Enregistrement MX qui pointe vers un CNAME ou une adresse IP : pourquoi c'est invalide

Ce que ça veut dire

L'enregistrement MX indique aux autres serveurs mail où livrer les emails de votre domaine. Sa valeur est une priorité et un nom d'hôte, par exemple 10 mail.yourdomain.com. Ce nom d'hôte doit avoir son propre enregistrement A (IPv4) ou AAAA (IPv6).

Deux erreurs sont fréquentes :

• Un MX qui pointe vers une adresse IP : yourdomain.com MX 10 203.0.113.25. Ce n'est pas autorisé : la RFC 5321 précise que la valeur du MX est un nom de domaine, et une adresse n'y est pas valide.
• Un MX qui pointe vers un CNAME : la cible du MX, mail.yourdomain.com, est elle-même un CNAME vers un autre nom. La RFC 2181 (section 10.3) indique que la cible d'un MX ne doit pas être un alias.

Pourquoi cela arrive

• Une interface DNS permet de saisir une IP dans le champ MX, ou quelqu'un a pensé que c'était plus simple.
• Certaines interfaces traitent l'IP comme un nom relatif et publient 203.0.113.25.yourdomain.com, qui n'existe pas.
• L'hôte mail a été créé comme CNAME vers le nom du serveur de l'hébergeur (par exemple mail CNAME server12.host.example) pour éviter de mettre à jour les IP.
• La documentation d'un prestataire a été recopiée dans le mauvais type d'enregistrement.

Ce qui se passe en pratique

• Une IP dans le MX : beaucoup de serveurs d'envoi ne trouvent pas de nom d'hôte et échouent. Certains se rabattent sur l'enregistrement A du domaine (le serveur du site web), qui n'accepte généralement pas d'emails. Les résultats sont imprévisibles : certains expéditeurs arrivent à livrer, d'autres reçoivent une erreur, souvent avec des messages comme « Domain not found », « No MX for domain » ou « Host or domain name not found ».
• Un CNAME comme cible du MX : beaucoup de serveurs suivent l'alias et livrent quand même, ce qui explique que l'erreur passe inaperçue. Mais ce n'est pas conforme à la norme, certains serveurs et outils de validation stricts le refusent, et cela ajoute une requête de plus qui peut échouer.

Un domaine sans aucun MX est un autre problème, traité dans pas d'enregistrement MX sur votre domaine.

Comment vérifier

1. Ouvrez le scanner de domaine et saisissez votre domaine. Il liste vos enregistrements MX et leurs cibles.
2. Avec dig :

   dig MX yourdomain.com +short
   10 mail.yourdomain.com.
   
   dig CNAME mail.yourdomain.com +short
   (must be empty)
   
   dig A mail.yourdomain.com +short
   203.0.113.25

   Si la réponse MX est un nombre comme 203.0.113.25., ou si dig CNAME sur la cible renvoie un nom, vous avez l'un des problèmes décrits plus haut.
3. Sous Windows : nslookup -type=MX yourdomain.com.
4. Testez le serveur lui-même : nc -v mail.yourdomain.com 25 doit afficher un message d'accueil 220.

Comment corriger

MX qui pointe vers une IP

1. Créez un enregistrement A (et AAAA si vous utilisez l'IPv6) pour un nom d'hôte mail :

   Host: mail      Type: A      Value: 203.0.113.25

2. Modifiez le MX pour qu'il utilise ce nom :

   Host: @         Type: MX     Priority: 10     Value: mail.yourdomain.com

   Certaines interfaces exigent un point final (mail.yourdomain.com.), d'autres ajoutent le domaine pour vous ; vérifiez ce qu'affiche votre interface après l'enregistrement.

La cible du MX est un CNAME

Remplacez le CNAME de l'hôte mail par des enregistrements A/AAAA avec l'IP du serveur, ou faites pointer le MX directement vers le vrai nom d'hôte donné par votre prestataire (celui qui a l'enregistrement A) :

Before:
yourdomain.com.        MX 10  mail.yourdomain.com.
mail.yourdomain.com.   CNAME  server12.host.example.

After (option 1):
mail.yourdomain.com.   A      203.0.113.25

After (option 2):
yourdomain.com.        MX 10  server12.host.example.

Si vous utilisez Google Workspace, Microsoft 365 ou un autre prestataire, utilisez exactement les valeurs MX de leur page de configuration. Vérifiez aussi que l'hôte mail n'est pas proxifié par un CDN (voir les enregistrements Cloudflare proxifiés cassent l'email) et que son nom n'a pas d'autre CNAME en conflit (voir CNAME en conflit avec les enregistrements MX et TXT).

Votre propre serveur

Idéalement, le nom d'hôte du MX correspond au reverse DNS (PTR) du serveur et au nom de son certificat TLS, par exemple mail.yourdomain.com partout.

Vérifiez que c'est corrigé

Attendez l'expiration du TTL de l'ancien MX, puis relancez dig MX et vérifiez le résultat dans le scanner de domaine. Envoyez un email depuis une boîte extérieure (Gmail, Outlook) vers une adresse de votre domaine et vérifiez qu'il arrive. Si votre serveur envoie aussi des emails, lancez depuis celui-ci un test Delivmail pour vérifier le SPF, le DKIM et le reverse DNS.