Recepción de correo: adónde llega lo que le escriben

Los registros MX dicen a qué servidor entregar el correo de su dominio. Cómo se leen, qué falla en la práctica y por qué un dominio sin buzones también necesita atención.

Los registros MX son la dirección postal de su dominio. Cuando alguien escribe a hola@ejemplo.es, su servidor pregunta al DNS a qué máquina hay que entregar el mensaje, y la respuesta son los MX. Sin ellos no hay entrega: el mensaje rebota con un error y el remitente recibe un aviso.

Es la parte menos vistosa de esta comprobación y la que produce los fallos más caros, porque cuando algo va mal aquí no se degrada nada: simplemente no llega el correo. También es donde aparece un caso que casi nadie trata, el del dominio que no tiene buzones —solo una web, o nada en absoluto— y que por eso mismo es cómodo de suplantar.

Cómo son los registros

Un dominio puede tener varios MX. Cada uno lleva un número de prioridad: cuanto más bajo, antes se intenta.

ejemplo.es.  IN  MX  10 mail.ejemplo.es.
ejemplo.es.  IN  MX  20 respaldo.ejemplo.es.

Con Microsoft 365 hay un único MX con la forma ejemplo-es.mail.protection.outlook.com. Google Workspace usa hoy un único registro, smtp.google.com, en lugar de los cinco aspmx de años atrás. Los hosting españoles suelen dar uno o dos nombres propios, del estilo mail.sudominio.es.

Hay un caso especial que merece la pena conocer: el MX nulo.

ejemplo.es.  IN  MX  0 .

Un solo registro con prioridad 0 y un punto como destino significa, de forma expresa: este dominio no recibe correo. No es un error ni un descuido, es la declaración correcta para un dominio que solo sostiene una web o que está aparcado. El remitente lo entiende y rechaza el mensaje de inmediato, en lugar de reintentar durante días.

Lo que se rompe en la práctica

Casi todos los fallos de esta sección vienen de tres situaciones:

• Una migración a medias. Se traslada el correo a Microsoft 365 o a Google Workspace, se añaden los MX nuevos y se dejan los viejos. Como el servidor antiguo sigue respondiendo, una parte del correo se entrega en un buzón que ya nadie mira.
• Un cambio de proveedor de DNS. La zona se recrea en otro sitio y alguien copia los registros a mano. Los MX se copian; los TXT, a veces no.
• Comodidad. Se apunta el MX a un alias o a una dirección IP porque «así también funciona». Funciona con la mayoría de remitentes y falla con los estrictos, que son justo los proveedores grandes.

Cómo se configura

Los MX se editan en el panel donde estén los servidores de nombres del dominio. Si el correo está en Microsoft 365 pero el dominio en Dinahosting, los registros se escriben en Dinahosting.

Paso a paso en Dinahosting

1. Panel → Dominios → su dominio → Gestión DNS.
2. Revise los registros MX existentes. Antes de añadir nada, decida cuáles sobran: los de una migración anterior se borran, no se dejan con prioridad alta.
3. Añada el registro del proveedor nuevo con la prioridad que él indique.
4. Si su proveedor le da un segundo servidor, añádalo con un número mayor.
5. Guarde y compruebe. Un cambio de MX se nota en minutos u horas según el TTL anterior; durante ese tiempo puede llegar correo a los dos sitios.
6. Si el dominio no debe recibir correo, ponga en su lugar un único registro MX con prioridad 0 y destino ..

Los hallazgos, uno por uno

Ningún servidor de correo configurado

El dominio no tiene ningún registro MX, y tampoco el MX nulo que declararía que no quiere recibir.

Importa porque no se puede entregar correo. Algunos remitentes recurren entonces a la dirección del servidor web —es una regla antigua que todavía se aplica— y el mensaje acaba en una máquina que no tiene buzones. El resto rebota.

Qué hacer. Si el dominio debe recibir correo, publique los MX de su proveedor de buzones. Si no debe recibir, publique el MX nulo: un solo registro, prioridad 0, destino ., y ponga el DMARC en p=reject. Las dos opciones son correctas; lo que no es correcto es dejarlo en blanco.

Un solo servidor de correo

Solo hay un MX, o varios que apuntan al mismo nombre.

Conviene ponerlo en su sitio: no es un fallo. Si ese servidor se cae, los remitentes reintentan durante días —lo habitual son cuatro— así que rara vez se pierde nada; lo que hay es retraso. Y muchos proveedores grandes dan deliberadamente un único nombre que por dentro es un grupo de servidores repartidos, con lo que la redundancia ya existe aunque no se vea.

Qué hacer. Normalmente nada. Si su proveedor ofrece un segundo servidor de entrada, añádalo con un número de prioridad mayor. Si su MX es de Microsoft 365 o Google Workspace, deje el registro tal como lo indica el proveedor.

El MX apunta a una dirección IP

El destino del registro MX es una dirección IP en lugar de un nombre de servidor.

Importa porque el estándar exige un nombre. Los remitentes estrictos rechazan el registro, y con él la entrega; otros lo aceptan. El resultado es lo peor de los dos mundos: funciona lo suficiente como para que nadie lo revise y falla con una parte de los remitentes.

Qué hacer. Cree un nombre —por ejemplo mail.ejemplo.es— con un registro A o AAAA que apunte a esa dirección, y ponga ese nombre en el MX. De paso queda preparado para cambiar de servidor sin tocar el MX.

