Ir al contenido principal

Búsqueda registro MX

Identifica los servidores de correo de tu dominio

¿Tus emails no se entregan? Verifica que tus registros MX apunten a los servidores de correo correctos. Compara las respuestas de múltiples resolutores para detectar problemas de configuración.

Tipo de registrocada tipo tiene su propia página

El resultado se muestra más abajo automáticamente

Modo de resolución
Probar la propagación DNS

Simple = una consulta al resolver · Traza = descenso desde la raíz

opcionesOpciones avanzadas

Puntos clave de la herramienta

Servidores y prioridades

Muestra todos los servidores MX con sus prioridades. El servidor con el valor de prioridad más bajo recibe el correo primero.

Validación de destinos

Verifica que cada servidor MX resuelva a un registro A o AAAA válido. Un MX sin IP impide la entrega.

Comparación multi-resolutor

Compara las respuestas de Google, Cloudflare, Quad9 para detectar inconsistencias de propagación.

Diagnóstico completo

Identifica registros MX huérfanos, prioridades mal configuradas o servidores inalcanzables.

Gratuito y sin registro

Prueba tantos dominios como necesites. No se requiere cuenta.

¿Cómo usar correctamente las diferentes opciones de la consulta DNS?

¿Qué es la traza iterativa?

La traza ejecuta la resolución paso a paso. El resolver consulta primero a los servidores raíz, luego a los del TLD (.com, .es, .eu) y finalmente a los servidores autoritativos de la zona objetivo. En cada etapa la página muestra el servidor consultado, la respuesta, el RCODE y la latencia.

  1. 1. Raíz

    Descubrimiento de los servidores del TLD para el nombre solicitado.

  2. 2. TLD

    Referencia a los NS de la zona (delegación).

  3. 3. Autoritativos

    Respuesta final (o error) con TTL y latencia.

¿Para qué sirve?

  • Comparar respuestas según los resolvers y las regiones
  • Detectar una caché caliente, un TTL demasiado largo o una delegación incompleta
  • Explicar una diferencia de latencia o un RCODE inesperado

Truco: deja la traza desactivada para las comprobaciones rápidas; actívala cuando investigues o prepares un ticket/post-mortem.

¿Qué es la traza clásica?

La traza clásica consulta únicamente el resolver seleccionado (UDP o DoH) y muestra la respuesta tal como se percibe desde ese punto de la red. Obtienes el RCODE, las secciones de la respuesta y la latencia del tramo cliente → resolver.

  1. 1. Resolver elegido

    Utiliza el ajuste predefinido o la configuración personalizada para lanzar la consulta exactamente como lo haría tu servicio.

  2. 2. Protocolo conservado

    Respeta el transporte seleccionado (UDP, TCP o DoH) para reproducir el comportamiento real.

  3. 3. Respuesta detallada

    Muestra las secciones question, answer y authority/additional cuando existen, con TTL y metadatos útiles.

¿Por qué usarla?

  • Comprobar la visión de un resolver específico antes de sospechar de la delegación
  • Confirmar los valores en caché y el impacto de un TTL o de un vaciado
  • Documentar una resolución tal como la ve un cliente o un microservicio

Truco: deja desactivada la opción de traza iterativa cuando audites un resolver concreto; actívala después para compararla con el recorrido raíz → TLD → autoritativo.

¿Cómo funciona la prueba de propagación?

La prueba de propagación es una herramienta dedicada que consulta en paralelo un conjunto de resolvers públicos (Google, Cloudflare, Quad9, OpenDNS, ISP...) y agrupa las respuestas por contenido y RCODE. Ves al instante quién ya aplicó la actualización.

  1. 1. Resolvers multipunto

    Consulta varios resolvers repartidos por el mundo en una sola prueba.

  2. 2. Comparación automática

    Agrupa las respuestas idénticas y señala las divergencias o los errores propios de cada resolver.

  3. 3. Resumen accionable

    Ofrece un resumen claro, la lista de resolvers, sus latencias y el estado de cada grupo.

¿Cuándo usarla?

  • Seguir la difusión de un cambio DNS a escala mundial
  • Identificar cachés aún antiguas y decidir un vaciado específico
  • Compartir un estado de propagación en un ticket o post-mortem

