DNS Lookup: cómo comprobar registros TXT, registros MX y otros registros DNS
Revisar registros TXT y revisar registros MX son las tareas de DNS más comunes: TXT contiene los registros SPF, DKIM, DMARC y de verificación de dominio, mientras que MX le indica al mundo dónde entregar tu correo. La forma más rápida de consultar los registros DNS de un dominio en línea es usar una consulta DNS: la herramienta gratuita, sin registro, muestra los registros A, AAAA, CNAME, MX, NS, TXT, SOA y SRV junto con sus valores y TTL. La consulta MX profundiza en los servidores de correo y sus prioridades, y desde la línea de comandos nslookup -type=txt example.com y nslookup -type=mx example.com muestran lo mismo. A continuación: cómo leer los resultados y qué hacer cuando tus registros "no se actualizan".
Cómo revisar registros DNS en línea
- Abre la consulta DNS e ingresa el dominio:
example.com. No necesitas quitar el protocolo ni la ruta: la herramienta extrae el nombre de host de la URL por sí sola. - Para un subdominio, ingrésalo completo:
www.example.com,shop.example.com. Cada nombre tiene sus propios registros, y un CNAME normalmente está en el subdominio. - Compara los resultados con lo que te dio tu proveedor de hosting o de correo: la IP del registro A, los nombres de host en MX, las cadenas en TXT.
- Revisa la columna TTL: te indica en cuántos segundos se actualizarán las cachés si acabas de cambiar algo.
La herramienta consulta los registros a través del resolver de nuestro servidor, así que muestra lo que ve un punto de la red en este momento. Para comprobar si los cambios se han propagado, compara esa respuesta con la de resolvers públicos usando los comandos de la siguiente sección.
Los nombres con guion bajo, como _dmarc.example.com, no se ingresan en la consulta general: los registros de correo tienen herramientas dedicadas: la consulta MX muestra los servidores de correo con prioridades e IP, el verificador SPF desglosa los mecanismos y las cadenas de include, y el verificador DMARC muestra la política y las direcciones de reportes.
Cómo revisar DNS con nslookup y dig
nslookup está disponible en Windows, macOS y Linux; dig viene incluido en macOS y en la mayoría de las distribuciones de Linux. El último parámetro de nslookup, o el argumento @ en dig, define a qué servidor DNS se consulta.
nslookup -type=A example.com
nslookup -type=MX example.com
nslookup -type=TXT example.com 8.8.8.8
nslookup -type=CNAME www.example.comdig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com NS +short
dig example.com TXT +short
dig _dmarc.example.com TXT +short
dig selector1._domainkey.example.com TXT +short
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com AEn PowerShell, Resolve-DnsName example.com -Type MX hace lo mismo. Para ver qué hay realmente en la zona, sin cachés de por medio, consulta directamente al servidor autoritativo: primero dig example.com NS +short, luego dig @ns1.your-provider.net example.com A. dig +trace example.com recorre toda la cadena desde los servidores raíz y muestra en qué paso la respuesta difiere de lo que esperas.
Tipos de registros DNS y qué revisar
| Registro | Qué hace | Valor de ejemplo | Qué buscar |
|---|---|---|---|
| A / AAAA | La dirección IPv4 / IPv6 del sitio | 203.0.113.10 | Si coincide con tu servidor; si hay direcciones que no reconoces |
| CNAME | Un alias que apunta a otro nombre | shop.example.net. | Sin cadenas ni conflictos con otros registros |
| MX | Servidores de correo y su prioridad | 10 mx1.example.net. | Si existen y si son los correctos |
| TXT | Verificaciones y políticas de correo | v=spf1 ... ~all | Exactamente un registro SPF, DMARC presente |
| NS | Quién sirve la zona | ns1.example.net. | Si coinciden con el proveedor donde editas los registros |
| SOA | Parámetros de la zona | número de serie, temporizadores | Si el número de serie aumenta después de los cambios |
| SRV | Ubicación de servicios | _sip._tcp | Solo se necesita para servicios específicos |
Cómo revisar un registro CNAME
Un CNAME dice: "este nombre es un alias de otro nombre: pregunta allá." Se usa en subdominios que apuntan a un servicio externo: un creador de sitios web como Shopify, Wix o Squarespace, una CDN, una tienda alojada. Puedes comprobar el registro CNAME de un dominio en línea introduciendo el subdominio en la consulta DNS, o con dig www.example.com CNAME +short.
- Un CNAME no puede coexistir con otros registros en el mismo nombre. Por eso no puedes poner un CNAME normal en el dominio raíz (
example.com, que siempre tiene NS y SOA). Algunos proveedores de DNS ofrecen un sustituto (ALIAS, ANAME o CNAME flattening): desde fuera, un registro así parece un registro A normal. - Las cadenas CNAME → CNAME → CNAME funcionan, pero ralentizan la resolución y dificultan la depuración.
- Un CNAME que apunta a un nombre que ya no existe es una causa común de que un subdominio "no cargue" después de apagar un servicio externo.
- El punto final. Algunos paneles de control exigen que el valor termine con un punto; de lo contrario, se añade tu dominio al final y acabas con
shop.example.net.example.com.
Cómo comprobar el registro TXT de un dominio
- Averigua en qué nombre debe estar el registro. SPF y la verificación de Search Console van en el propio dominio (normalmente "@" en un panel DNS), DMARC en
_dmarc.example.com, DKIM enselector._domainkey.example.com. Los registros de verificación de otros servicios van donde el servicio te indique. - Consúltalo en línea. Para el propio dominio, usa la consulta DNS: la pestaña TXT muestra todos los registros TXT con su TTL. Los nombres con guion bajo no los acepta la consulta general, para ellos usa el verificador de SPF, el verificador de DKIM y el verificador de DMARC.
- O desde la línea de comandos:
El último comando consulta directamente al servidor autoritativo, así que ves el registro justo después de añadirlo, sin esperar a las cachés.nslookup -type=txt example.com nslookup -type=txt _dmarc.example.com 8.8.8.8 dig TXT example.com +short dig TXT _dmarc.example.com +short dig @ns1.your-provider.net TXT example.com +short - Compara el valor carácter por carácter con el que te dio el servicio: un espacio de más, una clave truncada o comillas dentro del valor harán fallar la validación.
| Registro TXT | Nombre | Empieza con |
|---|---|---|
| SPF | dominio | v=spf1 |
| DKIM | selector._domainkey.dominio | v=DKIM1 |
| DMARC | _dmarc.dominio | v=DMARC1 |
| Verificación de Google Search Console | dominio | google-site-verification= |
| Verificación de Microsoft 365 | dominio | MS=ms |
No elimines el registro de verificación de Google una vez verificada la propiedad: sin él, la verificación puede perderse.
Errores comunes en los registros TXT
- Dos registros
v=spf1. Según el estándar SPF, eso es un error y SPF deja de funcionar por completo. Combina los mecanismos del segundo servicio en el registro existente. Ten en cuenta que nuestro verificador de SPF analiza el primer registrov=spf1que encuentra, así que busca duplicados en la lista TXT de la consulta DNS o condig TXT example.com +short. - Comillas dentro del valor. La mayoría de los paneles esperan el valor sin comillas y las añaden por ti. Si lo pegas con comillas, a veces pasan a formar parte del texto, y dig entonces muestra
"\"v=spf1 ...\"". - Cadenas de más de 255 caracteres. Una sola cadena dentro de un registro TXT está limitada a 255 caracteres, por lo que un valor largo, normalmente una clave DKIM de 2048 bits, se guarda como varias cadenas entre comillas en un mismo registro:
"v=DKIM1; k=rsa; p=MIIB..." "...continued". El receptor las une sin espacios. Muchos paneles dividen el valor por ti; el error es crear dos registros TXT separados. - Nombre incorrecto. Se escribió el dominio completo en el campo "Nombre" y el panel lo volvió a añadir, generando
_dmarc.example.com.example.com.
Cómo funcionan los registros y cómo configurarlos: SPF, DKIM y DMARC explicados y qué son un registro DKIM y un selector.
Registros TXT: SPF, DKIM y DMARC
Si el correo de tu dominio llega a spam, revisa tres registros TXT:
example.com. TXT "v=spf1 include:_spf.google.com ~all"
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"- SPF: la lista de servidores autorizados para enviar correo en nombre del dominio. Solo debe existir un registro
v=spf1: si hay dos registros SPF, la verificación deja de ser válida. La evaluación de SPF está limitada a diez consultas DNS, y las cadenas largas de include la superan fácilmente. - DKIM: la clave pública de firma, publicada en
selector._domainkey.dominio. El selector lo define tu servicio de correo; sin él no podrás encontrar el registro. - DMARC: la política para los mensajes que no pasan SPF ni DKIM:
none(solo informes),quarantine(enviar a spam),reject(rechazar).
Los registros TXT también contienen verificaciones de propiedad: por ejemplo, una propiedad de tipo Dominio en Search Console se verifica con un registro TXT. Consulta el artículo sobre cómo conectar una propiedad.
Cómo comprobar los registros MX
Un registro MX indica a los remitentes qué servidor acepta el correo del dominio. Tiene dos campos: una prioridad y el nombre de un servidor. Cuanto menor es el número, mayor es la prioridad: los remitentes prueban primero el servidor con 10 y recurren al de 20 si no está disponible. Varios registros MX con la misma prioridad se reparten la carga: los remitentes eligen entre ellos, lo cual es un balanceo de carga normal.
- Introduce el dominio en el MX lookup: muestra los servidores de correo por prioridad, con sus direcciones IPv4 e IPv6 y registros PTR, y reconoce el proveedor de correo.
- O ejecuta
nslookup -type=mx example.comodig MX example.com +short: la respuesta tiene este aspecto:10 mx1.example.net. - Comprueba que cada nombre de host MX se resuelva a una dirección:
dig A mx1.example.net +short. - Compara la lista con las instrucciones de tu proveedor de correo: normalmente piden eliminar todos los registros MX antiguos, no añadir los suyos junto a ellos.
¿No hay registros MX? Según la RFC 5321, los remitentes probarán la dirección A/AAAA del propio dominio: el llamado MX implícito. Un dominio que no recibe correo debería publicar un null MX, 0 . (RFC 7505), para que los remitentes rechacen el mensaje de inmediato. Sin MX ni A, no es posible entregar correo al dominio.
| Error de MX | Consecuencia |
|---|---|
| MX apunta a una dirección IP | MX debe contener un nombre de host; muchos remitentes lo rechazarán |
| MX apunta a un CNAME | Los estándares lo prohíben; la mayoría de los servidores lo toleran, pero no todos |
| El host MX no tiene A/AAAA | No se puede entregar correo a ese servidor |
| MX se resuelve a una IP privada | El servidor no es accesible desde internet |
| Registros MX antiguos junto a los nuevos | Parte del correo llega al proveedor anterior |
| Null MX junto con otros registros MX | Configuración contradictoria: elimina el . o los demás registros |
MX solo cubre la recepción. Evitar que tu correo llegue a la carpeta de spam de los destinatarios es tarea de SPF, DKIM y DMARC, y la ruta de un mensaje concreto está en sus encabezados: consulta cómo leer los encabezados de un correo.
TTL y propagación de DNS
El TTL es el tiempo en segundos que los resolvers guardan una respuesta en caché. Con un TTL de 3600, un proveedor de internet que consultó una vez tu registro A seguirá devolviendo el valor anterior durante una hora, aunque ya lo hayas cambiado. La llamada "propagación de DNS" es simplemente la expiración gradual de cachés en todo el mundo. Cambiar los nameservers en el registrador suele tardar más: los registros de la zona del dominio de nivel superior tienen su propio TTL, normalmente largo.
- Antes de cambios planificados, reduce el TTL a 300 segundos, al menos un periodo del TTL anterior con antelación.
- Si consultaste un nombre antes de crear el registro, la respuesta negativa también se guarda en caché durante el tiempo definido en el registro SOA de la zona.
- Tu caché local también puede interferir: en Windows, límpiala con
ipconfig /flushdns; en macOS, consudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. - Si el servidor autoritativo responde correctamente pero los resolvers públicos no, no hay nada roto: solo tienes que esperar a que venza el TTL.
Cuándo debes comprobar el DNS
- El sitio carga para algunas personas, pero no para otras. Una causa común es que los registros se hayan cambiado recientemente y algunos ISP aún conserven los datos antiguos.
- El correo llega a spam. Revisa SPF, DKIM y DMARC en tus registros TXT.
- Cambio a un nuevo hosting. Anota tu DNS actual antes de hacer el cambio.
- Conexión de un servicio externo: correo, un CDN, un creador de sitios. Casi siempre se trata de un registro CNAME o TXT.
Errores comunes
- Editar los registros en el lugar equivocado. Si los registros NS del dominio apuntan a un proveedor, los cambios hechos en el panel de otro proveedor (el de tu registrador, por ejemplo) no tienen efecto. Revisa primero los NS.
- Dos registros SPF tras añadir un segundo servicio de correo, en lugar de combinarlos en uno solo.
- Un CNAME en el dominio raíz que rompe los registros MX y TXT.
- Registros MX olvidados durante una migración: el sitio funciona, pero el correo deja de llegar.
- Una IP antigua en www: el registro A del dominio raíz se actualizó, pero www sigue apuntando a la anterior.
Lista de verificación para cambiar de hosting
- Un día antes, reduce el TTL de tus registros para que el cambio se aplique rápidamente.
- Anota tus registros actuales: A, MX, TXT y NS deben quedar documentados antes de hacer cualquier cambio.
- Configura el sitio en el nuevo servidor y pruébalo por IP sin tocar el dominio.
- Cambia el registro A y observa las respuestas de distintos resolvers.
- Asegúrate de que el correo siga funcionando: MX y SPF son los registros que más se olvidan durante un cambio.
- Restablece el TTL original y revisa el certificado SSL en la nueva dirección.
