Correo: Registros MX múltiples — cómo funciona realmente la prioridad (y errores comunes)

enero 15, 2026 • febrero 3, 2026 • Lectura: 26 min • Views: 4

¿Te fue útil?

Cambiaste los registros MX para “añadir redundancia”, te fuiste a casa y amaneciste con una avalancha de tickets:
algunos remitentes no pueden entregar, otros lo hacen con lentitud, y algunos mensajes rebotan con errores que parecen una novela de Kafka.
El sistema de correo está “arriba”, pero la entrega no es un estado binario. Es un proceso negociado entre DNS, clientes SMTP, políticas y tiempo.

Los registros MX múltiples son uno de esos controles que parecen sencillos pero que manejan silenciosamente quién se comunica contigo, cuándo y con cuánta insistencia lo intentarán.
La “prioridad” es real, pero no del modo en que mucha gente la asume. Si la tratas como un conmutador activo/standby limpio, te castigará.

Prioridad MX: qué significa realmente (y qué no significa)

Un registro MX indica: “Para este dominio, aquí están los nombres de host que aceptan correo SMTP, y aquí hay una preferencia de ordenación.”
El valor numérico se llama preference (a menudo coloquialmente “prioridad”). Los números más bajos son preferidos. Esa es la parte que todos recuerdan.
La parte que todos olvidan: los remitentes SMTP no están obligados a hacer lo que tú deseas; siguen estándares y sus propias políticas operativas.

La preferencia MX no es una comprobación de salud.
No demuestra que el servidor sea accesible, esté configurado, autorizado o listo.
Tampoco garantiza que un remitente intentará primero el de menor prioridad si la caché local o la política dicen otra cosa.
Es una pista. Una buena pista. Pero sigue siendo una pista.

El significado práctico de los registros MX múltiples es este:

La preferencia menor se intenta primero en el caso normal.
La preferencia mayor se intenta si la menor falla (conexión rechazada, timeout, 4xx, etc.), y entonces los remitentes suelen encolar y volver a intentar más tarde.
Preferencias iguales implican reparto de carga (no garantizado uniforme, pero esa es la intención).
La conmutación por error es probabilística y basada en el tiempo: depende de la rapidez con que ocurran fallos, cuánto persistan las colas y cómo se comporten los horarios de reintento.

Piensa en la preferencia MX como una política de enrutamiento para el software de otros, ejecutada en su propio calendario.
Es menos como un semáforo y más como un conjunto de señales de tráfico en otra ciudad.

Dos reglas que salvan carreras

Si un nombre de host está en MX, debe poder aceptar correo para el dominio (y gestionarlo correctamente), o te estás apuntando a pérdidas, retrasos y rebotes nondeterministas.
Nunca publiques un objetivo MX que no puedas monitorizar y operar.
“Es solo una copia de seguridad” es cómo consigues retransmisiones de spam sorpresa, caídas sorpresa y conversaciones legales sorpresa.

Una cita, un chequeo de realidad

Idea parafraseada (a menudo atribuida al pensamiento de fiabilidad de sistemas): La esperanza no es una estrategia; el diseño y la verificación sí lo son.
Esa es la mentalidad que quieres cuando publicas DNS que influye en la entrega de correo a nivel global.

El algoritmo de selección: cómo los remitentes eligen entre los objetivos MX

Aquí está el algoritmo simplificado que la mayoría de los clientes SMTP siguen, basado en el comportamiento estándar:

Consultar los registros MX para el dominio del destinatario.
Si no existen, retroceder a una búsqueda A/AAAA en el propio dominio (sí, aún es común).
Ordenar los destinos MX por preferencia creciente (número más bajo primero).
Para destinos con la misma preferencia, aleatorizar o rotar el orden.
Para cada destino en orden:
- Resolver A/AAAA para los nombres MX.
- Intentar la entrega a una de las IP resueltas (la política varía: algunos prueban todas, otros eligen una, otros prefieren IPv6).
- Si la entrega falla con un error transitorio, continuar al siguiente destino o encolar y reintentar más tarde.
- Si la entrega falla permanentemente (5xx), generar un rebote.

Ese es el camino feliz. En producción es donde se pone interesante:

La caché DNS significa que un remitente puede seguir usando respuestas MX antiguas más tiempo del esperado, dependiendo del TTL y del comportamiento del resolutor.
La política local puede anular tu diseño: algunos proveedores grandes tratan ciertos rangos IP de forma diferente, o hacen enrutamiento “pegajoso” para reducir churn de conexiones.
Los fallos a nivel de conexión no son iguales: un “connection refused” rápido provoca un fallback inmediato; un timeout consume segundos y puede bloquear el rendimiento de la cola.
El greylisting y la limitación de tasa pueden convertir a tu “backup” en un imán de reintentos lentos.

