Consulta MX — Buscar Registros de Correo

Consulta MX gratis (check MX) para cualquier dominio: vea sus servidores de correo en orden de entrega, quién los opera, sus direcciones IPv4 e IPv6 y si responden con STARTTLS. Directamente desde los servidores de nombres del propio dominio, junto a las copias en caché de Google y Cloudflare.

Fuentes: los servidores de nombres del dominio, alcanzados desde un servidor raíz · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · servidores de correo probados desde nuestro servidor en Mumbai

¿Qué es un registro MX?

Un registro MX (mail exchange) indica los servidores que reciben el correo de un dominio, cada uno con un número de prioridad: los remitentes prueban primero el número más bajo.

Cuando alguien escribe a name@airbnb.com, su servidor de correo pide al DNS los registros MX de airbnb.com, elige el servidor con el número más bajo y entrega por SMTP en el puerto 25. El registro contiene un nombre de host, nunca una dirección IP, y ese nombre necesita su propio registro A o AAAA: no puede ser un alias (un CNAME, RFC 2181 §10.3).

Una consulta MX lee esos registros y sigue cada servidor hasta sus direcciones, su red y el proveedor que hay detrás. El MX solo dirige el correo entrante: quién puede enviar como el dominio lo deciden SPF, DKIM y DMARC.

Anatomía de un registro MXairbnb.com, desde su propio servidor de nombres
airbnb.com.Nombre300TTLINClaseMXTipo1Prioridadaspmx.l.google.com.Servidor de correo (exchange)
Nombre y TTLEl dominio que recibe el correo y cuánto tiempo pueden guardar las cachés esta respuesta: 300 s = 5 min.
PrioridadLa más baja se prueba primero. airbnb.com tiene 1, 5, 5, 10, 10.
Servidor de correoUn nombre de host con sus propios registros A y AAAA: 192.178.211.27 y 2404:6800:4000:1025::1b.
1 aspmx.l.google.com.Un nombre de host con registros A y AAAA
1 192.0.2.25Una dirección IP no es un servidor de correo válido
1 mail → CNAMEEl servidor de correo no puede ser un alias (RFC 2181 §10.3)
Cada campo tal como lo sirve el propio servidor de nombres de airbnb.com. La herramienta marca un MX que apunta a una dirección IP, a un CNAME o a un nombre sin dirección.

Cómo verificar los registros MX

Escriba el dominio arriba y haga clic en Consultar MX, o consulte el DNS desde una terminal: dig example.com MX en macOS y Linux, nslookup -type=mx example.com en cualquier sistema o Resolve-DnsName example.com -Type MX en Windows PowerShell.

Cada línea de respuesta es un servidor: la prioridad y luego el nombre de host. El número antes de IN es el TTL, los segundos que un resolutor puede seguir sirviendo esta copia. Agregue @ y un servidor de nombres (dig @dns1.p08.nsone.net airbnb.com MX) para leer la respuesta de la propia zona en lugar de una caché.

dig example.com MX +short

Cada línea: la prioridad y luego el servidor de correo. Agregue @ y un servidor de nombres para saltarse las cachés.

Cómo leer la respuesta de digregistrado el 23/10/2026
bash · zsh
$ dig airbnb.com MX
;; ->>HEADER<<- opcode: QUERY, status: NOERROR1
;; flags: qr rd ra; QUERY: 1, ANSWER: 5

;; ANSWER SECTION:
airbnb.com.    3002  IN  MX   13 aspmx.l.google.com.4
airbnb.com.    300   IN  MX   5 alt1.aspmx.l.google.com.
airbnb.com.    300   IN  MX   5 alt2.aspmx.l.google.com.
airbnb.com.    300   IN  MX  10 alt3.aspmx.l.google.com.
airbnb.com.    300   IN  MX  10 alt4.aspmx.l.google.com.

