Découvrez où le courrier d'un domaine est réellement livré

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 ou Windows 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 brute, d'où un comportement identique dans la version Mac App Store — contrairement au traceroute, que le bac à sable bloque réellement. 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. C'est exactement pourquoi l'écran DNS Lookup d'iOS n'affiche que des A et des AAAA. Pour lire les MX, 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.