Si quieres una conmutación por error nítida, solo con MX no la tendrás. Te da entrega eventual bajo condiciones razonables.
Si necesitas enrutamiento determinista, estás en el terreno de la gestión de tráfico frente a SMTP (o usar un servicio de correo que lo proporcione).

Broma #1: La prioridad MX es como un organigrama. Parece autoritaria hasta que ves cómo se toman las decisiones realmente.

Datos interesantes y contexto histórico

El correo es más antiguo que la mayoría de tu pila de monitorización y conserva comportamientos legacy que aún importan.
Aquí hechos concretos que explican por qué “solo añade otro MX” rara vez es “solo”.

Los registros MX se introdujeron para desacoplar el enrutamiento de correo de los nombres de host. El enrutamiento temprano dependía mucho de tablas de hosts y direcciones directas; MX lo hizo más flexible.
La preferencia MX es intencionadamente simple. Es un mecanismo de ordenación, no un marco de pesos y salud como los balanceadores modernos.
La caída a A/AAAA cuando falta MX sigue siendo comportamiento común. Por eso los dominios “sin www” a veces “reciben correo” accidentalmente.
Algunos remitentes tratan MX de igual preferencia como un conjunto rotativo. La meta es distribución, pero la distribución real depende de la implementación y la caché.
El “backup MX” solía ser un patrón común. Almacenar y reenviar tenía sentido cuando los enlaces eran inestables; hoy suele ser una responsabilidad a menos que se controle cuidadosamente.
SMTP está diseñado en torno a reintentos. Los fallos temporales son esperados; las colas y el backoff son características, no errores.
STARTTLS oportunista cambió lo que significa “alcanzable”. Un servidor puede aceptar TCP/25 pero aún fallar la política de entrega si TLS o la comprobación de certificados son exigidos por el remitente.
La adopción de IPv6 introdujo nuevas asimetrías. Un remitente puede preferir IPv6, y tu ruta v6 puede estar “arriba” en enrutamiento pero “caída” en la realidad (firewalls, DNS inverso, reputación).
Los proveedores grandes aplican comportamientos más allá de los estándares base. La limitación, la reputación y las heurísticas pueden dominar lo que experimentas como “entrega”.

Dónde fallan los diseños multi-MX en producción

La suposición seductora y equivocada: “Número mayor significa standby”

La gente publica MX 10 para el primario, MX 20 para el standby, y asume que el standby solo se usará cuando el primario esté caído.
Eso no está garantizado. “Caído” es ambiguo: ¿inaccesible? ¿rechazando? ¿lento? ¿4xx intermitente? ¿DNS obsoleto? ¿IPv6 roto?
Muchos remitentes intentarán el secundario si el primario está simplemente lento o falla intermitentemente.

Entonces tu standby se convierte en una vía de entrada de producción sin el endurecimiento de producción.
Puede que no tenga la configuración TLS correcta, o esté en una ruta de filtrado diferente, o no esté autorizado a enviar rebotes correctamente.

Preferencia igual como “balanceo” sin simetría

Si publicas dos MX con la misma preferencia, invitas a la distribución de carga.
Eso está bien solo si ambos endpoints son operacionalmente idénticos desde la perspectiva SMTP:
misma postura anti-spam, mismos límites de tasa, misma política TLS, misma identidad del banner, mismo enrutamiento interno, misma capacidad para aceptar para todos los destinatarios.

En el mundo real, un nodo es un poco más viejo, un poco mal configurado, un poco menos monitorizado.
Adivina de dónde vienen la mayoría de tus rebotes raros.

El “backup MX” que acepta para todo se convierte en un sumidero de spam

Modo de fallo clásico: el backup MX acepta correo para dominios que al final no entrega, porque está configurado para aceptar entradas sin validación.
No un relay abierto en el sentido obvio de “enviar a cualquier sitio”, sino en el sentido de “aceptar para cualquier destinatario en tiempo de SMTP y luego fallar más tarde”.
A los spammers les encanta eso porque oculta la validez de destinatarios y traslada el dolor a tu cola.

Si tu backup MX no tiene validación de destinatarios (o no puede realizarla porque no tiene acceso al directorio), debe configurarse con extremo cuidado.
De lo contrario estás construyendo una responsabilidad con excelente tiempo de actividad.