;; SERVER: 8.8.8.8#53(8.8.8.8)5
  1. Estado. NOERROR con respuestas. NXDOMAIN significa que el nombre no existe; NOERROR sin respuesta significa que no hay MX.
  2. TTL. Segundos que esta copia todavía puede servirse: 300 en el origen, en cuenta regresiva en las cachés.
  3. Prioridad. El orden en que prueban los remitentes, el más bajo primero.
  4. Servidor de correo. El host al que conectarse en el puerto 25; el punto final cierra el nombre.
  5. Quién respondió. 8.8.8.8 es una caché. @dns1.p08.nsone.net pregunta a la propia zona.
Las mismas cinco líneas aparecen en la vista Servidores de la herramienta, ordenadas y agrupadas por prioridad, con las direcciones de cada servidor al lado.

Cómo leer el resultado

El encabezado dice en una frase quién recibe el correo del dominio y cuántos servidores hay detrás, con el logotipo del proveedor; las filas de color debajo son los hallazgos que importan.

La vista Servidores lista cada host MX por prioridad con sus direcciones, su red y su DNS inverso; el primer servidor se prueba automáticamente en el puerto 25 y los demás a petición. A la derecha, la ruta de entrega muestra lo que hace un remitente con estas respuestas.

Consulta MX: cinco registros MX en Google Workspace, direcciones y prueba STARTTLS de cada servidor y la ruta del correoConsulta MX: cinco registros MX en Google Workspace, direcciones y prueba STARTTLS de cada servidor y la ruta del correoEl veredictoQuién recibe el correo, los servidores y niveles, la red, el TTL y qué servidor de nombres respondió.Los servidoresCada host MX por prioridad con sus direcciones IPv4 e IPv6, su número de AS y su PTR con confirmación directa.La prueba SMTPSTARTTLS y la versión de TLS desde nuestro servidor en el puerto 25; abra una fila para ver toda la conversación.La ruta de entregaEl remitente, las protecciones del primer tramo, cada nivel de prioridad y luego los buzones con su evidencia.
Una consulta MX de airbnb.com: el veredicto, los servidores por prioridad con sus direcciones y su prueba STARTTLS, y la ruta que sigue el correo. Seleccione un número para ver qué muestra cada parte.

¿Qué significa la prioridad MX?

La prioridad (el RFC 5321 la llama preferencia) fija el orden: un remitente prueba primero el número más bajo y solo pasa al siguiente cuando ese servidor no responde o aplaza el mensaje con una respuesta temporal 4xx.

Los servidores con el mismo número se reparten la carga: el remitente elige uno al azar. Solo cuenta el orden, no la distancia entre números, y 0 es un número válido. Un solo registro MX basta cuando el nombre que hay detrás se reparte entre muchos servidores, como ocurre con Microsoft 365 y Mimecast.

Nuestro consejo sobre el MX de respaldo: un respaldo en otra empresa que filtre menos que su servidor principal es una vía conocida para el spam, y los proveedores alojados ya operan servidores redundantes detrás de un solo nombre MX. Si conserva uno, debe aplicar los mismos controles de SPF y antispam que el principal (RFC 7208, apéndice F).

Cómo recorre un remitente los cinco servidores de airbnb.comprioridades 1 · 5 · 10
Intento 1prioridad 1
aspmx.l.google.comsiempre se prueba primero
250 OK

solo si no responde o responde 4xx

Intento 2prioridad 5
alt1.aspmx.l.google.comelegido al azar · ½alt2.aspmx.l.google.como este · ½
los números iguales reparten la carga

luego

Intento 3prioridad 10
alt3.aspmx.l.google.com½alt4.aspmx.l.google.com½
todos fallan: cola y reintentos durante días
0 es válidogithub.com publica la prioridad 0 para su único MX.
1, 5, 10 ≡ 10, 20, 30Solo cuenta el orden, no la distancia entre números.
Un MX puede bastarEl único host MX de hp.com representa 6 direcciones.
Los remitentes bajan por la lista solo cuando un servidor no responde o devuelve un error temporal; cuando todos fallan, el mensaje espera en la cola y se reintenta durante 4 a 5 días (RFC 5321).

Registros MX de Google Workspace

