MX: cómo funciona el correo

Tu sitio mitienda.com ya carga. Ahora el cliente quiere recibir correos en ventas@mitienda.com. Aquí es donde más gente se pierde, porque el correo no tiene nada que ver con el hosting de la página: viaja por otros servidores, con otros protocolos y lo dirige otro tipo de registro DNS, el MX.

En esta lección vas a entender el viaje completo de un correo, qué son MUA, MTA, SMTP, IMAP y POP3, cómo funcionan los registros MX y sus prioridades, y los errores que dejan a un negocio sin recibir correos (a veces durante días sin que nadie se dé cuenta).

Concepto

La analogía: el servicio postal

Correo postal	Correo electrónico	Nombre técnico
Tú escribes la carta	Escribes en Gmail, Outlook o el celular	MUA (Mail User Agent, el cliente de correo)
La dejas en la oficina de correos de tu colonia	Tu cliente la entrega al servidor de salida de tu proveedor	SMTP de envío (puerto 587)
Las oficinas de correos se pasan la carta	Servidor de salida → servidor del destinatario	MTA (Mail Transfer Agent) hablando SMTP (puerto 25)
La guía postal dice qué oficina atiende cada colonia	El DNS dice qué servidor recibe el correo de cada dominio	Registro MX
El cartero la deja en el buzón	El servidor la guarda en el buzón del usuario	MDA / buzón
Tú abres tu buzón	Tu app descarga o sincroniza los mensajes	IMAP o POP3

El viaje completo de un correo

Juan (juan@gmail.com) le escribe a ventas@mitienda.com, que usa Google Workspace:

 1. Juan escribe en la app de Gmail (MUA)
          │  SMTP envío (587, con usuario y contraseña)
          ▼
 2. Servidor de salida de Gmail (MTA de Juan)
          │
          │  3. Pregunta al DNS: "¿MX de mitienda.com?"
          │     ◄── "1 smtp.google.com"
          │  4. Pregunta al DNS: "¿A de smtp.google.com?"
          │     ◄── "142.250.x.x"
          │
          │  5. SMTP servidor a servidor (puerto 25)
          ▼
 6. smtp.google.com (MTA de Google Workspace que atiende mitienda.com)
          │  revisa SPF, DKIM, DMARC, antispam
          ▼
 7. Buzón de ventas@mitienda.com
          │  IMAP / app de Gmail / webmail
          ▼
 8. El vendedor lee el correo en su celular o computadora

Fíjate: en ningún momento aparece el hosting cPanel (203.0.113.10). El servidor de Juan solo preguntó por el MX.

Los protocolos en una tabla

Protocolo	Para qué	Puertos	Quién lo usa
SMTP (servidor a servidor)	Transportar correo entre dominios	25	MTA → MTA
SMTP Submission	Que tu app envíe correo a tu servidor	587 (STARTTLS) o 465 (TLS)	MUA → tu servidor
IMAP	Leer correo sincronizado (queda en el servidor)	993 (TLS)	MUA ↔ buzón
POP3	Descargar correo (normalmente se borra del servidor)	995 (TLS)	MUA ← buzón

IMAP sí, POP3 casi nunca

Configura siempre IMAP: el correo queda en el servidor y lo ves igual en el celular, la laptop y el webmail. Con POP3, si lo descargas en la computadora, puede desaparecer del celular, y si esa computadora se descompone, se pierde.

El registro MX

El MX (Mail eXchanger) dice: "el correo para este dominio entréguenlo en este servidor, con esta prioridad".

 Nombre          TTL   Tipo  Prioridad  Servidor de correo
 mitienda.com.   3600  MX    1          smtp.google.com.

Campo	Qué es
Nombre	Normalmente @ (correos algo@mitienda.com). Si quisieras algo@ventas.mitienda.com, el MX iría en ventas
Prioridad	Número: el menor se intenta primero
Servidor	Un nombre de host que debe tener registro A/AAAA. Nunca una IP y nunca un CNAME

Prioridades: el menor gana

Con varios MX, el servidor que envía prueba primero el de número más bajo. Si no responde, prueba el siguiente. Si dos tienen el mismo número, reparte entre ellos.

MX  10  mx.zoho.com.     ← 1º: se intenta primero
MX  20  mx2.zoho.com.    ← 2º: si el primero no responde
MX  50  mx3.zoho.com.    ← 3º: último recurso