Errores de DNS: MX apuntando a IPs, CNAMEs o nombres rotos

Los objetivos MX deben ser nombres de host que resuelvan a registros A y/o AAAA. No pueden ser direcciones IP en bruto.
Muchos proveedores DNS te dejarán escribir tonterías. Los remitentes SMTP no lo harán.

CNAME en MX está ampliamente desaconsejado y a menudo es rechazado por validadores. Algunos resolutores lo siguen; algunos sistemas lo tratan como una mala configuración.
No quieres “algunos” cuando el ecosistema global de correo es el cliente.

Cache negativo y mitos de propagación

Cuando “arreglas DNS”, no arreglas el correo instantáneamente. Los resolutores hacen caché.
Algunos cachean demasiado tiempo. Algunos ignoran tu TTL. Algunos tienen respuestas obsoletas por resolutores intermedios.
Tu monitorización puede mostrar la respuesta correcta mientras un remitente importante aún ve la antigua.

Guión rápido de diagnóstico

Cuando la entrega de correo es extraña, no empieces cambiando números MX.
Empieza encontrando dónde falla la entrega: respuesta DNS, accesibilidad TCP, diálogo SMTP, rechazo por política o comportamiento de cola.

Primero: confirma lo que el mundo ve (DNS, desde múltiples puntos de vista)

Consulta MX y A/AAAA para el dominio y para cada objetivo MX.
Revisa los TTL y si las respuestas difieren entre resolutores.
Confirma que no hay CNAME en el objetivo MX.

Segundo: prueba TCP/25 y el banner SMTP en cada objetivo MX (IPv4 e IPv6)

Los fallos rápidos (rechazados) son buenas señales; los timeouts matan el rendimiento.
Verifica firewall, enrutamiento y bloqueos del proveedor.
Confirma el nombre de host correcto y las capacidades TLS si es requerido.

Tercero: observa la aceptación en el servidor y el comportamiento de la cola

¿Estás rechazando en la conexión, en HELO/EHLO, en MAIL FROM o en RCPT TO?
¿Estás diferiendo (4xx) por greylisting, limitación de tasa, DNSBL o política?
¿Tu “backup” está encolando indefinidamente porque no puede entregar internamente?

Cuarto: correlaciona con logs y patrones de remitentes

¿Qué IPs remotas se están conectando a qué objetivo MX?
¿Los proveedores grandes usan consistentemente el secundario?
¿Los fallos se concentran en IPv6, una AZ o un nombre de host específico?

Tareas prácticas: comandos, salidas y decisiones

Estas son las tareas que realmente ejecuto cuando alguien dice “la conmutación MX no funciona” o “el correo está retrasado”.
Cada tarea incluye: el comando, qué significa la salida y la decisión que tomas.

Task 1: See the MX set as your resolver sees it

cr0x@server:~$ dig +nocmd example.com MX +noall +answer
example.com.        300     IN      MX      10 mx1.example.net.
example.com.        300     IN      MX      20 mx2.example.net.

Significado: La preferencia 10 se intenta antes que 20. TTL es 300 segundos.

Decisión: Si el conjunto es incorrecto, arregla DNS primero. Si está bien, sigue; los números MX por sí solos no explican “retrasos”.

Task 2: Check whether MX targets actually resolve (A and AAAA)

cr0x@server:~$ dig +nocmd mx1.example.net A mx1.example.net AAAA +noall +answer
mx1.example.net.    300     IN      A       203.0.113.10
mx1.example.net.    300     IN      AAAA    2001:db8:10::10

Significado: Se publican IPv4 e IPv6.

Decisión: Si publicas AAAA, debes operar IPv6. Si IPv6 está roto, o fórralo o deja de anunciarlo.

Task 3: Detect a CNAME hiding behind an MX hostname

cr0x@server:~$ dig +nocmd mx2.example.net CNAME +noall +answer
mx2.example.net.    300     IN      CNAME   mail-gw.provider.example.

Significado: Tu nombre MX es un CNAME.

Decisión: Reemplázalo por un nombre con A/AAAA directamente. Algunos remitentes fallarán o lo tratarán como mala configuración.

Task 4: Compare answers from different resolvers (spot propagation/caching issues)

cr0x@server:~$ dig @1.1.1.1 example.com MX +noall +answer
example.com.        300     IN      MX      10 mx1.example.net.
example.com.        300     IN      MX      20 mx2.example.net.

cr0x@server:~$ dig @8.8.8.8 example.com MX +noall +answer
example.com.        3600    IN      MX      5 oldmx.example.org.

