La idea de que un registro MX con preferencia 10 es el “servidor principal” y otro con preferencia 20 es el “de respaldo” circula en foros, tutoriales y conversaciones de soporte. Es una simplificación que se rompe en cuanto hay una caída real. El valor de preferencia MX es un entero de 16 bits, y los servidores remotos lo usan para construir una lista ordenada de destinos que solo recorren si el primero falla. No hay roles fijos, no hay sincronización entre hosts y no hay traspaso automático de estado. Entender esto cambia cómo se diseña la redundancia de correo entrante.
Qué declara un registro MX y qué no declara
Un registro MX indica qué hosts aceptan correo para el dominio y con qué prioridad relativa. Nada más. El formato es simple: preferencia, host y punto final. Un valor bajo significa “pruébame antes”; un valor alto significa “pruébame después”. El DNS no tiene ningún tipo de registro para activar catch-all ni para definir comportamiento de buzones: eso vive en el servidor de correo, no en la zona. Confundir ambos planos es el origen de la mayoría de errores de configuración.
Los registros MX tampoco dicen si un host está activo, si tiene espacio en disco o si acepta todas las direcciones del dominio. Un MX apunta a un nombre que debe resolver a su vez a un registro A o AAAA. Si ese nombre no resuelve, el destino se considera inalcanzable y el servidor remoto pasa al siguiente de la lista. Los registros MX no llevan peso, no llevan puerto y no llevan credenciales. Son una declaración de intenciones de enrutamiento.
La prioridad MX es, en la práctica, una lista de failover. Los servidores SMTP remotos ordenan los destinos de forma ascendente por preferencia y prueban el primero. Si responde con un código 4xx (fallo temporal) o 5xx (fallo permanente) a nivel de conexión, o si hay un timeout, se pasa al siguiente. Si el primero acepta el mensaje con un 250, los demás no se tocan. Esa es la diferencia entre un sistema de alta disponibilidad y una lista de reintentos.
Cómo se recorre la lista MX durante una caída
El matiz que casi nadie explica: el failover MX se activa a nivel de transporte, no a nivel de buzón. Si el servidor con preferencia 10 acepta la conexión SMTP pero luego responde 550 no such user para una dirección concreta, el servidor remoto no salta al MX con preferencia 20. El mensaje se rebota. La lista de failover solo se recorre cuando el destino no responde, rechaza la conexión o devuelve un error de transporte. Un rechazo de destinatario es una respuesta definitiva y se trata como tal.
Esto tiene consecuencias directas en el correo entrante. Un dominio con dos MX puede perder mensajes si el primario está arriba pero mal configurado. La solución no es añadir más MX: es asegurar que todos los hosts de la lista aceptan las mismas direcciones o que el primario delega correctamente. Los registros MX no son un mecanismo de alta disponibilidad de buzones, son un mecanismo de alta disponibilidad de transporte.
El orden ascendente también importa cuando hay más de dos destinos. Un dominio con preferencias 0, 10 y 20 no tiene “tres servidores primarios”: tiene una cadena de tres intentos. Si el 0 responde con un 4xx durante un mantenimiento, el remoto prueba el 10, y si ese también falla, el 20. Cada salto consume tiempo y puede agotar el plazo de reintento del servidor remoto. Por eso conviene que los MX de un mismo dominio estén en redes distintas y con latencias similares.
El caso del MX con preferencia 0 y el catch-all
Un MX con preferencia 0 y otro con preferencia 10 no forman un par primario/secundario en el sentido clásico. Forman una lista donde el 0 se intenta primero y el 10 solo se usa si el 0 no responde. qué es un correo catch-all explica esto con más detalle. Si el 0 está configurado con una regla catch-all que acepta cualquier mensaje enviado a un dominio, el 10 nunca recibirá tráfico mientras el 0 esté vivo. Eso puede ser deseable, pero también puede ocultar que el 10 tiene una configuración distinta y no está listo para asumir el tráfico.
La regla catch-all se aplica después de que falla la búsqueda normal de dirección. Es decir, el servidor primero comprueba si la parte local existe como buzón o alias; solo si no hay coincidencia, y si el catch-all está activo, entrega el mensaje al buzón comodín. Ese comportamiento es independiente de los registros MX. Un buzón catch-all se recoge con un solo login POP3 o IMAP, lo que simplifica la operación pero concentra el riesgo: si ese buzón se llena o se corrompe, se pierden todos los mensajes no coincidentes.
Failover real frente a redundancia aparente
Muchos paneles de hosting ofrecen “configurar correo catch-all” como una casilla y “añadir MX secundario” como otra, sin explicar que resuelven problemas distintos. El catch-all es un ajuste en el servidor de correo; el MX secundario es un ajuste en el DNS. El primero decide qué hacer con una dirección no coincidente; el segundo decide a qué host se conecta el remoto. Mezclarlos lleva a arquitecturas donde el failover nunca se prueba y el catch-all acumula correo que nadie lee.
Para que el failover sea real, los dos hosts MX deben compartir la misma base de usuarios o replicarla. Postfix, Exim y Dovecot permiten configurar backends compartidos (LDAP, SQL, ficheros replicados), pero eso no lo hace el DNS. Si el MX secundario tiene una lista de buzones distinta, cuando entre en juego rebotará direcciones que el primario aceptaba. El resultado es un failover que funciona a nivel de transporte y falla a nivel de negocio.
La autenticación de correo también se ve afectada. SPF, DKIM y DMARC rigen el correo saliente, no el entrante, pero un MX secundario que reenvía mensajes sin reescribir el sobre puede romper SPF y provocar rechazos en el destino final. Si el secundario actúa como relay, necesita su propia configuración de DKIM y una política DMARC coherente. Un failover mal diseñado no solo pierde correo entrante: también degrada la reputación del dominio.
Qué revisar antes de tocar la zona DNS
Antes de añadir o reordenar registros MX, conviene verificar que cada destino responde en el puerto 25, que su nombre resuelve a A y AAAA, y que acepta las direcciones del dominio. Una prueba con swaks o con un telnet manual al puerto 25 revela más que cualquier panel. También conviene comprobar la prioridad MX efectiva con una consulta directa al DNS autoritativo, no solo al resolutor del sistema, porque la caché puede mostrar una versión antigua de la zona.
- Verificar que cada host MX resuelve a A/AAAA y responde en el puerto 25.
- Comprobar que todos los hosts aceptan las mismas direcciones o que el primario delega.
- Revisar los tiempos TTL de la zona antes de un cambio de prioridad.
- Probar el failover real deteniendo el servicio en el MX de menor preferencia.
- Confirmar que el catch-all, si existe, está en el host correcto y con cuota suficiente.
- Documentar qué hace cada host ante un 550 no such user.
La prioridad MX no es un rol, es un orden. Un dominio con preferencias 0 y 10 no tiene primario y secundario: tiene un primer intento y un segundo intento que solo se usan si el primero falla a nivel de transporte. Diseñar la redundancia como si fuera un clúster activo-pasivo lleva a sorpresas durante las caídas. Diseñarla como una lista de failover, con hosts equivalentes y probados, es lo que mantiene el correo entrante en pie.
Si gestionas varios dominios, herramientas como allmail.one permiten revisar registros MX, SPF, DKIM y DMARC desde un solo panel y detectar incoherencias antes de que un remoto lo haga por ti. La comprobación periódica de la zona y de la respuesta SMTP de cada host evita que un failover teórico se convierta en un rebote real. El correo catch-all y los registros MX son piezas distintas del mismo sistema: trátalos como tales y el diagnóstico será mucho más rápido cuando algo falle.