Consulta MX: adónde se entrega de verdad el correo de un dominio

Un registro MX es uno de los registros de recurso más simples del DNS y uno de los de mayor consecuencia. Tipo 15, clase IN, y una sección RDATA con exactamente dos partes: una preferencia de 16 bits en orden de red, seguida de un nombre de dominio para el servidor de intercambio. Ese nombre está sujeto a la compresión de nombres del DNS, así que con frecuencia se guarda como un puntero a una parte anterior del mensaje en lugar de como una cadena literal, razón por la cual no puedes leer una respuesta MX tratando el paquete como texto. El RFC 5321, sección 5.1, define qué hace un MTA emisor con ese conjunto. Consulta el MX del dominio destinatario, ordena los resultados por preferencia ascendente, resuelve cada servidor de intercambio a registros de dirección e intenta la entrega en ese orden, eligiendo al azar entre los registros que comparten valor de preferencia. Si la consulta MX no devuelve nada, el emisor recurre a los registros de dirección del propio dominio: la regla del MX implícito. Si devuelve un único registro con preferencia 0 y un punto suelto como servidor, el RFC 7505 dice que el dominio no acepta correo y que el emisor debe rechazarlo de inmediato en vez de reintentar durante cinco días. El servidor de intercambio tiene que ser un nombre de host con registros de dirección; no puede ser un CNAME ni una dirección literal. Conseguir esa respuesta en macOS es sencillo. SSHive usa el resolutor de Node basado en c-ares, que habla DNS directamente con los servidores que tiene configurados tu sistema operativo en lugar de pasar por getaddrinfo. resolveMx devuelve el conjunto, ordenado de forma ascendente. Cada servidor de intercambio pasa luego por resolve4, cada dirección resultante por una consulta PTR, y la primera dirección de cada servidor por el motor DNSBL, que despliega las ocho zonas en paralelo. Cada paso de enriquecimiento tiene su propio control de errores, así que un servidor sin registro PTR o sin registro A degrada a una raya en vez de hacer fallar toda la consulta. Nada de esto necesita un socket raw, y por eso MX Lookup se comporta igual en la versión del Mac App Store. iOS es el problema difícil. La red de alto nivel de Apple te da resolución de nombre a dirección y nada más: getaddrinfo y NWEndpoint devuelven registros A y AAAA, y no hay ninguna API pública de Swift para un tipo de registro arbitrario. Para leer MX (y, dado que el mismo auxiliar se generalizó, todos los demás tipos de registro que ahora muestra la pantalla DNS Lookup), SSHive baja hasta el resolutor BSD de libresolv mediante un pequeño auxiliar en C: res_init, luego res_query con clase C_IN y tipo T_MX para la respuesta en bruto, después ns_initparse y ns_parserr sobre la sección de respuesta, leyendo la preferencia en big-endian de los dos primeros bytes del RDATA y expandiendo el nombre comprimido del servidor con dn_expand. Swift ordena el resultado por preferencia y se lo entrega a la vista. Ninguna biblioteca resolutora de terceros, ninguna API web por el camino: la consulta va de tu dispositivo a los resolutores que ya está usando. Los costes son honestos. La consulta usa la configuración del resolutor del sistema: un portal cautivo o una red DNS64/NAT64 que maneje mal el tipo 15 hace fallar res_query, y la app informa de que no hay registros MX en lugar de dar un error de red. El analizador se detiene en 32 registros. Y en todas las plataformas no hay campo de servidor de nombres personalizado, ni visualización de TTL, ni inspección de SPF, DKIM, DMARC, MTA-STS o TLS-RPT.