Significado: Diferentes resolutores no coinciden. Uno aún sirve el MX antiguo con un TTL más largo.

Decisión: Espera un corte retrasado. Mantén la infraestructura antigua viva hasta que las cachés expiren, o reduce el TTL con suficiente antelación antes de migraciones.

Task 5: Verify TCP/25 reachability quickly (IPv4)

cr0x@server:~$ nc -vz -w 3 203.0.113.10 25
Connection to 203.0.113.10 25 port [tcp/smtp] succeeded!

Significado: El puerto 25 es accesible y el host está escuchando.

Decisión: Si esto falla, arregla firewall/enrutamiento/bloqueos del proveedor antes de tocar DNS. La “conmutación” MX no ayudará si ambos están bloqueados.

Task 6: Verify TCP/25 reachability (IPv6)

cr0x@server:~$ nc -6 -vz -w 3 2001:db8:10::10 25
nc: connect to 2001:db8:10::10 port 25 (tcp) failed: No route to host

Significado: La ruta IPv6 está rota.

Decisión: Si no puedes arreglar IPv6 rápidamente, elimina AAAA para los hostnames MX (o arregla enrutamiento/firewall). De lo contrario, algunos remitentes se quedarán atascados en timeouts.

Task 7: Check the SMTP banner and basic dialogue

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.net:25 -servername mx1.example.net -crlf
CONNECTED(00000003)
220 mx1.example.net ESMTP Postfix
EHLO test.example
250-mx1.example.net
250-STARTTLS
250 PIPELINING

Significado: El servidor responde y ofrece STARTTLS. La identidad del banner parece coherente.

Decisión: Si STARTTLS falla o el banner es incorrecto (por ejemplo, un host genérico en la nube), espera problemas de reputación y políticas. Arregla TLS e identidad antes de añadir más MX.

Task 8: Ask which MX is chosen by your MTA (from a Linux host)

cr0x@server:~$ postconf -n | grep -E 'myhostname|mydestination|relayhost'
myhostname = app1.internal.example
mydestination = $myhostname, localhost.localdomain, localhost
relayhost =

Significado: Este host entregará directamente (no hay relayhost configurado).

Decisión: Si tenías la intención de reenviar a través de un smart host, configura relayhost. De lo contrario, esta máquina ahora forma parte de tu superficie de entrega de correo.

Task 9: Trace an outbound delivery decision (Postfix)

cr0x@server:~$ postmap -q example.com /etc/postfix/transport
smtp:

Significado: Sin transporte especial; usará búsquedas MX SMTP normales.

Decisión: Si necesitas forzar un siguiente salto específico (por ejemplo, para evitar un MX roto durante una respuesta a incidentes), usa una entrada temporal en la tabla de transporte.

Task 10: Look for deferrals and why they happen (queue inspection)

cr0x@server:~$ mailq
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
7F2A51C02F     4210 Mon Jan  4 10:12:19  alerts@example.com
                                         (connect to mx1.example.net[203.0.113.10]:25: Connection timed out)
                                         user@example.com

-- 1 Kbytes in 1 Request.

Significado: El remitente está agotando tiempo hacia el primario. Eso es un fallo-lento, lo peor.

Decisión: Arregla la conectividad o el firewall. Si no puedes, reduce temporalmente los tiempos de espera (con cuidado) y asegúrate de que el secundario esté sano.

Task 11: Confirm which remote IPs are hitting which MX (log sampling)

cr0x@server:~$ sudo grep -E 'connect from' /var/log/mail.log | tail -n 5
Jan  4 10:15:01 mx2 postfix/smtpd[18422]: connect from mail-oi1-f170.google.com[209.85.167.170]
Jan  4 10:15:09 mx2 postfix/smtpd[18422]: connect from mta7.am0.yahoodns.net[67.195.228.94]
Jan  4 10:15:14 mx2 postfix/smtpd[18422]: connect from outbound.protection.outlook.com[40.92.72.65]
Jan  4 10:15:18 mx2 postfix/smtpd[18422]: connect from mail.example-sender.net[198.51.100.44]
Jan  4 10:15:22 mx2 postfix/smtpd[18422]: connect from unknown[192.0.2.55]

Significado: Grandes proveedores se están conectando a mx2 (el “secundario”).

Decisión: Trata mx2 como producción. Si no es equivalente a mx1, has creado un cerebro partido en políticas de aceptación.

Task 12: Test recipient acceptance at SMTP time (RCPT TO behavior)