Los dominios nuevos de Google Workspace necesitan un solo registro MX: smtp.google.com con prioridad 1. Los dominios configurados antes de 2023 suelen publicar todavía el conjunto de cinco registros que empieza por aspmx.l.google.com; según Google, ambos funcionan y una configuración que funciona no necesita cambios.

La herramienta identifica Google Workspace con cualquiera de los dos conjuntos y marca el antiguo como heredado, nunca como error. Acompañe el MX con SPF include:_spf.google.com y con DKIM desde la Consola del administrador; Google calcula hasta 72 horas para que los registros MX nuevos se vean en todas partes.

Las dos configuraciones de Google Workspace, lado a ladoMX actuales, 23/10/2026
Actualun registrorecomendada
1 smtp.google.com.
Visto en google.comsendgrid.com
Antiguacinco registrossigue siendo válida
1 aspmx.l.google.com.5 alt1.aspmx.l.google.com.5 alt2.aspmx.l.google.com.10 alt3.aspmx.l.google.com.10 alt4.aspmx.l.google.com.
Visto en airbnb.comnytimes.comuber.comspotify.com
La política MTA-STS de google.com acepta ambas:smtp.google.comaspmx.l.google.com*.aspmx.l.google.com
spotify.com todavía incluye los hosts antiguos aspmx2–aspmx5.googlemail.com con prioridad 10, siete registros en total: los nombres antiguos de más no causan problemas.

Registros MX de Microsoft 365

Microsoft 365 da a cada dominio un registro MX bajo mail.protection.outlook.com, como microsoft-com.mail.protection.outlook.com, normalmente con prioridad 0. La primera parte es un token que se copia del Centro de administración de Microsoft 365: suele parecerse al dominio con guiones, pero no siempre.

Los dominios que activan SMTP DANE de entrada reciben en su lugar un host bajo mx.microsoft, como siemens-com.h-v1.mx.microsoft: esa zona está firmada con DNSSEC, así que los remitentes pueden verificar el certificado del servidor con DANE. Durante la migración ambos registros están activos, el nuevo primero detrás del antiguo y luego delante, hasta que se elimina el antiguo. Microsoft no tiene previsto firmar mail.protection.outlook.com, así que el host tradicional no está obsoleto.

Cómo leer un host MX de Microsoft 365microsoft.com · siemens.com
Exchange Onlinela forma habitual
microsoft-comtoken del Centro de administración.mail.protection.outlook.comExchange Online Protection
Visto en microsoft.comgithub.comunilever.com
Con DANEzona firmada con DNSSECDANE
siemens-comtoken del Centro de administración.h-v1un fragmento.mx.microsoftzona firmada
Visto en siemens.comshell.com
Durante la migración al nuevo hostambos registros activos; gana el número más bajo
0contoso-com.o-v1.mx.microsoft.nuevo · se prueba primero
30contoso-com.mail.protection.outlook.com.antiguo · hasta que se elimine
Un host tradicional y un host mx.microsoft con prioridades distintas son una migración en curso según los pasos documentados por Microsoft, no un error: la herramienta lo indica en lugar de advertir.

Sin registro MX o MX nulo: ¿qué pasa?

Un dominio sin registros MX todavía puede recibir correo: los remitentes recurren a la dirección A o AAAA del propio dominio (RFC 5321 §5.1). Solo un MX nulo, el registro único 0 ., indica a todos los remitentes que el dominio no acepta correo (RFC 7505).

Por eso el MX nulo es el registro correcto para un dominio que nunca recibe correo: los remitentes lo devuelven de inmediato, con 556 5.1.10, en lugar de reintentar durante días. Agregue v=spf1 -all y DMARC p=reject para que tampoco nadie pueda enviar como él, como hace example.com. Los registros MX pertenecen a un solo nombre: www.example.com no hereda los de example.com.

Cuatro respuestas, cuatro resultadoslo que hace un remitente con cada una
Registros MXairbnb.comEntregar a los servidores en orden de prioridad.entregado250 OK
Sin MX, con A/AAAAwww.google.comEntregar a la dirección propia del nombre: sus registros A y AAAA. Si allí no responde el puerto 25, el correo espera y luego se devuelve.MX implícitoRFC 5321 §5.1
MX nulo: 0 .example.comNo intentarlo en absoluto. El remitente devuelve el mensaje de inmediato.rechazado556 5.1.10
El nombre no existeairbnb.cmoDevolver: la raíz no tiene .cmo, así que nada debajo existe.devuelto5.1.2

