Solucionar problemas

Diagnóstico avanzado de los registros de un dominio

Revisado el 6 min de lectura diagnostico dns

MXToolbox reúne consultas DNS y pruebas externas de correo y red. Resulta útil para observar qué respuesta obtiene un tercero, pero esa respuesta puede proceder de un resolutor con caché y no sustituye la consulta directa a los servidores DNS autoritativos.

Antes de comprobar un registro:

  1. Identifica qué servidores DNS están delegados para el dominio.
  2. Confirma que estás editando la zona servida por esos servidores. Si el dominio utiliza Cloudflare u otro proveedor DNS, modificar únicamente Zone Editor de cPanel no cambia el DNS público.
  3. Consulta el registro en cada servidor autoritativo.
  4. Cuando los autoritativos sean coherentes, utiliza MXToolbox u otros resolutores externos para comprobar qué respuesta ven desde fuera.

Por ejemplo, cambiar el correo a Google Workspace requiere sustituir los MX en la zona DNS autoritativa, no necesariamente en cPanel. Después de copiar los valores facilitados por Google, puedes realizar una observación externa introduciendo:

mx:dominio.com

mx indica el tipo de comprobación y dominio.com es el nombre que se consultará. Compara el resultado con los valores y prioridades proporcionados por el proveedor de correo.

Si dispones de dig, puedes consultar primero la delegación y los servidores autoritativos:

dig dominio.com NS +trace
dig +nssearch dominio.com
dig @ns1.proveedor.com dominio.com MX +norecurse
dig @ns2.proveedor.com dominio.com MX +norecurse

Sustituye los servidores, el dominio y el tipo MX por los que correspondan. Si los servidores autoritativos ofrecen valores o números de serie SOA diferentes, corrige primero esa incoherencia; no es una caché del usuario.

Si no dispones de dig, el diagnóstico DNS de IPeek, una herramienta externa gratuita, muestra la delegación publicada por la zona padre, si cada servidor autoritativo responde con autoridad y si coinciden sus números de serie SOA. Para comparar el valor de un registro concreto en cada servidor sigue siendo necesaria la consulta directa.

Para un registro TXT, utiliza txt:dominio.com y compara el nombre y el valor completo con los solicitados:

Entre las comprobaciones disponibles se encuentran:

a: Consulta la dirección IPv4 publicada en el registro A
aaaa: Consulta la dirección IPv6 publicada en el registro AAAA
mx: Consulta los servidores de correo y sus prioridades
txt: Consulta los registros TXT publicados bajo el nombre indicado
spf: Comprueba la política SPF publicada mediante un registro TXT
dkim: Comprueba el registro DKIM del selector indicado
dmarc: Comprueba la política DMARC publicada bajo _dmarc
cname: Muestra el nombre canónico al que apunta un alias
ptr: Realiza la consulta DNS inversa de una dirección IP
soa: Obtiene el registro de inicio de autoridad de la zona
dns: Comprueba la delegación y otros problemas detectados por MXToolbox
smtp: Prueba la respuesta SMTP del servidor en el puerto 25
http: Comprueba la respuesta HTTP de una URL
https: Comprueba la respuesta HTTPS de una URL
tcp: Prueba una conexión TCP hacia el host y puerto indicados
ping: Realiza una prueba ICMP desde la infraestructura de MXToolbox
trace: Realiza una traza ICMP desde la infraestructura de MXToolbox
blacklist: Consulta las listas de bloqueo integradas por MXToolbox
asn: Busca el sistema autónomo relacionado con una dirección IP
arin: Busca información registral sobre un bloque de direcciones IP
whois: Muestra la consulta registral ofrecida por MXToolbox

SPF se publica actualmente en registros TXT; no debe crearse un registro DNS de tipo SPF. blacklist solo informa de las listas que consulta MXToolbox y no establece una reputación universal.

Para dominios genéricos como .com, .net u .org, utiliza ICANN Lookup, basado en RDAP, como fuente actual de datos registrales. Desde el 28 de enero de 2025, RDAP sustituyó a WHOIS como fuente definitiva para los gTLD. Los dominios territoriales, como .es, pueden utilizar el servicio registral establecido por su propio registro.

Cada prueba confirma únicamente la observación que muestra. Un MX correcto no demuestra que exista el buzón, una consulta SMTP desde MXToolbox no reproduce la conexión del usuario y la ausencia de respuesta a ping no demuestra que el servicio esté caído. Para atribuir una causa, relaciona el resultado DNS con la prueba del servicio y con su respuesta o registro exactos.

Consulta el nombre exacto

Un TXT de verificación en la raíz, un TXT en _dmarc.dominio.com y el DKIM de selector._domainkey.dominio.com son consultas distintas. Para DKIM necesitas el selector utilizado por el emisor; una búsqueda en la raíz no demuestra que falte la firma.

Si aparece SERVFAIL, compara la respuesta autoritativa y la validación DNSSEC antes de volver a cambiar registros. Desactivar la validación en un equipo no repara una cadena DNSSEC incorrecta para el resto de usuarios. Guarda la salida completa, incluido el estado y el servidor consultado; el número de serie SOA por sí solo tampoco demuestra que todos los registros sean idénticos.

También te puede ayudar

¿Algo no cuadra o ha cambiado? Cuéntanoslo y lo revisamos.