Aller au contenu principal
Obtenir

Recherche MX : où le courrier d'un domaine est vraiment livré

Tous les enregistrements MX d'un domaine, triés comme les lit un serveur expéditeur, avec IP, DNS inverse et réputation DNSBL sur Mac.

Par Lucas Russo, développeur de SSHive · Mis à jour le

Télécharger SSHive gratuitementTous les outils réseau
Aussi sur iPhone et iPad
Le courrier n'arrive plus, ou il arrive sur le mauvais serveur. La première chose à établir n'est ni l'état du pare-feu ni le quota de la boîte : c'est l'endroit où Internet croit aujourd'hui devoir livrer votre courrier. Cette réponse tient dans un seul endroit, les enregistrements MX du domaine. Tout serveur expéditeur les interroge avant d'ouvrir la moindre connexion SMTP, et s'ils disent autre chose que ce que vous attendiez, rien de ce qui vient ensuite n'a d'importance. C'est aussi l'étape que l'on saute après une migration. Vous basculez un domaine vers un nouveau prestataire, le panneau d'administration affiche la bonne configuration, et le courrier continue d'atterrir dans l'ancienne boîte pendant une journée entière parce que les enregistrements n'ont jamais été modifiés, ou qu'une copie périmée circule encore. Une recherche de trente secondes l'aurait montré. SSHive effectue cette recherche lui-même, sur Mac, iPhone et iPad. La requête part vers les résolveurs DNS que votre appareil utilise déjà : aucune API web intermédiaire, aucun compte, aucune publicité. Sur Mac, l'outil ne s'arrête pas à la liste des enregistrements : chaque serveur est résolu en adresses IPv4, chaque adresse est résolue en sens inverse pour obtenir son nom PTR, et la première adresse de chaque serveur est testée sur huit zones DNSBL. Vous obtenez toute la façade mail du domaine dans un seul tableau : qui reçoit, dans quel ordre, sur quels hôtes, et si ces hôtes traînent un problème de réputation. Sur iPhone et iPad, vous obtenez la liste elle-même, priorité et nom du serveur, grâce à une véritable requête DNS de type 15 adressée au résolveur du système, ce que les API standard d'iOS ne savent pas faire. C'est gratuit sur Mac, iPhone et iPad, version Mac App Store comprise : aucun outil réseau de SSHive n'est réservé à Pro. Une limite énoncée clairement : c'est un outil MX et réputation, pas un audit d'authentification du courrier. SSHive n'inspecte ni SPF, ni DKIM, ni DMARC, ni MTA-STS, ni TLS-RPT, ne capture aucune bannière SMTP et ne teste le port 25 sur aucune plateforme.

Ce que fait SSHive

Les priorités, dans l'ordre où SMTP les lit

SSHive interroge les enregistrements MX du domaine et les trie par préférence croissante, exactement l'ordre dans lequel un MTA expéditeur les parcourt. Le plus petit numéro est essayé en premier. Sur macOS le résultat est un tableau à cinq colonnes ; sur iPhone et iPad chaque ligne porte une capsule de priorité colorée : verte jusqu'à 10, orange jusqu'à 20, rouge au-delà.

Chaque serveur résolu en adresses

Sur macOS, chaque nom de serveur MX est résolu en adresses IPv4, affichées séparées par des virgules dans la colonne IP. Un tiret cadratin signifie qu'aucun enregistrement A n'est revenu : soit l'hôte est en IPv6 uniquement, puisque SSHive résout ici en IPv4, soit le MX pointe vers un nom qui n'existe plus. Les deux méritent une vérification.

DNS inverse pour chaque IP de serveur mail

La colonne rDNS affiche le nom PTR de chaque adresse résolue. Elle révèle qui exploite réellement l'hôte derrière un nom MX de façade, et met en évidence les PTR génériques d'hébergeur que les serveurs destinataires pénalisent souvent sur le courrier sortant. La résolution inverse n'a pas de carte dédiée dans le panneau desktop : c'est ici qu'elle apparaît.

Réputation DNSBL intégrée, huit zones

Sur macOS, la première IPv4 de chaque serveur est testée en parallèle contre zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net, dnsbl.sorbs.net, bl.mailspike.net, dnsbl-1.uceprotect.net, psbl.surriel.com et all.s5h.net. La colonne affiche une pastille verte Non listé, ou une pastille rouge dont l'infobulle nomme les zones exactes ayant signalé l'adresse.

