Ir al contenido principal

Búsqueda registro MX

Identifique los servidores de correo de su dominio

¿Sus emails no se entregan? Verifique que sus registros MX apunten a los servidores de correo correctos. Compare las respuestas de múltiples resolutores para detectar problemas de configuración.

En modo de traza iterativa, se ignora el resolvedor.
Consulta varios resolvedores públicos para comparar las respuestas.

Servidores y prioridades

Muestre todos los servidores MX con sus prioridades. El servidor con la prioridad más baja recibe el correo primero.

Validación de destinos

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

Comparación multi-resolutor

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

Diagnóstico completo

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

Gratuito y sin registro

Pruebe tantos dominios como necesite. No se requiere cuenta.

¿Cómo usar correctamente las diferentes opciones del motor de búsqueda DNS?

¿Qué es la traza iterativa?

La traza ejecuta la resolución paso a paso. El resolvedor consulta primero a los servidores raíz, luego a los del TLD (.com, .fr, .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 resolvedores y las regiones
  • Detectar un 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 resolvedor 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 → resolvedor.

  1. 1. Resolvedor elegido

    Utiliza el preset 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 resolvedor 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 resolvedor concreto; actívala después para compararla con el recorrido raíz → TLD → autoritativo.

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

La prueba consulta en paralelo un conjunto de resolvedores 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. Resolvedores multipunto

    Activa los presets de propagación para consultar a varios actores repartidos por el mundo.

  2. 2. Comparación automática

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

  3. 3. Resumen accionable

    Ofrece un resumen claro, la lista de resolvedores, 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 antiguos y decidir un vaciado específico
  • Compartir un estado de propagación en un ticket o post-mortem

Truco: durante la prueba de propagación la selección de resolvedor queda bloqueada. Desactiva el modo para volver al diagnóstico unitario.

¿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

@  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 su tenant de Microsoft.

Servidor dedicado

@  MX  10  mail.captaindns.com.

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


Buenas prácticas

Redundancia

  • Configure al menos 2 servidores MX con diferentes prioridades
  • El servidor de respaldo debe poder almacenar emails temporalmente (store-and-forward)
  • Pruebe 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
Reverse DNSLa 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. Verifique que el MX existe y apunta a un nombre válido
  2. Confirme que el destino del MX tiene un registro A/AAAA
  3. Pruebe la accesibilidad del servidor en el puerto 25
  4. Verifique el reverse DNS (PTR) de la IP del servidor

Emails entregados al servidor incorrecto

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

Retraso en la entrega

  1. Verifique que el servidor principal (prioridad baja) es accesible
  2. Si el respaldo recibe los emails, el principal tiene un problema
  3. Consulte 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 reverse DNS del servidor

Recursos útiles