Registros MX y prioridad

Módulo 4: Registros para el correo electrónico · Tiempo de lectura: 8 minutos

Objetivo de aprendizaje: Después de esta lección podrá leer y configurar registros MX, elegir bien la prioridad y explicar qué ocurre si un dominio no tiene registro MX.

Conceptos clave: registro MX, prioridad (preference), MX de respaldo, servidor de correo (nombre de host), MX implícito, null MX, entrega local

¿Adónde debe ir el correo?

Si alguien envía un correo a info@example.com, el servidor de correo del remitente debe averiguar a qué servidor debe entregarse ese correo. Esto lo busca en el DNS, consultando el registro MX (Mail eXchanger) de example.com.

La respuesta no es una dirección IP, sino una lista de servidores de correo, cada uno con un número delante:

example.com.   3600  IN  MX  10 mail.example.com.
example.com.   3600  IN  MX  20 backup.example.net.

Después, el servidor remitente consulta el registro A o AAAA de mail.example.com, y solo entonces sabe a qué dirección IP debe llamar. Un registro MX siempre apunta a un nombre, que a su vez tiene su propio registro A o AAAA.

El registro MX casi siempre está en el propio dominio (@), porque se refiere a la parte que va después de la @ en la dirección de correo. Si quiere recibir correo en info@nieuws.example.com, entonces nieuws.example.com necesita su propio registro MX.

Prioridad: el número más bajo va primero

El número delante del servidor de correo se llama prioridad (en el estándar, RFC 5321, se llama preference). La regla es simple:

• Cuanto más bajo sea el número, antes le toca el turno a ese servidor.
• Si ese servidor no está disponible, el remitente prueba con el siguiente.
• Si dos servidores tienen el mismo número, el remitente reparte el correo de forma aleatoria entre ambos. Así puede repartir la carga.

El número en sí no significa nada. 0, 1, 5, 10 o 100: solo cuenta el orden. Un registro con prioridad 10 y otro con 20 funciona exactamente igual que 1 y 2. Si su proveedor de correo indica un número, utilícelo tal cual. Si solo indica un servidor, el número no importa.

A un servidor con un número más alto solemos llamarlo MX de respaldo. Antes era habitual: si su propio servidor fallaba, el respaldo guardaba el correo. Hoy en día, un servidor remitente guarda el correo él mismo durante unos días y vuelve a intentarlo. Un MX de respaldo mal configurado (por ejemplo, sin filtro antispam) atrae precisamente spam. Úselo solo si su proveedor lo indica así.

Reglas para un buen registro MX

1. Un nombre, no una dirección IP. MX 10 192.0.2.25 no es válido. Cree un registro A mail con 192.0.2.25 y haga que el MX apunte a mail.example.com.
2. No hacia un CNAME. El nombre de un registro MX debe tener su propio registro A o AAAA, no un CNAME (RFC 2181, apartado 10.3). Muchos servidores lo resuelven igualmente, pero no todos.
3. El punto al final. En muchos paneles escribe mail.example.com. con un punto. Sin el punto, el panel añade de nuevo su dominio al final: mail.example.com.example.com. Ese nombre no existe, y su correo no llegará.
4. El servidor de correo debe existir. Si el MX apunta a un nombre sin registro A o AAAA, no llega nada. Esto se ve con frecuencia en la práctica cuando alguien traslada los servidores de nombres de su dominio a un constructor de sitios web: el registro MX se traslada, pero el registro A de mail no.
5. Elimine los registros antiguos. Si cambia a otro proveedor de correo, elimine los registros MX del proveedor anterior. Si los deja, parte de su correo seguirá llegando al proveedor anterior.

Sin registro MX: MX implícito y null MX

¿Qué ocurre si un dominio no tiene ningún registro MX? Según el RFC 5321, el servidor remitente prueba entonces el registro A o AAAA del propio dominio. Esto se llama el MX implícito. Si su sitio web está en un servidor sin correo, el mundo intentará entregar su correo en su servidor web. Esto provoca retrasos y mensajes de error en el remitente.