De vraies requêtes MX sur iPhone et iPad

iOS n'expose que la résolution nom vers adresse : getaddrinfo ne peut jamais renvoyer un enregistrement MX. SSHive émet une véritable requête de type 15 via le résolveur BSD, analyse lui-même la section réponse et lit la préférence 16 bits directement sur le fil. Vous obtenez priorité et nom de serveur, jusqu'à 32 enregistrements, avec un bouton de copie sur chaque ligne.

Gratuit sur toutes les plateformes, sans publicité

La recherche MX n'est pas une fonction Pro. Aucun outil réseau de SSHive n'est verrouillé, sur aucune plateforme : pas d'invitation à passer au payant dans le panneau, pas d'écran publicitaire avant une requête, pas de compte à créer. Pro, un paiement unique en achat universel pour Mac, iPhone et iPad, sert à dépasser 2 sessions SSH simultanées ou 5 profils enregistrés, à ouvrir des tunnels distants et à utiliser RDP et VNC.

Comment faire, étape par étape

  1. 1

    Ouvrez le panneau d'outils réseau sur le Mac

    Dans l'app Mac, cliquez sur l'icône réseau de la barre latérale, ou sur la pastille Outils réseau de l'écran d'accueil. L'un comme l'autre ouvre un onglet Outils réseau. Aucune session SSH ni aucune connexion préalable n'est nécessaire.

  2. 2

    Saisissez le domaine dans la carte Recherche MX

    Sur Mac, Recherche MX est la troisième carte de la section Résolution et réputation, après Recherche DNS et Vérification DNSBL. Saisissez le domaine racine, pas un nom d'hôte (exemple.com, et non mail.exemple.com), puis cliquez sur Rechercher les MX. Le texte d'exemple du champ indique le format attendu.

  3. 3

    Lisez les cinq colonnes

    Les résultats arrivent sous la forme Priorité, Serveur MX, IP, rDNS et DNSBL, triés par priorité croissante. Survolez une pastille rouge pour voir précisément quelles zones ont signalé l'adresse ; une pastille verte signifie qu'aucune des huit zones n'a répondu par un code 127.x.

  4. 4

    Sur iPhone ou iPad, allez dans Outils puis Email & IP

    Touchez Outils dans la barre d'onglets sur iPhone, ou Outils réseau dans la barre latérale sur iPad, puis MX Lookup, première ligne de la section Email & IP. Saisissez le domaine et lancez la requête. Chaque ligne affiche une capsule de priorité colorée et le nom du serveur en police à chasse fixe.

  5. 5

    Enchaînez sur Blacklist Check en mobilité

    Pour le détail zone par zone sur iPhone ou iPad, touchez le bouton de copie d'une ligne, ouvrez Blacklist Check dans la même section Email & IP et collez le nom d'hôte : l'outil le résout lui-même vers sa première adresse IPv4, puis interroge dix zones DNSBL.

Lire correctement un tableau MX

Le numéro de priorité est une préférence, pas une note de qualité, et sa valeur absolue ne signifie rien. 5/10/20 et 1/2/3 décrivent exactement le même routage. Seul l'ordre compte : un MTA expéditeur trie par ordre croissant et essaie le plus petit d'abord, ne passant au suivant que si la connexion échoue. Deux enregistrements portant le même numéro sont départagés au hasard : c'est ainsi que fonctionne la répartition de charge au niveau MX. Le serveur au numéro le plus élevé mérite donc l'examen le plus attentif. Un MX de secours est un point faible classique : souvent plus ancien, moins filtré et moins surveillé que le principal, il est ciblé délibérément par les expéditeurs de spam pour cette raison précise. Si votre tableau montre un secours hébergé ailleurs que le principal, vérifiez qu'il a encore une raison d'exister. Un résultat vide n'est pas forcément une panne. Deux cas légitimes existent. Une priorité 0 avec un simple point comme serveur est un null MX (RFC 7505) : le domaine déclare ne recevoir aucun courrier, ce qui est correct pour un domaine purement web. Et un domaine sans aucun enregistrement MX n'est pas injoignable : SMTP retombe sur l'enregistrement A ou AAAA du domaine lui-même, la règle du MX implicite de la RFC 5321. Le courrier partira vers votre serveur web, ce qui est rarement l'intention, mais ce n'est pas du silence. Un tiret cadratin dans la colonne IP signifie que le serveur n'a renvoyé aucun enregistrement A. SSHive résout ici en IPv4 : un serveur de messagerie en IPv6 uniquement apparaît donc vide. Lancez DNS Lookup sur ce nom d'hôte et cherchez un AAAA avant de conclure à une panne. Le même contrôle attrape l'autre erreur classique : un MX qui pointe vers un CNAME, ce que les RFC 2181 et 5321 interdisent et que certains MTA rejettent purement et simplement. Enfin, une inscription DNSBL sur un MX entrant ne vous empêche pas de recevoir. Son intérêt est qu'en petite infrastructure le même hôte émet aussi, et qu'une inscription sur zen.spamhaus.org, consultée par une très large part des destinataires, pèse bien plus lourd qu'une inscription sur dnsbl-1.uceprotect.net, qui liste des blocs entiers de manière agressive et qu'un nombre nettement plus faible de serveurs interroge. Lisez la zone, pas le compteur.

