Quand le courriel entrant commence à rebondir, le premier réflexe est de vérifier les enregistrements MX. C’est nécessaire mais rarement suffisant. Le MX peut être correct en DNS pendant qu’une des IP derrière a perdu son PTR, ou que l’écouteur SMTP a été coupé par un pare-feu, ou que l’hôte a déménagé et que le DNS n’a pas suivi. Le Diagnostic MX de PortJar passe toute la chaîne d’un coup — MX, A, PTR et joignabilité SMTP sur 25, 465 et 587 — pour que vous puissiez voir en quinze secondes si un serveur de courriel expéditeur a une vraie chance de vous livrer.
Ce que fait l’outil
Vous lui donnez un domaine et il parcourt les trois premiers hôtes MX en ordre de priorité. Pour chacun, il résout les enregistrements A et AAAA, capture le DNS inverse (PTR) pour la première IP, et sonde TCP/25, TCP/465 et TCP/587 depuis le réseau de PortJar pour voir si l’écouteur SMTP répond vraiment. La sortie regroupe tout par hôte MX pour que vous puissiez lire la situation d’un seul nom d’hôte sans perdre le contexte.
C’est la même chaîne qu’un serveur de courriel expéditeur parcourt quand il essaie de vous livrer. Si un maillon casse, le courriel s’empile, retente, et finit par rebondir. Voir l’échec ici veut dire qu’un expéditeur sur internet le voit aussi.
Comment l’utiliser
Ouvrez portjar.com/tools/mx-diagnostics, tapez le domaine du destinataire (la partie après le @, sans schéma, sans chemin), et lisez le résultat. Il y a un seul champ de formulaire et aucune option à régler — l’outil sonde toujours les ports SMTP standards contre les trois premiers hôtes MX.
Si vous ne voyez qu’un ou deux hôtes MX dans la sortie, le domaine n’en publie qu’un ou deux — c’est attendu pour beaucoup de petits opérateurs. Si un port apparaît comme « fermé » ou « filtré », c’est la réponse à pourquoi un expéditeur a de la difficulté, pas une erreur de l’outil.
Quand l’utiliser
- Un usager signale un rebond de courriel. Avant de lancer un tcpdump sur le serveur de courriel, faites le diagnostic depuis l’extérieur. Si tout est vert, le problème est du côté de l’expéditeur ; si quelque chose est rouge, vous l’avez isolé sans quitter le navigateur.
- Vous venez de basculer les enregistrements MX. Confirmez que la propagation a atteint un résolveur externe, que les nouvelles IP répondent en SMTP, et que le PTR pointe vers un nom qui résout en avant — les trois vérifications que tout récepteur fait.
- Dépannage de réputation. Un récepteur refuse le courriel avec « PTR ne correspond pas ». Le diagnostic vous montre le PTR que chaque IP MX retourne en pratique, ce qui expose habituellement qu’un hôte sur trois n’a jamais reçu d’enregistrement inverse en règle.
- Vérification d’écouteur après un changement de noyau ou de pare-feu. Les mises à niveau d’OS et les règles de pare-feu d’hôte brisent silencieusement le port 25 entrant plus souvent qu’on le pense. La sonde répond à « est-ce que l’écouteur accepte encore des connexions depuis internet » sans que vous ayez à vous asseoir sur un shell distant.
- Transfert de fournisseur. Un fournisseur de courriel infogéré prétend avoir déménagé le MX. Le diagnostic vous donne un rapport copiable — trois hôtes, leurs IP, leurs PTR et l’état des ports — qui confirme ou réfute la prétention en une page.
Quoi faire du résultat
Trois choses doivent être vertes pour que le courriel entrant fonctionne : le MX doit résoudre vers au moins une IP, cette IP doit avoir un PTR utilisable, et un des ports SMTP doit répondre. Si l’un des trois est cassé, vous avez la réponse à pourquoi le courriel échoue.
Une constatation « pas de PTR » sur un hôte parmi plusieurs est habituellement à faible impact — le serveur expéditeur va normalement basculer vers le prochain MX en priorité. Un PTR manquant sur tous les hôtes signifie qu’une part significative d’expéditeurs rejettera votre courriel d’emblée pour des raisons de réputation, avant même de lire un seul en-tête.
TCP/25 fermé avec TCP/465 et TCP/587 ouverts est courant — beaucoup de fournisseurs routent maintenant le courriel entrant par des ports alternatifs — mais un expéditeur sur internet essaiera presque toujours 25 en premier. Si vous voyez 25 fermé, confirmez que c’est une politique délibérée (et documentez le chemin alternatif pour les expéditeurs) plutôt qu’un changement de pare-feu accidentel.
Un SERVFAIL ou NXDOMAIN sur la résolution MX elle-même est la pire forme : il n’y a aucun chemin entrant du tout. C’est un problème DNS, pas un problème de courriel, et le correctif est chez le registraire ou le fournisseur DNS.
Pour les environnements où le courriel entrant doit rester joignable pendant que DNS, pare-feu et plateformes de courriel changent en dessous, Stack Harbor gère la discipline du chemin courriel dans le cadre de la gestion cPanel et WHM.