Un dominio que no envía ni recibe correo:MX 0 .v=spf1 -all_dmarc p=reject

Cada fila es el veredicto de la herramienta para ese ejemplo: ábralo desde los botones de ejemplo sobre la herramienta.

¿No llega el correo? Dónde encaja el MX en el diagnóstico

Lea primero el rebote: su código de estado indica qué paso falló. Los problemas de MX aparecen como "host not found" o como demoras largas; un buzón inexistente es 5.1.1; los fallos de autenticación son rechazos 5.7.x.

Recorra la lista en orden: el dominio debe existir, su MX debe indicar el proveedor que usted usa, cada host MX debe resolver y responder en el puerto 25, y solo entonces SPF, DKIM, DMARC y las listas negras deciden dónde termina un mensaje.

Del rebote a la solucióncódigos de estado extendidos, RFC 3463
Host o dominio no encontrado5.1.2 · NXDOMAINEl dominio o su host MX no existe. Revise la ortografía y los servidores de nombres.Consulta DNS
El correo sigue llegando al proveedor anteriortras un cambio de MXLas cachés conservan el MX antiguo hasta que vence su TTL. Compare la zona con las copias de Google y Cloudflare.Vista Copias
Demorado y luego devuelto4.4.1 · sin respuesta del hostEl host MX está caído, no tiene dirección o el puerto 25 está bloqueado. Pruebe los servidores desde nuestro lado.Probar servidores
Usuario desconocido5.1.1El MX funciona; el buzón no existe en el proveedor.Verificador de correo
Rechazado: sin autenticar5.7.1El receptor rechazó al remitente. Corrija SPF, DKIM y DMARC en el dominio que envía.Verificador SPF
Bloqueado por la dirección o enviado a spamen listaLa IP del servidor que envía está en una lista negra.Listas negras
Los dos pasos resaltados son vistas de esta herramienta; los demás abren la herramienta correspondiente.

MTA-STS, DANE y TLS para servidores de correo

Los servidores de correo cifran con STARTTLS solo cuando ambos lados lo ofrecen, así que alguien en el camino puede eliminar la oferta y leer el mensaje. MTA-STS y DANE permiten que un dominio exija TLS a los remitentes.