El MX apunta a un alias

El nombre del MX es a su vez un alias (CNAME) que remite a otro nombre.

Importa porque el estándar lo prohíbe expresamente. Buena parte de los servidores emisores resuelve el alias igualmente, pero otros interrumpen la entrega, y los que lo hacen no siempre avisan de por qué. Es un fallo intermitente y difícil de diagnosticar desde dentro.

Qué hacer. Averigüe a qué nombre lleva el alias y póngalo directamente en el MX. Si lo que quería era poder cambiar el destino en un solo sitio, use un registro A o AAAA propio en lugar de un CNAME.

El servidor de correo no resuelve

El nombre indicado en el MX existe como registro, pero no tiene dirección IPv4 ni IPv6.

Importa porque nadie puede entregar ahí. El remitente busca la dirección, no la encuentra y devuelve el mensaje. Es de los pocos fallos de esta lista que se nota enseguida, porque afecta a todo el correo entrante.

Qué hacer. Revise primero la escritura del nombre: un punto de más, una letra cambiada o el dominio repetido dos veces son las causas más frecuentes. Si el nombre es correcto, falta el registro A o AAAA: publíquelo con la dirección de su servidor de correo.

Servidor de correo sin resolución inversa

La dirección IP de su servidor de correo no tiene registro PTR, es decir, no se puede pasar de la dirección al nombre.

Importa poco para recibir y bastante para enviar, si envía desde esa misma máquina. Muchos destinatarios rechazan o puntúan mal las conexiones de direcciones sin resolución inversa, y es de los criterios más antiguos y más aplicados que hay. Si su correo saliente pasa por el proveedor de buzones y no por este servidor, el hallazgo es informativo.

Qué hacer. El PTR no se publica en su zona DNS: lo configura quien le asigna la dirección IP, es decir, su proveedor de servidor o de nube. Pídaselo indicando la dirección y el nombre al que debe apuntar, que tiene que ser el mismo con el que el servidor se presenta al enviar.

Dominio sin buzones, aún suplantable

El dominio declara con un MX nulo que no recibe correo, pero su SPF no es estricto: no termina en -all o no existe.

Importa porque una cosa es recibir y otra enviar. Un dominio que ha renunciado a recibir sigue siendo un remitente perfectamente utilizable para un tercero, y además uno que nadie vigila: los rebotes no llegan a ninguna parte y las quejas tampoco.

Qué hacer. Publique v=spf1 -all en ese dominio. Es el registro más corto posible y significa: ningún servidor está autorizado a enviar en mi nombre. Si el dominio sí envía algo —avisos de una web, por ejemplo— entonces no es un dominio sin uso y necesita un SPF normal.

Dominio sin buzones y sin rechazo DMARC

El dominio tiene MX nulo, pero su DMARC no está en p=reject.

Importa porque el SPF estricto indica que el mensaje no está autorizado y DMARC es lo que convierte eso en una consecuencia. Sin p=reject, cada receptor decide por su cuenta qué hacer con una falsificación, y muchos deciden entregarla.

Qué hacer. Publique v=DMARC1; p=reject; en _dmarc de ese dominio. Puede añadir una dirección rua si quiere ver los intentos; en un dominio sin uso suele ser informativo y no molesta.

Sin servidores y sin declaración clara

El dominio no tiene MX, tampoco MX nulo, y su DMARC no está en p=reject. No dice ni que recibe ni que no recibe.

Importa porque esa ambigüedad la resuelve cada remitente a su manera. Algunos recurren a la dirección del servidor web y entregan ahí; otros reintentan durante días antes de rendirse. Y mientras tanto el dominio sigue siendo un remitente falsificable sin ninguna resistencia.

Qué hacer. Decida qué es este dominio. Si tiene que recibir correo, publique los MX de su proveedor. Si no, ciérrelo del todo: MX nulo, v=spf1 -all y v=DMARC1; p=reject;. Diez minutos por dominio, y vale la pena repasar todos los que tenga registrados.

Preguntas frecuentes

Cambié los MX y sigue llegando correo al servidor antiguo.

Es normal durante un tiempo. Los servidores remitentes guardan la respuesta del DNS el tiempo que indique el TTL, y algunos más. Deje el buzón antiguo accesible unos días después del cambio, y revise que no haya quedado ningún MX viejo con prioridad alta, porque entonces no es la caché: es su propia zona.

¿Necesito un segundo MX de respaldo?

Casi nunca. Los remitentes reintentan durante días, así que un corte del servidor principal produce retraso, no pérdida. Un MX de respaldo mal montado, en cambio, puede acabar aceptando correo que luego no sabe entregar.

Tengo diez dominios y solo uso uno. ¿Qué hago con los otros nueve?

Ciérrelos: MX nulo, v=spf1 -all y v=DMARC1; p=reject; en cada uno. Es la medida con mejor relación entre esfuerzo y efecto de toda esta comprobación, y no afecta a nada de lo que esté en marcha.

¿Comprueban ustedes si mi servidor acepta correo de verdad?

No. Medimos el DNS: los registros MX, si los nombres resuelven y si tienen resolución inversa. No abrimos una conexión SMTP contra su servidor, porque el envío saliente está cerrado en el servidor de pruebas. Lo que no medimos aparece en el informe como no medible, no como correcto. También lo explicamos en cifrado en el transporte.