cr0x@server:~$ swaks --to nonexistent-user@example.com --server mx2.example.net --timeout 10
=== Trying mx2.example.net:25...
=== Connected to mx2.example.net.
<-  220 mx2.example.net ESMTP Postfix
 -> EHLO client.example
<-  250-mx2.example.net
<-  250 PIPELINING
 -> MAIL FROM:<test@client.example>
<-  250 2.1.0 Ok
 -> RCPT TO:<nonexistent-user@example.com>
<-  250 2.1.5 Ok
 -> DATA
<-  554 5.7.1 Service unavailable; Client host blocked

Significado: mx2 acepta un destinatario inválido en RCPT (250) pero falla después. Eso es receta para backscatter y crecimiento de colas.

Decisión: Configura validación de destinatarios (rechazar usuarios desconocidos en RCPT TO) o asegúrate de que mx2 no esté listado como MX para dominios que no puede validar.

Task 13: Verify reverse DNS for the MX IPs (reputation basics)

cr0x@server:~$ dig +short -x 203.0.113.10
mx1.example.net.

Significado: PTR coincide con el hostname usado en la identidad SMTP.

Decisión: Si el PTR falta o es genérico, arréglalo. Algunos receptores tratan el rDNS desajustado como señal de confianza y limitarán o rechazarán.

Task 14: Check SPF alignment for inbound gateways that might generate bounces

cr0x@server:~$ dig +short example.com TXT
"v=spf1 ip4:203.0.113.10 ip4:203.0.113.20 -all"

Significado: Solo esas IPs están autorizadas a enviar en nombre de example.com.

Decisión: Si tu “secundario” envía correo que reclama ser de tu dominio (incluidos DSNs), asegúrate de que SPF (y DKIM/DMARC cuando corresponda) no cause rechazos.

Task 15: Confirm DMARC policy (to predict how strict receivers will be)

cr0x@server:~$ dig +short _dmarc.example.com TXT
"v=DMARC1; p=reject; rua=mailto:dmarc-rua@example.com"

Significado: Política estricta; el correo desalineado se rechaza.

Decisión: Si enrutas correo por gateways distintos, mantiene la firma/alineación consistente. De lo contrario, algunos caminos fallarán y parecerán “aleatorios”.

Task 16: Spot SMTP timeouts vs refusals (kernel counters can hint)

cr0x@server:~$ sudo ss -tn state syn-sent '( dport = :25 )' | head
State    Recv-Q   Send-Q     Local Address:Port      Peer Address:Port
SYN-SENT 0        1          10.0.0.15:45822         203.0.113.10:25
SYN-SENT 0        1          10.0.0.15:45824         203.0.113.10:25

Significado: Muchas conexiones SYN-SENT indican timeouts o paquetes filtrados, no rechazo a nivel de aplicación.

Decisión: Revisa reglas de firewall y filtrado upstream. Si ves acumulación de SYN-SENT, cambiar la preferencia MX no ayudará.

Tres microhistorias corporativas (anonimizadas pero dolorosamente reales)

Microhistoria 1: El incidente causado por una suposición errónea (“Standby significa no usado”)

Una empresa mediana ejecutaba su correo entrante en un par de MTAs en distintos centros de datos. MX 10 apuntaba al primario.
MX 20 apuntaba a un servidor “de respaldo” que no se había tocado en meses porque era “solo para emergencias”.
El equipo se sintió responsable. ¡Dos MX! ¡Resiliencia lograda! Incluso le dijeron a la dirección que era “activo-pasivo”.

Entonces un cambio de firewall introdujo pérdida de paquetes intermitente hacia el DC primario. No fue una caída—solo suficientes SYN/ACKs perdidos para causar timeouts.
Algunos remitentes reintentaron y eventualmente llegaron al secundario. Otros encolaron durante horas antes de probar el secundario.
Algunos desistieron cuando su propia política de reintentos expiró. El síntoma parecía correo perdido aleatoriamente. Ese es el peor tipo de incidente.

El MTA de respaldo ejecutaba una configuración más antigua que no aplicaba validación de destinatarios en RCPT.
Aceptaba correo para destinatarios con errores tipográficos y luego fallaba la entrega internamente. El disco de la cola se llenó. Después empezó a fallar también el correo legítimo.
Mientras tanto, el primario estaba “mayormente arriba”, así que la monitorización no alertó hasta que los humanos lo hicieron.

