Recherche MX :
votre serveur de messagerie répond-il ?
Saisissez un domaine — l’outil liste chaque hôte MX par ordre de priorité, résout chacun d’eux et vérifie que son DNS inversé pointe vers la même adresse IP. Il se connecte ensuite sur le port 25, lit la bannière et teste STARTTLS. Le DNS vous indique seulement quel hôte est déclaré ; la connexion vous dit s’il accepte vraiment le courrier.
Quand un MX valide perd quand même du courrier
Les quatre configurations ci-dessous renvoient des enregistrements MX et passent les vérificateurs qui se contentent de les lister — tout en vous coûtant la délivrabilité, la réputation d’expéditeur, ou les deux.
Le PTR qui désigne un pool d’adresses FAI
Le DNS direct indique mail.caldmont.com ; le DNS inversé indique cust-45.pool.example.net. Les grands fournisseurs pénalisent cet écart à chaque connexion émise par cette machine — greylisting d’abord, dossier indésirable ensuite.
FCrDNS : échecLe MX de secours que personne ne corrige
La priorité 20 pointe vers une machine mise à jour pour la dernière fois il y a des années — filtrage plus faible, TLS obsolète. Les spammeurs visent le MX de secours exprès, car c’est la porte que personne ne surveille.
MX de secours · filtrage réduitUne adresse IP à la place d’un nom d’hôte
Une panne, une modification faite dans l’urgence, et voilà MX 20 203.0.113.45 installé dans votre zone. Un enregistrement MX doit pointer vers un nom d’hôte — les serveurs conformes ignorent cette entrée, ce qui veut dire que le MX de secours que vous croyez avoir n’existe pas.
RFC 5321 — pas un nom d’hôtePort 25, sans STARTTLS
Le serveur répond, le chiffrement n’est jamais proposé, et chaque message traverse Internet en clair. Les serveurs qui exigent TLS diffèrent ou rejettent le message — et les clients de messagerie le signalent à vos destinataires.
aucun TLS proposé sur le port 25MX nul, IP littérales et PTR cassés
Certaines de ces réponses semblent cassées alors qu’elles sont correctes — un MX nul et des priorités égales remplissent chacun un rôle précis. D’autres se résolvent proprement et perdent quand même du courrier.
Un ensemble typique de fournisseur : une première porte, une paire répartie en round-robin, des MX de secours derrière. Des priorités égales relèvent du round-robin voulu — une fonctionnalité, pas une anomalie. Voilà à quoi ressemble une configuration saine.
MX nul (RFC 7505) : « ce domaine n’accepte aucun e-mail, rejetez immédiatement ». L’enregistrement volontaire et correct pour les domaines web uniquement ou parqués : les expéditeurs reçoivent une réponse immédiate au lieu de réessayer pendant des jours.
Les serveurs recourent alors à la règle du MX implicite (RFC 5321) : ils livrent le courrier à votre enregistrement A/AAAA, c’est-à-dire au serveur web. Cela fonctionne jusqu’au jour où vous déplacez le site.
Une IP littérale là où un nom d’hôte est attendu. Certains serveurs tentent quand même l’adresse en silence ; les serveurs conformes considèrent l’enregistrement comme inutilisable. Votre délivrabilité dépend désormais de qui vous envoie du courrier.
Échec FCrDNS : l’enregistrement inversé désigne un pool d’adresses FAI, ou rien du tout. Les serveurs y lisent « pas un vrai serveur de messagerie » — et c’est pourtant cette machine qui envoie chacun de vos rejets et réponses automatiques.
Le port 25 répond mais le chiffrement n’est jamais proposé. Tout transite en clair, et les serveurs qui exigent TLS diffèrent ou rejettent le message. Une seule ligne de configuration suffit à corriger cela.
Le contrôle de réputation caché dans le DNS inversé
Le FCrDNS (forward-confirmed reverse DNS) est un aller-retour : on prend l’IP du serveur de messagerie, on consulte son PTR, on résout ce nom en DNS direct — et on doit retomber sur la même IP. Un seul maillon cassé et l’aller-retour échoue. Les serveurs le vérifient en permanence :
- Le trajet : IP → PTR → nom d’hôte → A/AAAA → même IP. Nous le parcourons pour chaque hôte MX, dans les deux sens.
- Les consignes de Google pour les expéditeurs exigent un PTR correspondant pour atteindre Gmail ; Microsoft en tient compte dans son filtrage des connexions.
- « Mais le MX, c’est pour recevoir » — votre machine MX n’est jamais purement entrante. Les rejets, les réponses d’absence et les transferts en partent aussi. Sa réputation, c’est la vôtre.
- Les fournisseurs managés maintiennent cela impeccable pour vous. En auto-hébergement, le PTR est votre responsabilité — un simple ticket auprès de votre FAI ou hébergeur.
Empreintes de fournisseurs
ce que révèle le motif MXCe que vous pouvez vérifier vous-même
Les enregistrements sont à portée de dig. La conversation, elle, ne l’est pas — les FAI grand public bloquent le port 25 sortant, donc il faut frapper depuis un réseau à qui les serveurs de messagerie acceptent de parler.
Questions fréquentes sur la recherche MX
Saisissez votre domaine ci-dessus. Nous interrogeons ses enregistrements MX, les trions par priorité, résolvons chaque nom d’hôte en IPv4 et IPv6, exécutons l’aller-retour FCrDNS sur chaque adresse, identifions le fournisseur de messagerie à partir du motif observé, puis nous connectons à chaque serveur sur le port 25 depuis notre réseau de sondes — en lisant la bannière SMTP et en testant STARTTLS. Gratuit, sans inscription, quelques secondes de bout en bout.
Plus le chiffre est bas, plus l’hôte est essayé en premier. Les expéditeurs ne remontent la liste que si les hôtes de meilleure priorité ne répondent pas. Des priorités égales ne sont pas une erreur — c’est de la répartition de charge en round-robin, et les grands fournisseurs y ont recours (le jeu classique de Google compte deux hôtes en priorité 5 et deux en priorité 10). Le problème des configurations à plusieurs paliers n’est pas dans les chiffres — c’est que le palier de secours tourne sur des logiciels plus anciens avec un filtrage plus laxiste, exactement ce qui attire les spammeurs.
Le DNS inversé à confirmation directe (FCrDNS) : l’IP de votre serveur de messagerie doit posséder un enregistrement PTR, et le nom que renvoie ce PTR doit se résoudre à nouveau vers la même IP. C’est une preuve peu coûteuse que celui qui contrôle l’IP contrôle aussi le nom — les canons à spam sur des plages détournées y parviennent rarement. Les consignes de Google pour les expéditeurs exigent un PTR valide et correspondant pour délivrer sur Gmail, et la plupart des filtres le notent. Et avant de classer cela dans « ça ne concerne que le sortant » : votre hôte MX envoie aussi du courrier — chaque rejet, chaque réponse d’absence, chaque transfert. Un aller-retour cassé sur la machine entrante pénalise discrètement tout cela.
Un unique MX de préférence 0 avec la racine comme hôte — 0 . — défini par la RFC 7505. C’est la façon standard de déclarer « ce domaine n’accepte pas de courrier ». Les expéditeurs le voient et renvoient un rejet définitif en quelques secondes, au lieu de retomber sur la règle du MX implicite et de marteler votre serveur web de tentatives pendant des jours. C’est l’enregistrement à utiliser pour les domaines parqués ou web uniquement — associé à v=spf1 -all et une politique DMARC reject, pour qu’aucun message ne puisse non plus être envoyé en usurpant le domaine.
Étonnamment, oui. La règle du MX implicite (RFC 5321) dit qu’en l’absence de MX, les expéditeurs traitent l’enregistrement A/AAAA du domaine comme un MX de préférence 0 — le courrier est alors livré à ce qui répond sur l’IP de votre serveur web. Si cette machine fait tourner un MTA, le courrier passe ; certains font tourner leur messagerie de production sur cet accident pendant des années. C’est fragile — déplacez le site, et le courrier disparaît — et c’est rarement voulu. Publiez de vrais enregistrements MX si vous recevez du courrier, ou 0 . sinon.
Non — et c’est une confusion fréquente. Le MX répond à « où va le courrier à destination de ce domaine » ; votre réputation à l’envoi dépend de l’IP d’envoi, de SPF, DKIM et DMARC, que nos outils dédiés notent un par un. Deux exceptions : si vous êtes auto-hébergé, la machine MX est aussi la machine d’envoi, donc son FCrDNS et son hygiène TLS comptent double ; et certains serveurs vérifient qu’un domaine qui envoie du courrier peut aussi en recevoir — un jeu de MX cassé échoue discrètement ce contrôle.
La sonde ouvre une connexion TCP vers chaque hôte MX sur le port 25, lit la bannière d’accueil, envoie EHLO, et vérifie si STARTTLS est proposé — puis le négocie et relève la version TLS et le certificat. Elle n’envoie aucun courrier : la conversation s’arrête avant MAIL FROM. Vous ne pouvez pas faire cela depuis une connexion résidentielle, car les FAI grand public bloquent le port 25 sortant pour lutter contre le spam par botnet. Une réserve à connaître : STARTTLS sur le port 25 est opportuniste — un attaquant positionné sur le chemin réseau peut supprimer cette offre. MTA-STS est le verrou qui règle ce problème ; notre vérificateur de versions TLS parcourt chaque version de protocole que votre serveur acceptera.
Continuer l'exploration
Les outils gratuits, c'est un début.
Uptimia veille sur la santé de vos sites.
Disponibilité, SSL, expiration de domaine, vitesse de page, transactions — surveillés depuis 171+ emplacements dans le monde. 30 jours gratuits.