Registros MX y TXT explicados

¿Qué son los registros MX?

Un registro MX asocia un dominio con uno o más intercambiadores de correo, cada uno con un entero de prioridad (preferencia). Los remitentes prueban primero el número más bajo; prioridades iguales pueden repartirse en equilibrio. Ejemplo: `10 mail.example.com` y `20 mail-backup.example.com`.

Los destinos MX deben ser nombres de host con registros A o AAAA — no direcciones IP sueltas. Tras cambiar MX, verifique con el DNS Checker y espere a que expire el TTL en cachés antiguas. Combine la comprobación MX con el Blacklist Checker si el correo entrante empieza a ir a spam.

Los dominios de producción deben publicar al menos dos hosts MX en redes distintas. Si el intercambiador primario no es alcanzable, RFC 5321 exige que los sitios remitentes prueben el siguiente host de menor prioridad. Documente ambas prioridades en tickets de cambio y vuelva a ejecutar el DNS Checker tras cada edición MX para que los hilos de soporte muestren prioridades en vivo, no capturas de panel.

¿Qué son los registros TXT?

Los registros TXT almacenan cadenas de texto arbitrarias. Los operadores de correo publican SPF en el apex (o subdominio legacy) como `v=spf1 ...`, DKIM en selectores como `default._domainkey.example.com`, y DMARC en `_dmarc.example.com`. La verificación de sitios usa tokens cortos (`google-site-verification=...`, `MS=ms...`).

Varias cadenas en una misma respuesta TXT son normales. Algunos paneles dividen claves DKIM largas en fragmentos. Al diagnosticar, copie el valor concatenado exacto del DNS Checker en lugar de reescribirlo desde un PDF.

TXT también se usa para BIMI, MTA-STS y TLS-RPT en configuraciones de correo avanzadas — siempre como texto en nombres predecibles. Si su proveedor rota selectores DKIM, pueden aparecer brevemente selectores antiguos y nuevos; consulte TXT tras cada rotación y anote TTL antes de eliminar claves retiradas.

SPF, DKIM y DMARC en TXT

SPF enumera qué hosts pueden enviar correo por su dominio (`v=spf1 include:... ~all`). Solo puede existir un TXT SPF por owner name — cadenas SPF duplicadas invalidan la política por completo. Fusione includes en lugar de añadir un segundo registro en el apex.

DKIM publica una clave pública en `selector._domainkey.example.com`. La alineación con el dominio del encabezado From importa para pass/fail de DMARC. Tras incorporar un relay, confirme el TXT del selector en el DNS Checker según el panel del proveedor antes de campañas masivas.

DMARC en `_dmarc.example.com` fija la política (`p=none`, `quarantine`, `reject`) y direcciones de informes (`rua=`, `ruf=`). Empiece con `p=none` para informes agregados, luego endurezca cuando SPF y DKIM se alineen con fiabilidad. Vuelva a comprobar las tres familias con el DNS Checker tras cualquier migración de correo — MX solo nunca demuestra que SPF sea correcto.

Cómo comprobar MX y TXT online

Paso 1 — Abra el DNS Checker e introduzca el dominio (apex o subdominio). Paso 2 — Ejecute una consulta completa o céntrese en las secciones MX y TXT. Paso 3 — Compare prioridad, destinos y cadenas TXT con la guía de configuración de su proveedor de correo. Paso 4 — Si los valores están obsoletos, anote el TTL y vuelva a consultar cuando expire.

Para una consulta MX aislada, abra la herramienta DIG, elija tipo MX e inspeccione la sección de respuesta. Use el mismo dominio en WHOIS para confirmar que los servidores de nombres coinciden con el panel DNS que editó.

Archive la salida del checker en tickets: prioridades, hostnames de intercambiadores, cadenas SPF/DKIM/DMARC completas y valores TTL. Si Authentication-Results sigue mostrando fallos tras un arreglo, espere una ventana TTL completa y ejecute de nuevo el DNS Checker — las cachés recursivas suelen sobrevivir al momento en que pulsa Save en el panel.

Verificación y tokens TXT de terceros

Search Console, Microsoft 365, Stripe y emisores de certificados piden cada uno una prueba TXT única en el apex o etiquetas `_dnsauth`. Estos tokens coexisten con SPF como registros TXT separados en el mismo nombre — a diferencia de SPF, varias cadenas TXT no relacionadas en un owner son válidas.

Antes de borrar TXT «antiguos» durante la limpieza, confirme que ninguno es verificación activa o claves DKIM. El DNS Checker lista cada respuesta TXT en un nombre para comparar con la documentación del proveedor en lugar de adivinar de memoria.