Analogía: la lista de teléfonos de emergencia de una escuela: primero mamá (10), si no contesta papá (20), si no la abuela (50).

Los números no importan, el orden sí

10, 20, 50 funciona igual que 1, 2, 3. Lo que cuenta es cuál es menor. Copia exactamente los que te dé tu proveedor de correo.

Si el servidor destino está caído, el correo no se pierde (enseguida)

Si ningún MX responde, el servidor remitente reintenta durante horas o días (típicamente hasta 4–5 días) antes de devolver el correo como no entregado. Por eso un fallo corto del MX no suele perder correos; uno largo, sí.

MX de los proveedores más comunes

Valores al momento de escribir esto; copia siempre los que muestre el panel de tu proveedor:

Proveedor	Registros MX
Google Workspace (cuentas nuevas desde 2023)	1 smtp.google.com
Google Workspace (configuración antigua, también 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
Zoho Mail	10 mx.zoho.com, 20 mx2.zoho.com, 50 mx3.zoho.com (para cuentas de la región EU/IN los nombres cambian, p. ej. mx.zoho.eu)
Microsoft 365	0 mitienda-com.mail.protection.outlook.com (el nombre depende de tu dominio)
Cloudflare Email Routing	route1.mx.cloudflare.net, route2..., route3... (Cloudflare los crea solo)
Correo del hosting cPanel	0 mail.mitienda.com (con A mail → 203.0.113.10) o 0 mitienda.com

Por qué el sitio y el correo pueden estar en servidores distintos

Porque son registros distintos:

                      Zona de mitienda.com (Cloudflare)
          ┌──────────────────────┴───────────────────────┐
          │                                              │
   A   @   203.0.113.10                       MX  @  1 smtp.google.com
   CNAME www mitienda.com                     TXT @  v=spf1 include:_spf.google.com ~all
          │                                              │
          ▼                                              ▼
   Navegadores → hosting cPanel                Servidores de correo → Google Workspace
   (la página web)                             (los buzones)

• Los navegadores preguntan por A/AAAA/CNAME.
• Los servidores de correo preguntan por MX.

Nunca se cruzan. Por eso puedes:

• Cambiar de hosting sin tocar el correo (solo editas el A).
• Pasarte de correo del hosting a Google Workspace sin tocar la web (solo editas los MX y el SPF).

¿Correo en el hosting o aparte?

El correo incluido en el cPanel es "gratis", pero comparte IP con cientos de sitios (más riesgo de caer en spam), se pierde si cancelas el hosting y su antispam suele ser peor. Para un negocio, recomienda Google Workspace, Zoho Mail o Microsoft 365. Las opciones gratis y de pago se comparan en Correo con tu dominio.

¿Qué pasa si no hay MX?

Según el estándar (RFC 5321), si un dominio no tiene MX, el servidor remitente intenta entregar el correo en el registro A del dominio (el "MX implícito"). En nuestro caso, intentaría entregarlo a 203.0.113.10, el hosting.

Situación	Resultado
Hay MX válido	Se entrega en el MX
No hay MX, hay A, y el hosting sí acepta correo para el dominio	Puede llegar al hosting "por accidente" (confuso)
No hay MX y el servidor del A no acepta correo	El correo rebota o se queda reintentando
Con Cloudflare en naranja	Las IP de Cloudflare no reciben correo (puerto 25): el correo falla

Dominios que no deben recibir correo: Null MX

Si un dominio nunca debe recibir correo (por ejemplo, un dominio solo para redirigir), lo correcto es declararlo con un Null MX (RFC 7505):

MX   @   0   .

Prioridad 0 y destino . (punto). Así los remitentes saben al instante que no deben intentarlo. En Cloudflare, el destino se escribe como . en el campo Mail server (si el panel no lo acepta, déjalo sin MX). Combínalo con un SPF v=spf1 -all; lo verás en SPF.

Paso a paso: configurar MX en Cloudflare (Google Workspace)

Los menús cambian

La ruta descrita es la actual; el nombre exacto de algún botón puede variar ligeramente.

1. En dash.cloudflare.com, elige mitienda.com.
2. Ve a DNS → Records.
3. Borra los MX viejos que ya no uses (por ejemplo, los del hosting o del registrador). Mezclar MX de dos proveedores reparte tus correos entre ambos.
4. Add record:
   • Type: MX
   • Name: @
   • Mail server: smtp.google.com
   • Priority: 1
   • TTL: Auto
5. Save. Los registros MX no tienen nube naranja: siempre son "DNS only".
6. Agrega también el TXT de SPF (v=spf1 include:_spf.google.com ~all), DKIM y DMARC; los verás en SPF, DKIM y DMARC.
7. En la consola de Google Workspace, pulsa Activar Gmail / Verificar MX para que Google confirme la configuración.

Cloudflare te ayuda

En DNS → Records, Cloudflare a veces muestra avisos amarillos como "No MX records" o sugiere registros de correo. Léelos: muchas veces detectan exactamente el error que tienes.

Variante: correo en el hosting cPanel

Si el cliente quiere seguir usando el correo de cPanel con Cloudflare como DNS:

Tipo   Nombre   Valor                Prioridad   Proxy
---------------------------------------------------------
A      mail     203.0.113.10         —           DNS only (GRIS)  ← ¡obligatorio gris!
MX     @        mail.mitienda.com    0           —
TXT    @        "v=spf1 a mx ip4:203.0.113.10 ~all"

El error de la nube naranja en mail

Si mail.mitienda.com está en naranja, apunta a Cloudflare, y Cloudflare no transporta correo (solo tráfico web). El MX apuntará a un servidor que no recibe correo y todo rebota. Los nombres usados por el correo (mail, smtp, imap, pop, webmail si es por puerto directo) van en gris.

Comprobar MX

Linux / macOS

# MX del dominio (prioridad y servidor)
dig +short mitienda.com MX
# 1 smtp.google.com.

# Que el servidor de correo tenga IP (debe responder A/AAAA, no CNAME)
dig +short smtp.google.com A

# Directo al autoritativo
dig @ana.ns.cloudflare.com mitienda.com MX +short

Windows

nslookup -type=MX mitienda.com 1.1.1.1
# mitienda.com  MX preference = 1, mail exchanger = smtp.google.com

nslookup -type=MX mitienda.com ana.ns.cloudflare.com

Resolve-DnsName mitienda.com -Type MX

Herramientas web: MXToolbox (MX Lookup y "Email Health"), la Caja de herramientas de Google Admin (Check MX) y la herramienta DNS del curso.

La prueba definitiva

Después de configurar, envía un correo real desde una cuenta externa (un Gmail personal) a ventas@mitienda.com y responde desde esa cuenta. Así compruebas la ida (MX) y la vuelta (SPF/DKIM). Si el correo llega a spam, revisa las lecciones de autenticación.

Errores comunes

1. MX apuntando a una IP

✘ MX  @  10  203.0.113.10
✔ A   mail  203.0.113.10
  MX  @  10  mail.mitienda.com

El valor de un MX debe ser un nombre. Cloudflare no te deja guardar una IP, pero otros paneles sí, y muchos servidores lo rechazan.

2. MX apuntando a un CNAME

✘ CNAME correo  ghs.googlehosted.com
  MX    @       10 correo.mitienda.com     ← el destino es un CNAME

El estándar prohíbe que el destino de un MX sea un alias. Algunos servidores lo toleran y otros no, lo que produce fallos intermitentes muy difíciles de diagnosticar. El destino del MX debe tener A/AAAA directamente.

3. Olvidar los MX al mover los nameservers a Cloudflare

El clásico del curso. El cliente tenía NS del hosting, con MX configurados ahí. Pasas los NS a Cloudflare, el escaneo automático no importó los MX (o los importó mal), y desde ese momento los correos dejan de llegar. Nadie se queja hasta 3 días después: "oye, no me han llegado pedidos".

Prevención: haz el inventario de la lección 3 y comprueba dig MX antes y después del cambio.

4. Mezclar MX de dos proveedores

MX  @  0   mail.mitienda.com     ← hosting viejo
MX  @  1   smtp.google.com       ← Google nuevo

El correo irá al hosting (prioridad más baja) y Google no recibirá casi nada. O si tuvieran el mismo número, se repartiría al azar. Al migrar, deja solo los MX del proveedor actual.

5. Nube naranja en el host de correo

Ya lo viste: mail, smtp, imap, pop siempre en gris.

6. "Edité los MX en cPanel y nada"

Si los NS son de Cloudflare, la zona del cPanel no cuenta. Además, cPanel tiene una opción Email Routing (Enrutamiento de correo) en Correo electrónico → Email Routing que debe estar en Remote Mail Exchanger cuando el correo está en Google/Zoho; si la dejas en "Local", los correos enviados desde el propio hosting (por ejemplo, el formulario de contacto de WordPress) se quedarán en un buzón local que nadie revisa.

Ese último es muy traicionero

Todo el mundo recibe correo bien en Google Workspace... excepto los avisos del formulario de la web, porque el servidor cPanel cree que ventas@mitienda.com es local y los entrega en su propio buzón. Solución: en cPanel, Email Routing → Remote Mail Exchanger para mitienda.com.

Ejercicios

1. Explica con tus palabras la diferencia entre SMTP, IMAP y POP3.
2. Con dig o nslookup, consulta los MX de gmail.com y de outlook.com. ¿Cuál tiene más de uno? ¿Qué prioridades usan?
3. Escribe los registros MX y el A necesario para recibir correo de Zoho Mail en mitienda.com sin romper el sitio en 203.0.113.10.
4. Tienes estos registros. Encuentra los 3 errores:

A      mail   203.0.113.10        Proxied (naranja)
MX     @      0  203.0.113.10
CNAME  smtp   mail.mitienda.com
MX     @      5  smtp.mitienda.com

5. Tu cliente cambió los NS a Cloudflare ayer y hoy dice que no le llegan correos. ¿Qué revisas y en qué orden?
6. Un dominio mitienda-promo.com solo redirige a mitienda.com y nunca debe recibir correo. ¿Qué registros de correo le pones?

Ver solución

1. SMTP transporta y envía correo (de tu app al servidor por 587/465, y entre servidores por 25). IMAP sirve para leerlo sincronizado: queda en el servidor y se ve igual en todos tus dispositivos. POP3 lo descarga a un dispositivo y normalmente lo borra del servidor.
2. dig +short gmail.com MX devuelve varios (5 gmail-smtp-in.l.google.com, 10 alt1..., etc.). outlook.com suele devolver uno o varios *.mail.protection.outlook.com. Los valores pueden cambiar con el tiempo.
3. Registros (el sitio sigue en su A, no se toca):

A    @   203.0.113.10
MX   @   10  mx.zoho.com
MX   @   20  mx2.zoho.com
MX   @   50  mx3.zoho.com
TXT  @   "v=spf1 include:zoho.com ~all"

No se necesita ningún A para el correo porque los MX apuntan a servidores de Zoho que ya tienen sus propios A.

4. Errores: (1) mail está en naranja: Cloudflare no transporta correo, debe ir en gris. (2) El primer MX apunta a una IP: debe ser un nombre (mail.mitienda.com). (3) El segundo MX apunta a smtp.mitienda.com, que es un CNAME: el destino de un MX debe tener A/AAAA directo. Corrección:

A    mail   203.0.113.10     DNS only (gris)
MX   @      0  mail.mitienda.com

5. Orden: (a) dig +short NS mitienda.com para confirmar que ya manda Cloudflare; (b) dig +short mitienda.com MX y comparar con lo que pide el proveedor de correo; (c) si faltan, crearlos en Cloudflare → DNS → Records; (d) revisar que los hosts de correo estén en gris; (e) revisar SPF/DKIM; (f) enviar un correo de prueba desde Gmail. Los correos de las últimas horas probablemente siguen en reintento en los servidores remitentes y llegarán solos.
6. Null MX y SPF que prohíbe todo:

MX   @   0  .
TXT  @   "v=spf1 -all"

Resumen

• El correo viaja MUA → SMTP → MTA → MX del destino → buzón → IMAP/POP3; el hosting web no participa.
• El MX dice qué servidor recibe el correo del dominio; menor prioridad = se intenta primero.
• El destino de un MX es un nombre con A/AAAA: nunca una IP, nunca un CNAME.
• Sitio y correo son registros distintos, por eso pueden estar en empresas distintas.
• Sin MX se usa el A como respaldo; para dominios sin correo usa Null MX (0 .).
• En Cloudflare, los hosts de correo (mail, smtp...) van en gris; los MX nunca se proxean.
• Al mover nameservers, copia los MX (y SPF, DKIM, DMARC) antes del cambio y comprueba con dig MX / nslookup -type=MX.
• Siguiente: TXT y verificaciones.