Si quiere dejar claro que un dominio nunca recibe correo, use un null MX (RFC 7505):

example.net.  3600  IN  MX  0 .

Prioridad 0 y como servidor de correo solo un punto. Un remitente ve entonces de inmediato que no tiene que intentarlo y envía directamente al remitente un mensaje de error claro. Combine esto con un registro SPF v=spf1 -all (lección 4.3) si el dominio tampoco envía correo.

Entrega local: la trampa en el hosting con correo

Muchos paquetes de hosting tienen un servidor web y un servidor de correo en una misma máquina. Ese servidor piensa por defecto: "el correo de este dominio lo entrego yo mismo". Si traslada su correo a otro proveedor, cambia los registros MX, pero el servidor no lo recuerda automáticamente. Resultado: el correo de su propio formulario de contacto, y de otros sitios web en el mismo servidor, se queda colgado en el servidor antiguo y nunca llega a su nuevo proveedor. El remitente a veces recibe de vuelta 550 Unknown user.

Esta pregunta la reciben muy a menudo las empresas de hosting. Por eso, en la mayoría de los paneles hay un interruptor con un nombre como "Usar este servidor para gestionar mis correos electrónicos" o "Entrega local de correo". ¿Traslada su correo a otro proveedor? Cambie el MX y desactive ese interruptor. Si solo hace una de las dos cosas, algo saldrá mal.

En la práctica: así se ve en un panel

En este ejemplo usamos DirectAdmin. En Gestor de E-Mail, Registros MX verá los registros MX de su dominio. En cada registro escribe la prioridad en una casilla y el servidor de correo a continuación, con un punto al final. Debajo está la casilla de verificación Usar este servidor para gestionar mis correos electrónicos. En Plantilla MX puede elegir configuraciones ya preparadas, por ejemplo para Microsoft 365 o Google Workspace.

En Mi WebOké encontrará lo mismo en la pestaña DNS de un dominio; allí el interruptor se llama Entrega.

En cPanel, Plesk, Cloudflare o en su registrador la pantalla se ve distinta, pero siempre rellena los mismos tres datos: el nombre (@ o vacío), la prioridad y el servidor de correo.

Resumen

• El registro MX indica adónde debe ir el correo de su dominio. Apunta a un nombre, nunca a una dirección IP ni a un CNAME.
• La prioridad más baja va primero; los números iguales se reparten el correo; el número en sí no significa nada.
• Sin MX, el mundo prueba su registro A (MX implícito). Si nunca recibe correo, use MX 0 . (null MX).
• Si traslada su correo, elimine los registros MX antiguos y desactive la entrega local en su servidor de hosting.

Cuestionario

Ejercicio

Ejercicio Z4.1: Buscar el MX. Busque los registros MX de wikipedia.org (o de su propio dominio). Indique qué servidor de correo tiene el número de prioridad más bajo, y cuál es ese número.

Ejercicio O4.1: Configúrelo usted mismo en su zona de práctica. Cree en su zona de práctica <code>.dnspractice.eu dos registros MX: prioridad 10 hacia mail.<code>.dnspractice.eu y prioridad 20 hacia backup.<code>.dnspractice.eu. Cree para ambos nombres un registro A: mail hacia 192.0.2.25 y backup hacia 192.0.2.26. Después haga clic en Comprobar.

Más información

Los pasos de estos artículos corresponden a los paneles de WebOké; en otros paneles funciona de forma parecida.

• Manual de DirectAdmin 5.5: Registros MX: ¿dónde llega su correo electrónico?
• Su correo electrónico en otro lugar: Microsoft 365, Google Workspace o un servidor de correo propio
• No se puede enviar correo desde PHP: los registros MX apuntan a otro lugar
• Manual de DirectAdmin 18.9: Ya no recibo correo electrónico
• RFC 5321 apartado 5.1 (enrutamiento de correo), RFC 7505 (null MX)