Tras añadir un TXT de verificación, consulte de inmediato con el DNS Checker y de nuevo tras el TTL si el proveedor sigue informando fallo. Algunos registradores publican zonas por lotes cada pocos minutos — dos ejecuciones idénticas del checker cinco minutos aparte dan confianza más rápido que refrescar solo la UI del proveedor.

Problemas habituales

La ausencia de SPF es la vía más rápida a carpetas de spam. Una prioridad MX incorrecta envía correo a un host dado de baja. Un TXT de verificación mal escrito rompe Search Console o la configuración de Microsoft 365. Respuestas en caché tras no bajar el TTL antes de un corte parecen «DNS roto» cuando la propagación sigue en curso.

Dos registros SPF en el mismo nombre invalidan SPF por completo — fusione en un solo TXT. DMARC sin DKIM/SPF alineados informa de fallos pero no los corrige; trate DMARC como capa de política sobre registros de autenticación que ya funcionen.

Apuntar MX a una etiqueta solo CNAME rompe la resolución en resolvers estrictos. Publicar MX hacia un hostname sin A/AAAA operativos crea pérdida silenciosa de correo — confirme destinos de intercambiadores en el DNS Checker tras cada cambio de destino MX.

MX y TXT durante migraciones

Las migraciones de correo fallan en silencio cuando MX se actualiza antes de que SPF/DKIM/DMARC estén listos en el nuevo proveedor, o cuando registros MX antiguos permanecen con números de prioridad más bajos de lo previsto. Publique una baseline con el DNS Checker antes del cutover y compare secciones MX y TXT cada hora durante la ventana de migración.

Reduzca TTL en MX y TXT críticos veinticuatro a cuarenta y ocho horas antes del cambio si su host DNS lo permite. Confirme el TTL más bajo públicamente con el DNS Checker — algunos paneles muestran 300 segundos mientras la zona en vivo aún sirve 3600 hasta completar el siguiente ciclo de publicación.

Mantenga MX del proveedor antiguo con prioridad más alta (número mayor) hasta validar entrega entrante en el nuevo stack, luego elimine intercambiadores retirados. El correo saliente puede seguir usando includes SPF antiguos hasta actualizar TXT en el apex — compruebe ambas direcciones con el DNS Checker antes de cerrar el ticket.

Documente quién posee cada cadena TXT (verificación de marketing, correo IT, informes DMARC de finanzas) para que futuras limpiezas no borren registros de autenticación de producción por error.

Preguntas frecuentes

¿Cuánto tardan en aparecer los cambios DNS?

La mayoría de los resolvers respetan el TTL (time to live). Si el TTL es 3600 segundos, espere hasta una hora antes de que expiren las respuestas en caché. Reduzca el TTL antes de migraciones, aplique el cambio y verifique con el DNS Checker hasta ver los nuevos valores.

¿Puedo comprobar MX y TXT sin instalar dig?

Sí. Abra el DNS Checker, introduzca su dominio y filtre o desplácese hasta las secciones MX y TXT. Para un solo tipo de registro también puede usar la herramienta DIG con tipo MX o TXT.

¿Por qué el correo funciona pero SPF sigue fallando?

SPF solo autoriza IPs de envío o cadenas include. Un registro MX correcto no implica que SPF esté bien. Compare las IPs SMTP salientes con la cadena include de SPF y use consultas TXT para confirmar que la cadena publicada coincide con la documentación de su proveedor de correo.

¿Debo usar varios registros MX?

Sí en correo de producción. Publique al menos dos hosts MX con prioridades distintas (número menor = mayor preferencia). Si el primario cae, los remitentes prueban la siguiente prioridad según RFC 5321.

¿Qué RFC define SPF?

SPF está definido en RFC 7208 (antes RFC 4408). DKIM es RFC 6376 y DMARC es RFC 7489. Todos se publican como registros TXT en nombres predecibles.

¿Puedo publicar MX y SPF en la misma etiqueta de hostname?

MX y SPF suelen vivir en nombres distintos — MX en el apex o subdominio mail, SPF como TXT en el apex. Nunca coloque CNAME en una etiqueta que también necesite MX o SPF. Use el DNS Checker para confirmar que tipos conflictivos no comparten un mismo owner name.

¿Con qué frecuencia debo volver a comprobar MX y TXT en producción?

Tras cada cambio de DNS o proveedor de correo, más auditorías trimestrales para dominios que envían correo masivo. El monitorizado automatizado vía la API de DN01 puede alertar cuando prioridades MX o cadenas SPF se desvían de los valores esperados.

¿DNS Checker almacena mis consultas?

Las comprobaciones correctas pueden aparecer en el historial reciente local de su sesión del navegador por comodidad. Use la API documentada con su propio token si necesita monitorización repetible sin la interfaz web.