Questions fréquentes

Que signifie réellement le numéro de priorité MX ?+
C'est une valeur de préférence, et seul l'ordre compte. Un serveur expéditeur trie les enregistrements par ordre croissant et essaie le plus petit numéro d'abord, ne passant au suivant que si la connexion échoue. 5/10/20 et 1/2/3 décrivent un routage identique. Les enregistrements partageant le même numéro sont choisis au hasard : c'est la répartition de charge au niveau MX. Ce numéro n'est ni une note ni une unité.
Mon domaine ne renvoie aucun enregistrement MX. Le courrier est-il cassé ?+
Pas forcément. Sans aucun enregistrement MX, SMTP retombe sur l'enregistrement A ou AAAA du domaine lui-même, la règle du MX implicite de la RFC 5321. Le courrier est tenté vers votre serveur web, ce qui est généralement une erreur de configuration mais pas un silence. L'autre cas légitime est le null MX : un enregistrement unique de priorité 0 avec un simple point comme serveur, qui déclare selon la RFC 7505 que le domaine ne reçoit aucun courrier et fait rejeter immédiatement les expéditeurs.
Le Lookup MX fonctionne-t-il sur iPhone et iPad ?+
Oui, sur les deux, et gratuitement. La version mobile est toutefois plus étroite que celle du Mac : elle renvoie la priorité et le nom du serveur, sans colonne IP ni DNS inverse, qui n'existent que sur Mac. L'analyseur mobile s'arrête par ailleurs à 32 enregistrements. Pour la réputation zone par zone d'un résultat mobile, copiez le nom d'hôte dans l'outil Blacklist Check.
Le Lookup MX est-il disponible dans la version Mac App Store ?+
Oui, avec toutes ses colonnes et toutes ses zones DNSBL. Le Lookup MX n'est que du DNS classique via le résolveur système : il n'exige aucun socket brut et le bac à sable ne le restreint pas. Rien n'est restreint dans le panneau d'outils : le ping et le traceroute émettent du vrai ICMP depuis la version App Store également, via un socket datagramme qui n'exige aucun privilège.
SSHive vérifie-t-il SPF, DKIM ou DMARC ?+
Non. Aucune inspection SPF, DKIM, DMARC, MTA-STS ou TLS-RPT sur aucune plateforme, aucune capture de bannière SMTP, aucun test du port 25. Ce que vous pouvez faire, c'est lire les enregistrements bruts : SPF est publié en TXT à la racine du domaine, et la carte Recherche DNS du Mac renvoie les TXT à côté des A, AAAA, MX, CNAME et NS. SSHive affiche la chaîne ; il ne l'analyse ni ne la valide. Les politiques DMARC résident sous le nom distinct _dmarc.
Pourquoi la colonne IP est-elle vide pour l'un de mes serveurs ?+
La recherche MX du Mac ne résout les serveurs qu'en IPv4 : un serveur de messagerie en IPv6 uniquement n'a rien à afficher et montre un tiret cadratin dans les colonnes IP et rDNS, et n'est jamais testé en DNSBL, le moteur étant lui aussi IPv4 uniquement. L'autre explication est pire : le MX pointe vers un nom d'hôte sans aucun enregistrement d'adresse. Lancez DNS Lookup sur ce nom pour trancher. Si un AAAA revient, c'est le premier cas.
Puis-je faire confiance à un résultat « Non listé » ?+
Globalement oui, avec une réserve à connaître. Plusieurs opérateurs de DNSBL, Spamhaus en particulier, refusent les requêtes venant des grands résolveurs publics et répondent par une erreur ou par un code générique. Le Mac considère comme listée toute réponse commençant par 127., et comme non listé tout le reste, erreur DNS comprise : sur un résolveur public, les deux sens peuvent donc tromper. Spamhaus refuse ces requêtes avec un code 127.255.255.x, qui s'affiche en « Blacklisté » alors que rien n'est listé, tandis qu'une zone qui répond par une erreur franche apparaît propre même si elle vous liste. L'iPhone et l'iPad mettent ces deux cas à part, comme indéterminés, au lieu de les compter dans un sens ou dans l'autre. Quand le résultat compte, confirmez-le via le résolveur de votre opérateur ou un vérificateur web dédié avant d'agir.