Truco: la prueba de propagación es una herramienta aparte. Usa el DNS Lookup (modo Simple o Traza) para el diagnóstico unitario de un resolver.

¿Qué es un registro MX?

Un registro MX (Mail Exchange) indica qué servidores reciben los emails de un dominio. Cuando alguien envía un email a user@captaindns.com, el servidor remitente consulta el MX de captaindns.com para saber dónde entregar el mensaje.

Estructura de un registro MX:

CampoDescripciónEjemplo
NombreEl dominio (@ para el apex)@
TipoSiempre MXMX
PrioridadOrden de preferencia (menor = primero)10
DestinoNombre del servidor de correomail.captaindns.com.
TTLDuración de caché en segundos3600

Ejemplo concreto:

captaindns.com.  3600  IN  MX  10 mail.captaindns.com.
captaindns.com.  3600  IN  MX  20 backup.captaindns.com.

El servidor con prioridad 10 recibe el correo primero. Si no está disponible, el servidor con prioridad 20 toma el relevo.


Configuración para proveedores comunes

Google Workspace

Configuración actual desde 2023, un registro único:

@  MX  1   SMTP.GOOGLE.COM.

Los dominios creados antes de 2023 publican el conjunto histórico, que Google sigue admitiendo:

@  MX  1   ASPMX.L.GOOGLE.COM.
@  MX  5   ALT1.ASPMX.L.GOOGLE.COM.
@  MX  5   ALT2.ASPMX.L.GOOGLE.COM.
@  MX  10  ALT3.ASPMX.L.GOOGLE.COM.
@  MX  10  ALT4.ASPMX.L.GOOGLE.COM.

Microsoft 365

@  MX  0  captaindns-com.mail.protection.outlook.com.

El nombre exacto depende de tu tenant de Microsoft.

Servidor dedicado

@  MX  10  mail.captaindns.com.

Asegúrate de que mail.captaindns.com tenga un registro A válido.


Buenas prácticas

Redundancia

  • Configura al menos 2 servidores MX con diferentes prioridades
  • El servidor de respaldo debe poder almacenar emails temporalmente (store-and-forward)
  • Prueba regularmente la conmutación deteniendo el servidor principal

Configuración correcta

ReglaExplicación
MX → hostnameUn MX apunta a un nombre, nunca a una IP
Hostname → A/AAAAEl destino del MX debe tener un registro A o AAAA
Sin CNAMEEl destino no debe ser un CNAME
DNS inversoLa IP del servidor de correo debe tener un PTR correspondiente

Evitar

  • MX hacia IP: MX 10 203.0.113.25 (inválido)
  • MX hacia CNAME: El MX debe apuntar a un A/AAAA directo
  • Prioridades idénticas sin intención: Puede causar distribución no deseada
  • MX huérfano: Un MX cuyo destino no resuelve a ninguna IP

Diagnóstico de problemas comunes

Emails no entregados (rebote)

  1. Verifica que el MX existe y apunta a un nombre válido
  2. Confirma que el destino del MX tiene un registro A/AAAA
  3. Prueba la accesibilidad del servidor en el puerto 25
  4. Verifica el DNS inverso (PTR) de la IP del servidor

Emails entregados al servidor incorrecto

  1. Verifica las prioridades: la más baja se contacta primero
  2. Elimina los MX antiguos después de una migración
  3. Espera la expiración del TTL después de los cambios

Retraso en la entrega

  1. Verifica que el servidor principal (prioridad baja) es accesible
  2. Si el respaldo recibe los emails, el principal tiene un problema
  3. Consulta los logs SMTP para identificar reintentos

Verificar en línea de comandos

Windows (nslookup)

nslookup
set q=mx
captaindns.com

Linux/Mac (dig)

dig MX captaindns.com

Resultado típico:

captaindns.com.  3600  IN  MX  10 mail.captaindns.com.
captaindns.com.  3600  IN  MX  20 backup.captaindns.com.

Verificar que el destino resuelve:

dig A mail.captaindns.com

Herramientas complementarias

HerramientaUtilidad
Probador de emailProbar la entregabilidad y autenticación
Inspector SPFVerificar registro SPF
Inspector DKIMValidar firma DKIM
Búsqueda AVerificar que el destino MX resuelve
Búsqueda PTRVerificar el DNS inverso del servidor

Recursos útiles