“0 .” — el dominio rechaza el correo
Definido en la RFC 7505 para dominios que nunca reciben correo. Los remitentes fallan de inmediato en lugar de reintentar durante días. Útil para dominios aparcados y dominios que solo envían.
Descubre qué servidores reciben el correo de un dominio, en qué orden y qué proveedor los gestiona — Google Workspace, Microsoft 365, Zoho, Proofpoint y más. También señalamos los dominios sin registro MX o con un Null MX que rechaza todo el correo.
Servidores de correo de
Proveedor de correo:
| Prioridad | Servidor de correo | Función | Proveedor |
|---|
Unos registros perfectos no evitan los rebotes. Enviar a direcciones inválidas, desechables o abandonadas daña tu reputación de remitente y puede meter tu IP en listas negras. Valida tu lista antes de la próxima campaña.
Un registro MX (mail exchanger) indica al resto de internet qué servidores aceptan correo para un dominio. Cuando alguien escribe a [email protected], su servidor de correo consulta los registros MX de ejemplo.com y entrega el mensaje a uno de los hosts que aparecen allí.
Cada registro MX tiene dos partes: una prioridad (un número) y un nombre de host, por ejemplo “10 mx1.ejemplo.net”. El nombre de host debe tener su propio registro A o AAAA: un MX no puede contener una dirección IP, y las RFC 2181 y RFC 5321 prohíben que apunte a un alias CNAME.
Los remitentes prueban primero el host con el número más bajo. Si no responde, pasan al siguiente. Los hosts con la misma prioridad reparten la carga y se eligen en orden aleatorio.
Los números en sí no significan nada más allá de su orden — 1/5/10 y 10/20/30 funcionan igual. Los servidores MX de respaldo, con un número mayor, deben aplicar las mismas reglas antispam que el principal; si no, los spammers los atacarán a propósito.
Definido en la RFC 7505 para dominios que nunca reciben correo. Los remitentes fallan de inmediato en lugar de reintentar durante días. Útil para dominios aparcados y dominios que solo envían.
Sin registro MX, la RFC 5321 indica a los remitentes que prueben la dirección A/AAAA del propio dominio. Es un comportamiento heredado: publica registros MX reales — o un Null MX — en lugar de depender de él.
No existe ningún registro de ningún tipo para el nombre. Las direcciones de esos dominios no pueden recibir correo y deberían eliminarse de tus listas.
Los nombres de los hosts MX revelan el proveedor: *.mail.protection.outlook.com es Microsoft 365, smtp.google.com y aspmx.l.google.com son Google, *.pphosted.com es Proofpoint, etc.
Cómo suelen ser los registros MX de los proveedores más habituales. Copia siempre los valores exactos desde la consola de administración de tu proveedor.
| Proveedor | Hosts MX habituales |
|---|---|
| Google Workspace | smtp.google.com · aspmx.l.google.com, alt1–alt4.aspmx.l.google.com |
| Microsoft 365 | yourdomain-com.mail.protection.outlook.com |
| Zoho Mail | mx.zoho.com, mx2.zoho.com, mx3.zoho.com · mx.zoho.eu … |
| Proton Mail | mail.protonmail.ch, mailsec.protonmail.ch |
| Fastmail | in1-smtp.messagingengine.com, in2-smtp.messagingengine.com |
| iCloud Mail | mx01.mail.icloud.com, mx02.mail.icloud.com |
| Hostinger | mx1.hostinger.com, mx2.hostinger.com |
| Locaweb | mx.*.locaweb.com.br |
| KingHost | *.kinghost.net |
| GoDaddy | smtp.secureserver.net, mailstore1.secureserver.net |
| IONOS | mx00.ionos.com, mx01.ionos.com · mx00.kundenserver.de |
| OVHcloud | mx1.mail.ovh.net … |
| Cloudflare Email Routing | route1.mx.cloudflare.net, route2…, route3… |
| Proofpoint | mx0a-XXXXXXXX.pphosted.com |
| Mimecast | us-smtp-inbound-1.mimecast.com, eu-smtp-inbound-1.mimecast.com … |
| Barracuda | dXXXXXXa.ess.barracudanetworks.com |
| Amazon SES (inbound) | inbound-smtp.<region>.amazonaws.com |
Sí. Puedes hacer 100 consultas al día sin cuenta (compartidas con la consulta DNS). La herramienta solo lee registros DNS públicos y no envía ningún email.
Es el orden en que los remitentes prueban los servidores: primero el número más bajo. Los números iguales reparten la carga. Un número mayor suele indicar un servidor de respaldo.
Los remitentes recurren a la dirección A o AAAA del dominio (“MX implícito”, RFC 5321). Si allí no escucha ningún servidor de correo, el mensaje rebota. A los dominios que no deben recibir correo les conviene publicar un Null MX.
Un único registro MX con prioridad 0 y host “.” (RFC 7505). Declara que el dominio no acepta ningún correo, así que los remitentes desisten de inmediato en lugar de reintentar.
No. Un MX debe apuntar a un nombre de host que tenga su propio registro A o AAAA. Algunos servidores toleran un CNAME, pero incumple el estándar y puede provocar fallos de entrega intermitentes.
Mira los nombres de los hosts MX — esta herramienta lo hace por ti. Por ejemplo, *.mail.protection.outlook.com significa Microsoft 365, y aspmx.l.google.com o smtp.google.com significan Google. Una pasarela de seguridad como Proofpoint o Mimecast puede ocultar el proveedor de buzones que hay detrás.
No. Solo demuestra que el dominio puede recibir correo. Si un buzón concreto existe es otra comprobación — usa el validador de email gratis para una dirección, o valida una lista entera con una cuenta gratis.
Lo que dure el TTL del registro anterior — a menudo 1 hora, a veces hasta 24 horas o más. Durante el cambio algunos mensajes pueden seguir llegando a los servidores antiguos, así que mantenlos activos uno o dos días.
Una cuenta gratis incluye 200 créditos (10 para emails de proveedores gratuitos) para validar listas de forma masiva, mediante la API REST o en tiempo real en tus formularios.
Crear cuenta gratis — 200 créditosSin tarjeta de crédito. Los créditos no caducan.