Le MX sur le fil, et ce qu'il faut pour l'interroger depuis un iPhone

L'enregistrement MX est l'un des plus simples du DNS et l'un des plus lourds de conséquences. Type 15, classe IN, et une section RDATA en exactement deux parties : une préférence sur 16 bits en ordre réseau, suivie d'un nom de domaine pour le serveur. Ce nom est soumis à la compression de noms DNS : il est fréquemment stocké sous forme de pointeur vers une portion antérieure du message plutôt qu'en clair, raison pour laquelle on ne peut pas lire une réponse MX en traitant le paquet comme du texte. La section 5.1 de la RFC 5321 définit ce qu'un MTA expéditeur fait de cet ensemble. Il interroge le MX du domaine destinataire, trie par préférence croissante, résout chaque serveur en enregistrements d'adresse et tente la livraison dans cet ordre, en tirant au sort entre les enregistrements de préférence égale. Si la requête MX ne renvoie rien, l'expéditeur retombe sur les adresses du domaine lui-même : la règle du MX implicite. Si elle renvoie un unique enregistrement de préférence 0 avec un simple point comme serveur, la RFC 7505 impose de rejeter immédiatement au lieu de réessayer pendant cinq jours. Le serveur doit être un nom d'hôte doté d'enregistrements d'adresse ; ni un CNAME, ni une adresse littérale. Obtenir cette réponse sur macOS est direct. SSHive s'appuie sur le résolveur de Node basé sur c-ares, qui parle DNS directement aux serveurs configurés par le système au lieu de passer par getaddrinfo. resolveMx renvoie l'ensemble, trié par ordre croissant. Chaque serveur passe ensuite par resolve4, chaque adresse obtenue par une requête PTR, et la première adresse de chaque serveur par le moteur DNSBL, qui déploie les huit zones en parallèle. Chaque étape d'enrichissement est protégée indépendamment : un serveur sans PTR ou sans enregistrement A dégrade en tiret cadratin au lieu de faire échouer toute la requête. Rien de tout cela n'exige de socket brut, d'où un comportement identique dans la version Mac App Store. iOS est le vrai problème. Le réseau de haut niveau d'Apple ne donne que la résolution nom vers adresse : getaddrinfo et NWEndpoint renvoient des A et des AAAA, et aucune API Swift publique ne permet d'interroger un type d'enregistrement arbitraire. Pour lire les MX (et, le même assistant ayant été généralisé, tous les autres types que l'écran DNS Lookup affiche désormais), SSHive descend jusqu'au résolveur BSD de libresolv via un petit assistant en C : res_init, puis res_query en classe C_IN et type T_MX pour la réponse brute, puis ns_initparse et ns_parserr sur la section réponse, la préférence étant lue en big-endian sur les deux premiers octets du RDATA et le nom compressé étendu par dn_expand. Swift trie le résultat par préférence et le transmet à la vue. Aucune bibliothèque de résolution tierce, aucune API web intermédiaire : la requête part de votre appareil vers les résolveurs qu'il utilise déjà. Les contreparties sont assumées. La requête suit la configuration du résolveur système : un portail captif ou un réseau DNS64/NAT64 qui traite mal le type 15 fait échouer res_query, et l'application signale alors une absence d'enregistrements MX plutôt qu'une erreur réseau. L'analyseur s'arrête à 32 enregistrements. Et sur toutes les plateformes, il n'y a ni champ de serveur DNS personnalisé, ni affichage des TTL, ni inspection SPF, DKIM, DMARC, MTA-STS ou TLS-RPT.

Outils liés

Vérification DNSBL

Recherche DNS

Whois

Ping

Traceroute