La solución fue brutalmente aburrida: hacer ambos MTAs equivalentes, añadir controles de destinatario adecuados, alinear políticas y TLS, y monitorizar la entregabilidad, no solo la disponibilidad de procesos.
También aprendieron a tratar los timeouts como incidentes de severidad uno. Los rechazos fallan rápido; los timeouts fallan lento y roban tu rendimiento.

Microhistoria 2: La optimización que salió mal (“Preferencia igual balanceará bien”)

Otra organización quiso reducir la carga entrante en una pasarela. Publicaron dos registros MX con preferencia 10.
Esperaban una división limpia 50/50 y se felicitaron por evitar un balanceador.
¡Distribución basada en DNS! Clásico.

Funcionó en su mayoría—hasta que no. Una pasarela tenía una configuración TLS ligeramente más estricta: cifrados nuevos, cadena de certificados distinta, comportamiento de handshake TLS algo distinto.
Un subconjunto de stacks de remitentes más antiguos falló la negociación STARTTLS y retrocedió a texto plano—o falló por completo según su política.
De pronto, “algunos socios no pueden enviarnos email” se convirtió en un ticket recurrente.

Peor aún, el filtrado de spam no era idéntico. Una pasarela aprendió más rápido (más CPU, reglas más nuevas), así que los spammers se decantaron por la más débil.
La reputación de la IP de esa pasarela se degradó, lo que hizo que el correo legítimo de ciertos proveedores llegara más lento por la limitación.
Todos culparon al DNS porque eso fue lo que cambiaron. El DNS fue inocente; la asimetría fue la culpable.

Finalmente migraron a un modelo donde ambos objetivos MX eran realmente idénticos en política y ritmo de parches, y validaron la interoperabilidad TLS en staging.
Tener MX de preferencia igual no es “malo”. Tener endpoints desiguales detrás de MX de preferencia igual sí lo es.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día (“Mantén el MX antiguo activo, baja TTL con antelación”)

Una gran empresa migró desde una pasarela on-prem a un servicio hospedado de seguridad de correo.
El plan de migración no fue glamuroso. Fue una lista de verificación: bajar TTL de MX días antes, publicar nuevo MX con preferencia mayor primero, verificar aceptación,
luego intercambiar las preferencias durante una ventana tranquila. Mantener la pasarela antigua en línea durante todo el periodo de envejecimiento de caché.

Durante el corte, un issue inesperado en un resolutor DNS regional causó que algunos clientes recibieran respuestas MX obsoletas.
Predeciblemente, esos clientes siguieron enviando correo a la pasarela antigua. Pero la pasarela antigua aún estaba en funcionamiento, aceptando y reenviando al nuevo servicio.
Nadie notó en el negocio. Ese es el mejor resultado: invisiblemente correcto.

El equipo también tenía monitorización aburrida y efectiva: pruebas sintéticas SMTP a cada objetivo MX, siguiendo latencia de conexión y éxito de STARTTLS.
Cuando el servicio hospedado tuvo un breve pico de limitación, las comprobaciones sintéticas vieron inmediatamente el aumento de diferimientos 4xx.
El equipo respondió coordinándose con el proveedor y ajustando temporalmente sus propios umbrales de entrada.

Nadie recibió un trofeo. Pero nadie recibió una llamada a las 3 a.m. tampoco, que es lo más parecido a un trofeo en operaciones.

Broma #2: “Es solo DNS” es el equivalente en correo de “es solo un pequeño cambio.” Ambas frases envejecen mal.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: Algunos remitentes entregan al secundario incluso cuando el primario está “arriba”

Causa raíz: El primario está lento o sufre timeouts intermitentes; los remitentes caen al secundario según su propia lógica de reintentos. También podría ser IPv6 roto en el primario.

Solución: Elimina los timeouts. Revisa accesibilidad TCP, SYN-SENT, drops de firewall y IPv6. Asegura que el primario falle rápido cuando esté no saludable (o elimina rutas rotas).

2) Síntoma: El correo se retrasa horas y luego llega a ráfagas

Causa raíz: Los remitentes encolan por errores transitorios (4xx) o timeouts. Tu “failover” MX está ocurriendo, pero en un calendario de reintentos largo.

Solución: Encuentra la etapa SMTP exacta que devuelve 4xx. Arregla límites de tasa, greylisting, triggers DNSBL o filtrado upstream. Reduce los stalls causados por timeouts.

3) Síntoma: Rebotes aleatorios que referencian un nombre MX concreto

Causa raíz: Configuración desigual entre los objetivos MX (TLS, anti-spam, requisitos de auth, validación de destinatarios o enrutamiento downstream).

