Enregistrement MX qui ne fonctionne pas : diagnostiquer et corriger le routage des e-mails

Lorsqu'un enregistrement MX ne fonctionne pas, la cause est presque toujours l'une de ces cinq : une cible CNAME au lieu d'un nom d'hôte A/AAAA, une faute de frappe ou un point final manquant dans la cible, des valeurs de priorité erronées ou en double, des enregistrements laissés par un ancien fournisseur de messagerie, ou un DNS qui ne s'est tout simplement pas encore propagé. Les échecs de distribution des e-mails signifient rarement que le DNS est « cassé » : ils signifient qu'un enregistrement précis ne correspond pas à ce qu'attend le serveur de messagerie expéditeur. Ce guide passe en revue chaque cause et la manière de la confirmer.

À quoi sert réellement un enregistrement MX

Un enregistrement MX (Mail Exchange) indique aux serveurs de messagerie expéditeurs quel hôte accepte les e-mails pour votre domaine. Chaque enregistrement MX comporte deux parties, définies dans la RFC 1035 : une préférence (souvent appelée priorité) et un échangeur (le nom d'hôte du serveur de messagerie). Les valeurs de préférence les plus basses sont essayées en premier : un MX de préférence 10 est utilisé avant un MX de préférence 20.

Une règle essentielle de la RFC 5321 (la norme SMTP) et de la RFC 2181 : la cible du MX doit se résoudre en un enregistrement A ou AAAA, jamais en un CNAME, et jamais en une simple adresse IP. Si vous faites pointer un MX vers un alias, certains serveurs destinataires et expéditeurs le rejetteront purement et simplement ou se comporteront de façon imprévisible. Cette seule erreur de configuration est à l'origine d'une grande part des tickets « la messagerie ne fonctionne pas ».

Étape 1 : interroger l'enregistrement en ligne, pas votre panneau de contrôle

Le tableau de bord de votre registrar peut être en retard sur ce qui est réellement publié sur Internet. Interrogez directement le DNS :

dig MX yourdomain.com

ou

nslookup -type=MX yourdomain.com

Ces deux commandes contournent votre cache local et interrogent directement un résolveur, de sorte que vous voyez ce que voient réellement les serveurs de messagerie du monde entier. Vous pouvez aussi faire une vérification rapide sans terminal grâce à notre outil de recherche MX gratuit : c'est le moyen le plus rapide de confirmer ce qui est actuellement publié avant de modifier quoi que ce soit.

TipVérifiez toujours le MX depuis un outil externe ou un autre réseau. Un enregistrement peut sembler correct depuis le Wi-Fi de votre bureau (qui a mis en cache l'ancienne réponse) alors que le reste d'Internet voit déjà le nouveau, ou inversement.

Cause fréquente 1 : le MX pointe vers un CNAME

Si dig MX renvoie une cible qui possède elle-même un enregistrement CNAME, par exemple mail.yourdomain.com qui est un CNAME vers ghs.example.net, c'est invalide selon les RFC 1035/5321. Corrigez-le en faisant pointer l'enregistrement MX directement vers un nom d'hôte doté de son propre enregistrement A/AAAA, ou en utilisant le nom d'hôte canonique du fournisseur de messagerie (qu'il a déjà correctement configuré de son côté).

Cause fréquente 2 : point final ou fautes de frappe dans le nom d'hôte

Dans un fichier de zone brut, un nom de domaine pleinement qualifié doit se terminer par un point final (mail.yourdomain.com.). Si vous l'oubliez, certains logiciels DNS ajoutent silencieusement votre domaine à la fin, ce qui produit un résultat erroné comme mail.yourdomain.com.yourdomain.com.. La plupart des tableaux de bord de registrar modernes ajoutent le point final automatiquement, mais si vous modifiez directement des fichiers de zone (ou utilisez notre gestion DNS avec saisie manuelle des enregistrements), il vaut la peine de vérifier la valeur exacte exigée par votre fournisseur.

Vérifiez également :

• Le champ Hôte/Nom est défini sur @ (ou laissé vide) pour la messagerie du domaine racine, et non sur mail ou le nom de domaine complet répété.
• Le nom d'hôte cible ne contient aucun espace parasite et correspond exactement à celui fourni par votre fournisseur de messagerie.

Cause fréquente 3 : priorités erronées ou en double

Les valeurs de priorité (préférence) déterminent l'ordre de basculement, et non quel enregistrement est « principal » d'après son nom. Une configuration comme celle-ci est valide et attendue :

Les serveurs expéditeurs essaient d'abord la priorité 10 et ne se rabattent sur la 20 que si la première est injoignable. Les problèmes apparaissent lorsque :

• Deux enregistrements partagent la même priorité alors qu'ils ne le devraient pas : les e-mails sont répartis aléatoirement entre eux au lieu de basculer dans l'ordre.
• Un serveur mis hors service conserve un nombre plus bas (donc une priorité plus élevée) que le serveur actif, si bien que les expéditeurs continuent d'essayer d'abord l'hôte mort.

Google Workspace recommande désormais un seul enregistrement MX, smtp.google.com en priorité 1, en remplacement de l'ancienne configuration à plusieurs enregistrements ASPMX.L.GOOGLE.COM. Microsoft 365 génère automatiquement un enregistrement, généralement yourdomain-com.mail.protection.outlook.com en priorité 0, lorsque vous validez le domaine. Si vos enregistrements ne correspondent pas à la configuration actuellement documentée par votre fournisseur, c'est cet écart qui pose problème.

Cause fréquente 4 : enregistrements résiduels d'un ancien fournisseur

Une erreur de migration très courante : vous passez de votre ancien hébergeur à Google Workspace ou Microsoft 365, vous ajoutez les nouveaux enregistrements MX, mais vous ne supprimez jamais les anciens. Les enregistrements MX de deux fournisseurs sont alors actifs en même temps, et les e-mails sont répartis ou rejetés selon la priorité qui l'emporte. Listez toujours tous les enregistrements MX du domaine et supprimez tout ce qui n'appartient pas à votre fournisseur actuel.

Cause fréquente 5 : délai de propagation

Si l'enregistrement est correct mais que la messagerie se comporte toujours mal, vérifiez le TTL (time to live) de l'enregistrement. Certains résolveurs mettent les réponses en cache pendant toute la durée de leur TTL, même après la publication d'un correctif, et certaines couches de cache les conservent plus longtemps quel que soit le TTL plus court que vous avez défini. Attendez la fin de la fenêtre du TTL avant de conclure que le correctif n'a pas pris, et revérifiez avec un outil de recherche externe plutôt qu'avec votre propre navigateur ou client de messagerie, qui peut utiliser un cache local obsolète.

Aucun enregistrement MX : est-ce valide ?

Oui, dans un cas précis. La RFC 7505 définit le Null MX : un enregistrement unique de préférence 0 et de cible . (un point seul), qui indique explicitement aux expéditeurs « ce domaine n'accepte aucun e-mail, inutile de réessayer ». C'est volontaire pour les domaines utilisés uniquement pour des sites web, et non pour l'e-mail : ce n'est pas une erreur de configuration si vous l'avez défini délibérément.

S'il n'existe réellement aucun enregistrement MX ni aucun Null MX, la RFC 5321 indique que les expéditeurs doivent se rabattre sur l'enregistrement A/AAAA du domaine comme hôte de messagerie implicite, mais s'appuyer sur ce repli est fragile et de moins en moins pris en charge par les systèmes de messagerie récents. N'en dépendez pas ; ajoutez plutôt un MX explicite ou un Null MX.

Le MX semble correct mais les e-mails ne sont toujours pas distribués

Si dig MX renvoie exactement ce que vous attendez et que les priorités sont cohérentes, le problème se situe généralement en aval du routage, et non dans l'enregistrement MX lui-même :

• Enregistrement SPF manquant ou incorrect, ce qui pousse les serveurs destinataires à rejeter les e-mails ou à les marquer comme spam : consultez notre guide pour créer un enregistrement SPF sécurisé.
• Signature DKIM absente.
• Un pare-feu sur le serveur de messagerie qui bloque le port 25 ou 587.

Ce sont des problèmes de délivrabilité, pas des problèmes de MX, mais ils se manifestent de la même manière pour les utilisateurs finaux (« l'e-mail ne fonctionne pas ») : il vaut la peine de les écarter une fois l'enregistrement MX lui-même validé. Pour une vue d'ensemble de la place du MX aux côtés des enregistrements A, TXT, CAA et autres, consultez notre guide des types d'enregistrements DNS.

Que signifient les messages de rejet

Les serveurs de messagerie signalent les problèmes de MX avec leurs propres formulations, et c'est généralement ce texte exact que l'on recherche. Les deux plus courants :

"No MX record found for domain=example.com; reason=empty DNS record" : le serveur expéditeur a demandé au DNS les enregistrements MX du domaine destinataire et a reçu une réponse valide, mais vide. Le DNS a fonctionné ; le domaine ne publie simplement aucune route de messagerie. Causes typiques :

• L'adresse contient une faute de frappe, ou le domaine ne reçoit pas d'e-mails du tout.
• Les enregistrements MX ont été perdus lors d'un déménagement DNS : ils existent toujours chez l'ancien fournisseur, mais les serveurs de noms pointent désormais vers un nouveau où personne ne les a recréés.
• L'adresse se trouve sur un sous-domaine (user@mail.example.com). Les enregistrements MX ne sont pas hérités : le sous-domaine a donc besoin de son propre MX, même si le domaine parent en possède un.
• Le domaine publie volontairement un Null MX (voir ci-dessus), que certains serveurs signalent de la même façon.

Vérifiez avec dig MX example.com +short et dig NS example.com +short. Une réponse MX vide de la part des serveurs de noms auxquels le domaine est réellement délégué le confirme ; ajoutez le MX à cet endroit, et non chez le fournisseur que vous avez modifié en dernier.

"Temporary error looking up MX record … timed out" : ici, c'est la recherche elle-même qui a échoué : aucune réponse n'est revenue. Cela désigne les serveurs de noms du domaine, et non ses enregistrements : ils sont hors service, injoignables, ou la délégation désigne des serveurs qui ne servent plus la zone. Une chaîne DNSSEC rompue produit le même effet : les résolveurs validants renvoient SERVFAIL. Les expéditeurs considèrent l'erreur comme temporaire et réessaient pendant quelques jours, si bien que les e-mails sont retardés plutôt que perdus, jusqu'à épuisement des tentatives. Interrogez chaque serveur de noms directement (dig @ns1.example.net MX example.com) pour trouver celui qui ne répond pas.

Liste de vérification rapide

• Lancez dig MX yourdomain.com ou utilisez l'outil de recherche MX pour confirmer ce qui est réellement publié.
• Vérifiez que le nom d'hôte cible n'est pas un CNAME et qu'il se résout en un enregistrement A/AAAA.
• Recherchez les problèmes de format liés au point final si vous modifiez des fichiers de zone bruts.
• Vérifiez que les valeurs de priorité correspondent à la configuration actuellement documentée par votre fournisseur, sans doublons orphelins.
• Supprimez les anciens enregistrements MX de tout fournisseur de messagerie précédent.
• Attendez la fin de la fenêtre du TTL avant de retester après une modification.

Si vous gérez le DNS de plusieurs domaines chez différents registrars, garder la cohérence des enregistrements MX, SPF et autres enregistrements de messagerie devient plus difficile à mesure que la liste s'allonge : notre gestion DNS vous offre un endroit unique pour vérifier et modifier les enregistrements chez tous vos fournisseurs, au lieu de les traquer séparément.