Vérificateur d’enregistrements MX

À propos de cet outil

Vérifiez les enregistrements MX de votre domaine pour la configuration email. Cet outil est entièrement gratuit et fonctionne directement dans votre navigateur, sans nécessiter d'installation.

Comment utiliser le vérificateur MX

1. Entrez le nom de domaine à analyser
2. Cliquez sur "Vérifier" pour interroger les enregistrements MX
3. Consultez la liste des serveurs de messagerie et leurs priorités
4. Vérifiez que les serveurs répondent correctement

Exemples de configurations MX

• Google Workspace : ASPMX.L.GOOGLE.COM (priorité 1)
• Microsoft 365 : domaine.mail.protection.outlook.com
• Serveur dédié : mail.example.com (priorité 10)
• Backup MX : Serveur secondaire avec priorité plus haute (20, 30...)

La préférence ordonne les essais, elle ne répartit pas la charge

Le serveur expéditeur trie les MX par préférence croissante et contacte le plus bas en premier. 0 passe avant 10, qui passe avant 50. Il ne bascule sur le suivant que si la connexion échoue ou si le serveur répond par un code temporaire 4xx.

Quand plusieurs MX partagent la même préférence, la RFC 5321 demande de tirer l’ordre au hasard entre eux. C’est la seule répartition que le MX sait faire, et elle est grossière : pas de poids, pas de notion de charge réelle, contrairement au champ weight d’un enregistrement SRV. Si vous voulez envoyer 80 % du trafic vers un site et 20 % vers l’autre, le MX n’est pas l’outil.

Le MX de secours à préférence haute vient des époques où les liaisons tombaient souvent. Il pose aujourd’hui un problème concret : beaucoup d’expéditeurs indésirables visent directement la préférence la plus élevée, en pariant que ce relais filtre moins bien que le principal. Si votre secours ne connaît pas la liste exacte des destinataires valides, il accepte des messages pour des adresses inexistantes puis génère des rebonds vers des expéditeurs falsifiés. Mieux vaut alors n’avoir aucun secours.

• 10 mx1.example.com. et 10 mx2.example.com. : les deux reçoivent, dans un ordre aléatoire d’un expéditeur à l’autre
• 10 mx1.example.com. et 50 backup.example.com. : le second n’est contacté que si le premier ne répond pas
• 1 smtp.google.com. : la configuration Google Workspace recommandée depuis 2023, un seul enregistrement au lieu des cinq ASPMX historiques
• 0 . : le null MX, qui annonce que le domaine ne reçoit pas de courrier

Les quatre erreurs qui font rebondir le courrier

Un MX qui pointe vers un CNAME. La RFC 2181, section 10.3, l’interdit sans ambiguïté. Certains serveurs suivent quand même l’alias, d’autres abandonnent. Vous obtenez alors une messagerie qui fonctionne depuis Gmail et échoue depuis un Postfix strict, avec un utilisateur qui vous jure que « ça marche chez lui ».

Le point final oublié. Dans un fichier de zone BIND, mail.example.com sans point devient mail.example.com.example.com. Les interfaces DNS hébergées ajoutent souvent le point à votre place, BIND non.

L’absence totale de MX. La RFC 5321, section 5.1, prévoit un repli sur l’enregistrement A ou AAAA du domaine, traité comme un MX de préférence 0. Un domaine sans MX mais avec un A qui pointe vers le serveur web recevra donc son courrier sur ce serveur web, où en général rien n’écoute sur le port 25. Le message reste en file chez l’expéditeur, qui réessaie pendant quatre à cinq jours (durée que la RFC 5321 recommande comme minimum) avant d’émettre un rapport de non-remise définitif. Quatre jours de silence, puis un rebond : le pire des scénarios pour un client qui vous écrit.

Le domaine qui ne doit jamais recevoir de courrier et qui ne le dit pas. Pour une marque défensive ou un domaine de redirection, publiez example.com. IN MX 0 . : c’est le null MX de la RFC 7505. La cible est la racine, les expéditeurs conformes rejettent tout de suite avec un code 5xx au lieu de faire patienter le message cinq jours.

Vérifier ses MX avant d’appeler l’hébergeur

La première commande à taper est dig MX example.com +short. Elle renvoie une ligne par enregistrement, préférence puis nom d’hôte, exactement ce qu’un serveur expéditeur voit. Sur gmail.com par exemple, vous obtenez une cible principale en préférence 5 et quatre alternatives en 10, 20, 30 et 40 : refaites le test chez vous, ces valeurs peuvent changer.

Le piège du diagnostic est le cache. Votre box ou votre résolveur d’entreprise peut servir l’ancienne réponse pendant toute la durée du TTL précédent. Interrogez un résolveur public pour trancher, et testez aussi depuis l’extérieur du réseau qui héberge le serveur : une vue DNS interne (split horizon) renvoie parfois un MX différent de la vue publique, et c’est la vue publique qui décide.

Avant une migration de messagerie, abaissez le TTL des MX à 300 secondes au moins 24 heures avant la bascule, laissez les anciens caches expirer, puis remontez à 3600 une fois la nouvelle configuration validée.

• dig MX example.com +short : la liste brute, préférence et cible
• dig MX example.com @1.1.1.1 : contourne le cache local pendant une migration
• dig A mail.example.com +short : confirme que la cible a bien une adresse, l’oubli le plus fréquent
• dig MX example.com +trace : remonte depuis la racine quand la délégation elle-même est suspecte
• nslookup -type=mx example.com : l’équivalent sous Windows sans outil supplémentaire
• openssl s_client -starttls smtp -connect mail.example.com:25 : vérifie qu’un MTA répond vraiment et présente son certificat