Solución: Haz los objetivos MX simétricos o elimina el más débil. Si no puedes mantenerlos equivalentes, no los anuncies por igual (o no los anuncies).

4) Síntoma: Bucles de correo o “relaying denied” desde el secundario

Causa raíz: El secundario no está configurado para aceptar correo para el dominio, o no puede enrutar al destino interno. Suele pasar con “backup MX” que no conoce tus dominios.

Solución: Asegura que el secundario sea autoritativo para el dominio destinatario y tenga rutas de transporte correctas. Valida con pruebas SMTP RCPT y entrega de extremo a extremo.

5) Síntoma: Rebotes “Host not found” tras un cambio de MX

Causa raíz: El nombre del objetivo MX no tiene A/AAAA, fue mal tipeado o depende de una cadena CNAME que falla en algunos resolutores.

Solución: Publica A/AAAA directos para los objetivos MX; elimina CNAME-en-MX; verifica con dig y desde múltiples resolutores.

6) Síntoma: Fallos de entrega solo desde remitentes con IPv6

Causa raíz: Existe AAAA pero la ruta IPv6 está rota (enrutamiento, firewall, rarezas NAT64, bloqueos del proveedor) o falta DNS inverso para IPv6.

Solución: O bien opera IPv6 por completo (conectividad, rDNS, reputación), o no publiques AAAA para los hosts MX.

7) Síntoma: Aumento de spam tras añadir un backup MX

Causa raíz: El backup MX acepta destinatarios inválidos (sin validación), convirtiéndose en un objetivo atractivo y carga para las colas.

Solución: Rechaza destinatarios inválidos en RCPT, o asegúrate de que el backup MX tenga acceso al directorio / mapas de destinatarios. Añade controles estrictos de retransmisión y monitorización.

8) Síntoma: “Funciona en nuestras pruebas” pero los socios reportan fallos

Causa raíz: Probaste desde una red/resolutor. Los socios golpean resolutores distintos, respuestas cacheadas, stacks TLS distintos o restricciones de política.

Solución: Prueba desde múltiples redes y resolutores. Valida interoperabilidad TLS y diálogo SMTP. Monitoriza con sondas externas, no solo internamente.

Listas de verificación / plan paso a paso

Checklist: diseñando registros MX múltiples (qué hacer, no qué esperar)

Decide la intención: distribución (preferencia igual) o orden de preferencia (primario/secundario). No mezcles narrativas.
Haz cada MX anunciado de calidad producción: parches, monitorización, capacidad, logs, backups y propiedad on-call.
Mantén la política consistente: TLS, política de cifrados, anti-spam, limitación de tasa, validación de destinatarios e identidad del banner.
Opera IPv6 deliberadamente: publica AAAA solo si has probado accesibilidad, rDNS y rutas de firewall.
Fija TTL sensatos: baja el TTL con suficiente antelación para migraciones planificadas; evita cambios frenéticos el mismo día.
Evita CNAME-en-MX: publica A/AAAA directamente para el nombre MX.
Planifica para colas: entiende que el failover puede significar entrega retrasada. Comunícalo a las partes interesadas.
Valida end-to-end: prueba aceptación SMTP y enrutamiento interno, no solo “puerto abierto”.

Paso a paso: corte seguro de MX (edición mínima drama)

T-7 días: Baja el TTL de MX (p. ej., 3600 → 300). Mantén el TTL antiguo el tiempo suficiente para propagarlo con seguridad.
T-3 días: Pon el nuevo MX en línea. Asegúrate de que pueda aceptar correo para el dominio y entregar internamente.
T-2 días: Publica el nuevo MX con preferencia mayor (como canario). Ejemplo: MX existente 10, nuevo MX 20.
T-2 a T-1 días: Observa logs. Confirma quién se conecta al nuevo MX y que los mensajes se entregan correctamente.
T-0: Intercambia preferencias (el nuevo pasa a número menor). Mantén el MX antiguo en línea con preferencia mayor.
T+1 día: Continúa monitorizando desde múltiples resolutores y con comprobaciones sintéticas SMTP.
T+ventana-de-envejecimiento-de-caché: Elimina el MX antiguo solo cuando estés seguro de que los resolutores obsoletos ya no lo usan.

Checklist: “backup MX” hecho correctamente (raro, pero posible)