MTA-STS publica una política por HTTPS (https://mta-sts.<domain>/.well-known/mta-sts.txt) con los hosts MX permitidos y un modo; con enforce, los remitentes solo entregan a esos hosts mediante TLS válido (RFC 8461). DANE pone la clave del servidor en un registro TLSA en _25._tcp.<mx host>, que solo cuenta donde DNSSEC firma esa zona (RFC 7672). TLS-RPT pide a los remitentes que informen de los fallos (RFC 8460). La herramienta comprueba que cada MX actual coincida con una línea mx: de la política.

Tres candados en un mismo tramoun remitente → proton.me, en vivo
remitentecualquier servidor de correo
STARTTLS · ofrecido, TLS 1.3STARTTLS por sí solo puede eliminarse por el camino: 250-STARTTLS simplemente desaparece de la respuesta.
MTA-STS · modo enforcemx: mail.protonmail.ch · mx: mailsec.protonmail.ch · max_age: 604800 ✓ coinciden los dos hosts MX actuales
DANE · TLSA 3 1 1_25._tcp.mail.protonmail.ch, firmado con DNSSEC (protonmail.ch) ✓
mail.protonmail.chprioridad 10
TLS-RPT también está activo: v=TLSRPTv1; rua=https://reports.proton.me/reports/smtptls. La herramienta prueba STARTTLS desde nuestro servidor; MTA-STS y DANE se obtienen del DNS y del archivo de política.

Hosts MX de los proveedores más comunes

La mayoría de los dominios apuntan su MX a uno de unas pocas decenas de proveedores, y cada uno publica nombres de host reconocibles. Así es como la herramienta identifica el proveedor de correo de un dominio, y como usted puede comparar una configuración con los valores del propio proveedor.

Las pasarelas como Mimecast, Proofpoint y Barracuda se colocan delante del host de los buzones; entonces la herramienta lee SPF y Autodiscover para nombrar los buzones probables que hay detrás.

Hosts MX e includes de SPF por proveedor16 de los 110+ proveedores que reconoce la herramienta
ProveedorMX (prioridad host)SPF
Google Workspace1smtp.google.como 1 aspmx.l.google.com + 4 altinclude:_spf.google.com
Microsoft 3650<token>.mail.protection.outlook.como <token>.<x>-v1.mx.microsoftinclude:spf.protection.outlook.com
Zoho Mailregión en el TLD10mx.zoho.com20mx2.zoho.com · 50 mx3.zoho.cominclude:zohomail.com
Proton Mail10mail.protonmail.ch20mailsec.protonmail.chinclude:_spf.protonmail.ch
iCloud Mail10mx01.mail.icloud.com10mx02.mail.icloud.cominclude:icloud.com
Fastmail10in1-smtp.messagingengine.com20in2-smtp.messagingengine.cominclude:spf.messagingengine.com
Yandex 36010mx.yandex.netredirect=_spf.yandex.net
Titan Email10mx1.titan.email20mx2.titan.emailinclude:spf.titan.email
GoDaddy Professional Email0smtp.secureserver.net10mailstore1.secureserver.netinclude:secureserver.net
Namecheap Private Email10mx1.privateemail.com10mx2.privateemail.cominclude:spf.privateemail.com
Cloudflare Email Routingreenvíoroute1/2/3.mx.cloudflare.netprioridades definidas por dominioinclude:_spf.mx.cloudflare.net
Amazon SEScompartido con WorkMail10inbound-smtp.<region>.amazonaws.cominclude:amazonses.com
Mimecastpasarela10<region>-smtp-inbound-1.mimecast.com10<region>-smtp-inbound-2.mimecast.cominclude:<region>._netblocks.mimecast.com
Proofpointpasarelamx0a-<id>.pphosted.com · mx0b-<id>o mx1-us1.ppe-hosted.com (Essentials)a:dispatch-us.ppe-hosted.com (Essentials)
Barracudapasarela1<id>.ess.barracudanetworks.com10<id>.ess.barracudanetworks.cominclude:spf.ess.barracudanetworks.com
NAVER WORKSCorea10kr1-aspmx1.worksmobile.com20kr1-aspmx2.worksmobile.cominclude:spf.worksmobile.com

Consulta MX: preguntas frecuentes

¿Para qué sirve una consulta MX?

Una consulta de registros MX muestra qué servidores reciben el correo de un dominio y quién los opera. Úsela para conocer el proveedor de correo de una empresa, confirmar un cambio de MX después de cambiar de proveedor, diagnosticar rebotes y demoras, o revisar un dominio antes de escribirle. Esta herramienta también prueba el STARTTLS de cada servidor de correo desde nuestro servidor y lee el SPF, el DMARC y el MTA-STS del dominio.

¿Cómo consultar los registros MX con nslookup?

Ejecute nslookup -type=mx example.com. Cada línea de respuesta muestra la prioridad como "MX preference" y el servidor como "mail exchanger". Agregue un servidor al final, como nslookup -type=mx example.com 8.8.8.8, para preguntar a un resolutor concreto, o indique el servidor de nombres del propio dominio para saltarse todas las cachés. En macOS y Linux, dig example.com MX da la misma respuesta.

¿Un dominio puede tener más de un registro MX?

Sí. Cada registro MX indica un servidor de correo con una prioridad. Los remitentes prueban primero el número más bajo, pasan al siguiente solo cuando un servidor no responde o aplaza la entrega, y eligen al azar entre servidores con el mismo número, lo que reparte la carga. gmail.com publica cinco registros MX con cinco prioridades; yahoo.com publica tres con la misma prioridad.

¿Un registro MX puede apuntar a una dirección IP o a un CNAME?

No. El valor del MX debe ser un nombre de host con su propio registro A o AAAA. Una dirección IP no es un valor válido, y el RFC 2181 prohíbe un host MX que sea un alias (un CNAME). Algunos remitentes igual siguen un CNAME o se conectan a una IP mientras otros lo rechazan, así que el correo puede llegar desde unos remitentes y rebotar desde otros. La herramienta marca ambos casos.

¿Cuánto tardan los cambios en los registros MX?

Lo que dure el TTL del registro antiguo. Los resolutores que guardaron en caché el MX antiguo lo siguen usando hasta que caduca su copia y luego vuelven a preguntar a los servidores de nombres del dominio; una respuesta "sin MX" en caché caduca igual. Baje el TTL un día antes de cambiar de proveedor. Los proveedores indican márgenes de seguridad (Google calcula hasta 72 horas), y la vista Copias muestra cuándo se renuevan las copias de Google y Cloudflare.

¿Qué es un registro MX nulo?

Un MX nulo es un único registro MX con prioridad 0 y un solo punto como host: 0 . (RFC 7505). Indica que el dominio no acepta correo, así que los remitentes devuelven un mensaje de inmediato, con 556 5.1.10, en lugar de reintentar durante días. Debe ser el único registro MX. example.com publica uno, junto con SPF -all y DMARC p=reject.

¿Qué pasa si un dominio no tiene registro MX?

El correo se intenta de todos modos. Sin registro MX, los remitentes entregan a la dirección A o AAAA del propio dominio, el MX implícito (RFC 5321, sección 5.1). Si allí nada responde en el puerto 25, el mensaje espera en la cola del remitente, se reintenta durante cuatro a cinco días y luego se devuelve. Un dominio que no debe recibir correo debería publicar un MX nulo.

¿Un solo registro MX es un problema?

No. Un solo registro MX es una configuración completa cuando el nombre que hay detrás tiene balanceo de carga: smtp.google.com de Google Workspace y los hosts mail.protection.outlook.com de Microsoft 365 responden cada uno desde muchos servidores. El RFC 5321 no exige un número mínimo de registros MX. La herramienta muestra cuántas direcciones IPv4 e IPv6 hay detrás de cada host MX, para que vea la redundancia.

¿Por qué el MX muestra un proveedor distinto del que esperaba?

Puede haber una pasarela delante de los buzones. Mimecast, Proofpoint, Barracuda y Cloudflare Email Security filtran primero el correo, así que el MX indica la pasarela mientras los buzones están en Microsoft 365, Google Workspace u otro proveedor detrás de ella. La herramienta lee el include de SPF y el registro Autodiscover del dominio para nombrar el proveedor de buzones probable, y muestra esa evidencia.

¿Los registros MX son públicos?

Sí. Los registros MX son datos DNS públicos por diseño: cualquier servidor de correo del mundo debe poder consultarlos para entregar a su dominio. Muestran qué servidores reciben correo y quién los opera, no quién envía ni qué hay en los buzones. Ocultarlos impediría que su correo llegue.

¿Los registros MX afectan el envío de correo?

No. Los registros MX solo dirigen el correo entrante a sus servidores. Qué servidores pueden enviar como su dominio lo deciden SPF, DKIM y DMARC, que los receptores verifican en cada mensaje. Puede enviar desde un proveedor y recibir en otro; en ese caso ambos aparecen en el SPF, pero solo el que recibe está en el MX.

¿Por qué no puedo conectarme al puerto 25 desde mi computadora?

La mayoría de las redes domésticas y móviles, y nubes como AWS, Google Cloud y Azure, bloquean las conexiones salientes al puerto 25 para frenar el spam, así que un telnet u openssl hacia un servidor de correo agota el tiempo de espera. Eso no dice nada del servidor. Esta herramienta prueba cada servidor de correo desde nuestro propio servidor en Mumbai, que sí puede llegar al puerto 25, y muestra toda la conversación.

¿Le falta algo?Sugiera una función o una herramienta nueva