La validación de destinatarios es innegociable: rechaza destinatarios desconocidos en RCPT.
Límites de store-and-forward: capea el crecimiento de la cola; alerta temprano; asegura disco y capacidad de E/S.
Controles estrictos de retransmisión: nunca permitas que se convierta en un relay de propósito general.
Política consistente: misma postura TLS y filtrado que el primario para evitar deriva de reputación.
Propiedad operativa: monitorizado, parchado, probado e incluido en simulacros de incidentes.

Preguntas frecuentes

1) ¿Un número MX menor garantiza que los remitentes usarán siempre ese servidor?

No. Es un orden de preferencia, no un mecanismo de imposición. Los remitentes pueden cachear respuestas antiguas, aplicar sus propias políticas
y retroceder cuando el host preferido está lento, tiene timeouts o rechaza transitoriamente.

2) Si mi MX primario está caído, ¿el correo irá inmediatamente al secundario?

A veces. Si “caído” se manifiesta como fallos rápidos (connection refused), muchos remitentes probarán rápidamente el siguiente MX.
Si “caído” parece timeouts, pueden consumir tiempo por intento y luego encolar y reintentar más tarde, provocando retrasos.

3) ¿Debo poner valores de preferencia MX iguales para balancear carga?

Solo si ambos endpoints son equivalentes operacional y políticamente. Preferencia igual significa “cualquiera sirve”.
Si uno es más débil, tendrás fallos parciales raros que parecen aleatorios.

4) ¿Puede un registro MX apuntar directamente a una dirección IP?

No. Los objetivos MX deben ser nombres de host que resuelvan a IPs mediante A/AAAA.
Si necesitas control directo de enrutamiento por IP, buscas otra herramienta distinta a MX.

5) ¿Es aceptable que un objetivo MX sea un CNAME?

Está ampliamente desaconsejado y causa problemas de interoperabilidad. Algunos sistemas siguen el CNAME; otros lo tratan como inválido o actúan de forma inconsistente.
Publica A/AAAA directamente para el nombre MX.

6) ¿Cuántos registros MX debería publicar?

Dos es común. Más de tres rara vez ayuda y con frecuencia aumenta la superficie de mala configuración.
Cada MX que publiques debe mantenerse como si recibiera tráfico real—porque lo hará.

7) ¿Puedo usar un “backup MX” que solo almacena y reenvía más tarde?

Puedes, pero debe validar destinatarios (o aceptarás basura que no puedes entregar), y debe estar asegurado y monitorizado.
Muchas organizaciones modernas prefieren usar un servicio reputado de seguridad de correo entrante en vez de ejecutar store-and-forward por su cuenta.

8) ¿Por qué veo correo llegando a mi secundario aun cuando todo está sano?

Porque algunos remitentes distribuyen entre igual preferencia, por caché DNS, por las propias heurísticas del remitente,
o porque tu primario falla ocasionalmente lento (timeouts), empujando reintentos al secundario.

9) ¿Los cambios de TTL surten efecto inmediatamente?

Los cambios de TTL solo afectan a cachés que consulten después del cambio. Los resolutores que ya guardaron el registro lo mantendrán hasta que expire,
y algunos resolutores intermedios se comportan mal. Planifica reducciones de TTL con antelación.

10) ¿La prioridad MX influye en el correo saliente de mi dominio?

No directamente. MX es para el enrutamiento entrante a tu dominio. El saliente lo controla la configuración de tu MTA, ajustes de relayhost y enrutamiento del proveedor.
La gente confunde esto constantemente, especialmente durante migraciones.

Conclusión: próximos pasos que puedes hacer hoy

Los registros MX múltiples no son una casilla mágica de redundancia. Son un contrato publicado con el mundo:
“Aquí están las puertas que puedes usar para entregarnos correo.” Cada puerta debe abrirse de forma fiable.

Pasos prácticos:

Inventaria tu conjunto MX y verifica que cada objetivo resuelve (A/AAAA) y responde en TCP/25 desde fuera de tu red.
Si publicas IPv6, prueba la accesibilidad SMTP IPv6 y el rDNS. Si no puedes operarlo, deja de anunciarlo.
Haz que tus endpoints MX tengan políticas idénticas: comportamiento TLS, validación de destinatarios, anti-spam y enrutamiento downstream.
Construye un pequeño monitor sintético: conectar, leer banner, emitir EHLO, intentar STARTTLS y registrar latencia. Alerta por timeouts y aumento de diferimientos 4xx.
Para cambios futuros, baja el TTL con antelación y mantiene el MX antiguo activo el tiempo suficiente para que las cachés envejezcan.

Haz eso, y la “prioridad MX” se convertirá en una herramienta útil en lugar de un misterio recurrente.