Correo: TTL durante la migración — el truco simple que evita la interrupción

enero 2, 2026 • febrero 3, 2026 • Lectura: 27 min • Views: 8

¿Te fue útil?

Las migraciones de correo rara vez fallan porque la sincronización IMAP fue lenta o porque alguien interpretó mal un asistente del proveedor.
Fallan porque el correo sigue llegando al lugar antiguo después de que “cambiaste”, o peor: la mitad del mundo va al antiguo,
la otra mitad al nuevo, y descubres cómo se siente la entrega partida a las 2 a.m.

La solución es aburrida, fiable y absolutamente no opcional: controla la caché DNS con el TTL antes de hacer el corte.
No puedes eliminar la propagación, pero puedes hacerla corta, medible y reversible.

TTL en una frase (y por qué importa para el correo)

TTL (Time To Live) es cuánto tiempo se permite almacenar en caché una respuesta DNS antes de que el resolutor tenga que volver a preguntar.
Durante una migración de correo, el TTL determina cuánto tiempo los remitentes siguen usando los registros MX antiguos después de que los cambias.

Parece sencillo porque lo es. También es una de las pocas palancas de migración que puedes accionar semanas antes,
sin tocar los servidores de correo en absoluto.

Aquí está la verdad operativa: un corte no es cuando tú cambias el DNS; es cuando suficientes resolutores
dejan de creer la respuesta antigua. El TTL es el calendario que entregas a Internet.

Qué falla realmente durante los cortes de correo

1) Entrega partida (el desastre silencioso)

Algunos remitentes resuelven tu MX al proveedor antiguo. Otros lo resuelven al nuevo. Ambos aceptan correo.
Los usuarios informan mensajes “perdidos” y ambos tienen razón. El correo se entrega. Simplemente no al mismo sitio.

Si planeas coexistencia, la entrega partida puede ser intencional. La mayoría de los equipos no lo están.
La mayoría lo crean por accidente y lo llaman “intermitente”.

2) Reintentos y retroalimentación que parecen pérdida

SMTP es un sistema de almacenar y reenviar. Los remitentes reintentan ante fallos transitorios.
Cuando cambias MX y algo está mal configurado (TLS, reputación de IP, greylisting, firewall),
puedes obtener una acumulación de reintentos que llegan tarde. Los usuarios lo llaman “perdido” y luego llega a las 3 p.m.

3) Desalineación de autenticación (SPF/DKIM/DMARC)

Cambiar desde dónde envías correo suele ir ligado a cambiar dónde lo recibes.
Si el nuevo proveedor firma DKIM de forma distinta, o envías desde nuevas IPs sin actualizar SPF,
puedes pasar la entrega pero perder la confianza. Eso significa carpeta de spam, no una caída. En la práctica, es una caída.

4) Suposiciones excesivas sobre la “propagación DNS”

Los equipos tratan el DNS como una niebla mágica de consistencia eventual. No es niebla. Es caché con reglas.
Las reglas son medibles. Si no las mides, no estás migrando; estás apostando.

Chiste #1: La propagación DNS es como “esperar a que Internet se actualice”—lo cual es adorable hasta que te das cuenta de que Internet no toma turnos.

Datos interesantes y algo de historia (para que dejes de adivinar)

El DNS es más antiguo que la mayoría de proveedores de correo SaaS. El Sistema de Nombres de Dominio se diseñó a principios de los 80 para reemplazar la distribución de HOSTS.TXT a escala. El correo fue y sigue siendo una de sus aplicaciones.
Los registros MX existen porque SMTP necesitaba indirección. El enrutamiento de correo temprano necesitaba una forma de decir “el correo para este dominio va allí”, no “la A de este dominio es el servidor de correo”. MX formalizó eso.
El TTL no es nuevo; lo que cambió es el comportamiento de la caché. Los resolutores recursivos modernos, los resolutores de ISP y las cachés empresariales almacenan respuestas de forma agresiva, y algunos añaden comportamientos “útiles” como prefetch.
El caché negativo existe. Las respuestas NXDOMAIN pueden ser almacenadas según los valores SOA de la zona, así que “añadiremos ese registro más tarde” aún puede golpearte por un tiempo.
SMTP se diseñó para reintentos, no para entrega instantánea. La cola y reintento es por lo que el correo es resiliente… y por lo que los errores de migración pueden tardar horas en aparecer.
Algunos remitentes fijan resultados más tiempo del que esperas. Aunque los resolutores deberían respetar el TTL, algunos entornos mantienen respuestas debido a reenvíos internos, cachés de política o comportamientos de recursor obsoletos.
Los agentes de transferencia de correo usan preferencia MX. Gana el valor de preferencia más bajo. Un orden incorrecto puede enrutar silenciosamente el correo a un destino “válido” pero erróneo.
Los TTL largos se usaban históricamente para reducir carga DNS. En épocas en que el ancho de banda y la CPU costaban, los administradores ponían TTLs de varias horas para evitar que los resolutores atosigaran los servidores autorizados.
Las migraciones de correo se hicieron más difíciles cuando la autenticación se endureció. SPF (años 2000), DKIM (finales de los 2000) y DMARC (2010s) mejoraron la confianza pero aumentaron las piezas móviles durante el corte.

El “truco simple”: escalonado de TTL que evita la interrupción

No se trata de “bajar el TTL justo cuando estás listo”. Ese es el error clásico. Bajar el TTL solo ayuda después de que
el nuevo TTL haya tenido tiempo de reemplazar las respuestas antiguas en caché. Si tu TTL MX es de 3600 segundos y lo bajas a 300
a mediodía, un resolutor que cacheó a las 11:59 aún tiene permiso para creer la respuesta de 3600 segundos hasta las 12:59.

El truco es escalonar los cambios de TTL para que, el día del corte, Internet ya esté entrenado para comprobar con frecuencia.
Entonces tu cambio de MX se convierte en una ventana corta en lugar de un misterio de medio día.

El patrón central

Días antes del corte: baja el TTL en MX (y en cualquier registro relacionado que vayas a cambiar) a algo como 300 segundos.
Espera al menos el TTL antiguo + margen de seguridad (prefiero 2× el TTL antiguo si puedes) para que las cachés se refresquen naturalmente.
Corte: cambia el MX al nuevo proveedor mientras el TTL está bajo.
Después de la estabilidad: sube el TTL a un valor sensato (a menudo 1800–3600 segundos) para reducir el volumen de consultas y el ruido.

Qué registros escalonar (la mayoría de equipos omite al menos uno)

MX es el titular, pero las migraciones de correo tocan una pequeña constelación de DNS. Escalona el TTL para cualquier cosa que vayas
a cambiar durante la ventana:

MX (obvio)
A/AAAA de los nombres de host de correo referenciados por MX (a veces el proveedor te da nombres que no controlas; a veces sí)
TXT para cambios de SPF (si vas a cambiar el envío)
TXT para registros de selector DKIM (si vas a rotar o añadir)
TXT para DMARC (si vas a endurecer la política tras la migración)
CNAME para endpoints de autodiscover/autoconfig (la molestia de los clientes sigue siendo molestia)
SRV en algunas configuraciones empresariales (menos común, pero no lo asumas)

¿Qué tan bajo es “TTL bajo”?

300 segundos (5 minutos) es el valor de referencia. 60 segundos es tentador pero a menudo inútil: no todos los resolutores
se comportan mejor a 60 que a 300, y aumentas el volumen de consultas y el riesgo de limitación o ruido en logs.
Si tu proveedor DNS es inestable, un TTL demasiado bajo puede amplificar la inestabilidad hasta convertirla en una caída visible.

Qué no resuelve el TTL

El TTL reduce el tiempo que le toma al mundo notar tus nuevos registros. No:

Forza a un remitente a reintentar inmediatamente.
Arregla problemas de firewall o accesibilidad al puerto 25.
Repara la alineación SPF/DKIM.
Traslada mágicamente el correo ya entregado al buzón antiguo.

Una cita para llevar en un recordatorio

Todo falla todo el tiempo. — Werner Vogels

Trata el cambio de MX como una falla que planeas sobrevivir. El escalonado de TTL es tu victoria de resiliencia más fácil.

Cronogramas que funcionan: T-7 días a T+2 días

Abajo hay un calendario de migración que asume que vas a cambiar el enrutamiento entrante de correo (corte de MX) y posiblemente el saliente.
Adapta los días a tu organización, pero mantén el orden. El correo castiga la improvisación.

T-7 a T-3 días: hacer el DNS aburrido

Inventariar los TTL actuales para MX y registros relacionados.
Bajar los TTL a 300 segundos para los registros que vas a cambiar.
Confirmar que el DNS autoritativo realmente está sirviendo el nuevo TTL (no confíes en la interfaz).
Ejecutar una verificación “pre-corte” desde múltiples resolutores (tu ISP, resolutores públicos, recursors corporativos).

T-2 a T-1 días: verificar que el lado receptor nuevo puede aceptar correo

Confirmar que el SMTP entrante funciona hacia el nuevo proveedor (dominios de prueba, usuarios piloto o MX alternativo).
Confirmar antispam, ajustes TLS, reglas de conectores y listas de permitidos/denegados entrantes.
Preparar reversión: tener listos los registros MX antiguos para restaurar, y confirmar que el lado antiguo aún puede aceptar correo.

T-0 día: corte, observa y no entres en pánico

Cambiar MX.
Vigilar el flujo de correo entrante y el comportamiento de las colas en ambos lados.
Confirmar resultados de autenticación (SPF/DKIM/DMARC) en mensajes reales.
Rastrear el tráfico rezagado que aún llega al sistema antiguo; decidir si reenviar, retransmitir o extraer.

T+1 a T+2 días: estabilizar y subir TTL

Subir TTL a 1800–3600 segundos una vez que estés seguro.
Seguir monitoreando reintentos y correos retrasados.
Desmantelar el inbound antiguo gradualmente, no de inmediato, salvo que el riesgo lo exija.

Guion de diagnóstico rápido

Cuando llegue el inevitable “el correo está caído”, necesitas una forma rápida de localizar el cuello de botella.
No empieces discutiendo sobre propagación DNS. Empieza por acotar el radio del problema.

Primero: ¿es DNS, accesibilidad SMTP o política de aceptación?

Comprueba qué MX ve el mundo desde al menos dos resolutores independientes.
Comprueba si el destino acepta TCP/25 y responde con un banner SMTP.
Comprueba si el servidor acepta un mensaje de prueba (aunque solo sea MAIL FROM/RCPT TO).

Segundo: ¿se está entregando el correo en otro lugar?

Busca en los logs/colas del sistema antiguo entregas recientes.
Comprueba el rastro de mensajes en el sistema nuevo para intentos de entrega.
Busca rebotes y mensajes diferidos en los logs de remitentes (si son internos) o en cabeceras de rebote proporcionadas por usuarios.

Tercero: ¿la autenticación provoca una “caída suave”?

Verifica que SPF incluya los sistemas de envío correctos.
Verifica la firma DKIM y la corrección del selector.
Verifica que la política DMARC no esté rechazando correo legítimo nuevo.

Cuarto: ¿algo cachea más tiempo que el TTL?

Revisa reenvíos/recursors empresariales por datos obsoletos.
Comprueba si dispositivos de seguridad upstream hacen filtrado/caché DNS.
Decide si es necesario anular temporalmente con vaciados de resolutor locales para aplicaciones críticas (raro, pero a veces necesario).

Tareas prácticas: comandos, salidas y decisiones (12+)

La diferencia entre una migración calma y un titular es casi siempre si puedes responder preguntas básicas con rapidez:
“¿Qué MX está activo?”, “¿Quién está cacheando qué?”, “¿Es accesible el puerto 25?”, “¿Estamos rechazando correo por política?”
Abajo hay tareas prácticas que puedes ejecutar desde una máquina Linux con herramientas comunes.

Task 1: Consultar MX y TTL actual desde tu resolutor por defecto

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

Qué significa: El TTL es 3600 segundos. Muchos resolutores pueden mantener esta respuesta hasta una hora después de cachearla.

Decisión: Si el corte es dentro del próximo día, llegaste tarde. Baja el TTL ahora y acepta la transición más larga, o reprograma.

Task 2: Consultar servidores autoritativos directamente (evitar cachés)

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

Qué significa: La autoridad está sirviendo TTL 300 ahora. Las cachés convergerán cuando expiren sus TTL antiguos.

Decisión: Anota la hora del cambio. El corte seguro más temprano es después de la expiración del TTL antiguo + margen.

Task 3: Comparar diferentes resolutores públicos (propagación real, no intuiciones)

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do echo "== $r =="; dig +noall +answer example.com MX @$r; done
== 1.1.1.1 ==
example.com.        3600    IN      MX      10 mx1.oldmail.example.net.
example.com.        3600    IN      MX      20 mx2.oldmail.example.net.
== 8.8.8.8 ==
example.com.        300     IN      MX      10 mx1.oldmail.example.net.
example.com.        300     IN      MX      20 mx2.oldmail.example.net.
== 9.9.9.9 ==
example.com.        1800    IN      MX      10 mx1.oldmail.example.net.
example.com.        1800    IN      MX      20 mx2.oldmail.example.net.

Qué significa: Diferentes resolutores cachearon en distintos momentos. Esto es normal y exactamente por lo que importa escalonar TTL.

Decisión: No cortes hasta que los grandes resolutores muestren el TTL bajo de forma consistente, a menos que puedas tolerar entrega partida.

Task 4: Confirmar a qué nombres de host apuntan los MX (y si controlas su DNS)

cr0x@server:~$ dig +noall +answer mx1.oldmail.example.net A
mx1.oldmail.example.net. 300 IN A 203.0.113.10

Qué significa: El objetivo MX resuelve a una IP con TTL 300. Si este registro está en una zona del proveedor que no controlas, no puedes escalonar su TTL.

Decisión: Si lo controlas, escalónalo. Si no, acepta que el proveedor asume ese riesgo.

Task 5: Buscar objetivos MX “colgantes” (una clásica trampa de corte)

cr0x@server:~$ dig +noall +answer mx-new.example.com A

Qué significa: Sin respuesta. Si apuntas MX a un nombre que no resuelve, los remitentes harán cola/reintentos y los usuarios dirán que el correo está muerto.

Decisión: No cortés. Arregla el DNS primero. También comprueba el tiempo de caché negativo vía SOA.

Task 6: Comprobar valores SOA para entender el comportamiento de caché negativo

cr0x@server:~$ dig +noall +answer example.com SOA
example.com. 3600 IN SOA ns1.dnsprovider.net. hostmaster.example.com. 2026010401 7200 900 1209600 300

Qué significa: El campo final (300) es el TTL de caché negativo en muchas implementaciones.

Decisión: Si vas a añadir registros faltantes, espera que NXDOMAIN persista hasta este valor después de que las cachés lo hayan visto.

Task 7: Validar accesibilidad SMTP al nuevo host MX (TCP/25)

cr0x@server:~$ nc -vz mx1.newmail.example.net 25
Connection to mx1.newmail.example.net 25 port [tcp/smtp] succeeded!

Qué significa: La ruta de red está abierta. Esto no prueba aceptación, pero elimina el primer obstáculo.

Decisión: Si falla, arregla firewall/grupos de seguridad/rutas antes de tocar MX.

Task 8: Comprobar el banner SMTP y el handshake básico

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect mx1.newmail.example.net:25 -servername mx1.newmail.example.net
CONNECTED(00000003)
---
220 mx1.newmail.example.net ESMTP ready
...
250-STARTTLS
250 SIZE 52428800

Qué significa: El servidor habla SMTP y ofrece STARTTLS. Tienes evidencia de que está activo y es relativamente moderno.

Decisión: Si STARTTLS es requerido por política, asegúrate de que se ofrezca y de que los certificados validen en tu entorno.

Task 9: Hacer una transacción SMTP mínima para validar la política de aceptación

cr0x@server:~$ printf "EHLO test.example\r\nMAIL FROM:<probe@example.org>\r\nRCPT TO:<postmaster@example.com>\r\nDATA\r\nSubject: smtp probe\r\n\r\nhello\r\n.\r\nQUIT\r\n" | nc -w 5 mx1.newmail.example.net 25
220 mx1.newmail.example.net ESMTP ready
250-mx1.newmail.example.net
250 PIPELINING
250 2.1.0 Ok
250 2.1.5 Ok
354 End data with <CR><LF>.<CR><LF;
250 2.0.0 Queued
221 2.0.0 Bye

Qué significa: El sistema nuevo acepta correo para tu dominio y lo encola para entrega. Eso es el núcleo de “entrante funciona”.

Decisión: Si RCPT TO es rechazado, corrige verificación de dominio, dominios aceptados, reglas de enrutamiento o ajustes antispam.

Task 10: Comprobar contenido del registro SPF antes y después de cambios salientes

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.oldprovider.example -all"

Qué significa: SPF actualmente autoriza solo al proveedor antiguo.

Decisión: Si el envío va a cambiar, añade el include o las IPs del nuevo emisor antes de que los usuarios comiencen a enviar desde la nueva plataforma.

Task 11: Confirmar que existen registros selector DKIM (trampa común “funcionó en el asistente”)

cr0x@server:~$ dig +short TXT selector1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Qué significa: El registro del selector está presente en DNS. Sin él, los destinatarios no pueden verificar tus firmas.

Decisión: Si falta, no actives políticas “DKIM requerido” o DMARC estricto aún. Arregla el DNS primero.

Task 12: Confirmar política DMARC (para evitar rechazo autoinducido)

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

Qué significa: Alineación estricta y política de rechazo. Durante la migración, esto puede convertir una deriva menor de autenticación en una falla completa.

Decisión: Si vas a cambiar el saliente o DKIM, considera relajar temporalmente a p=quarantine o ajustar modos de alineación hasta que todo esté estable.

Task 13: Verificar qué MX está usando actualmente un MTA vía traza DNS

cr0x@server:~$ dig +trace example.com MX
; <<>> DiG 9.18.24 <<>> +trace example.com MX
.                       518400  IN      NS      a.root-servers.net.
...
example.com.            300     IN      MX      10 mx1.newmail.example.net.
example.com.            300     IN      MX      20 mx2.newmail.example.net.

Qué significa: La traza muestra la cadena autoritativa y las respuestas MX finales. Si esto es correcto pero algunos clientes aún ven el MX antiguo, la caché está aguas abajo.

Decisión: Usa esto para demostrar qué sirve la autoridad; luego enfócate en los resolutores, no en capturas de pantalla de la UI DNS.

Task 14: Inspeccionar el comportamiento de la caché del resolutor local (ejemplo systemd-resolved)

cr0x@server:~$ resolvectl query example.com --type=MX
example.com: 10 mx1.oldmail.example.net
             20 mx2.oldmail.example.net

-- Information acquired via protocol DNS in 1.9ms.
-- Data is authenticated: no

Qué significa: Tu host todavía ve el MX antiguo. Puede ser tu caché local, no el resto del mundo.

Decisión: Vacía cachés locales (con cuidado) o consulta un resolutor externo directamente para evitar un autodiagnóstico erróneo.

Task 15: Confirmar que el sistema antiguo sigue recibiendo correo (para detectar entrega partida)

cr0x@server:~$ tail -n 5 /var/log/maillog
Jan 04 01:10:21 oldmx postfix/smtpd[18273]: connect from mail-oi1-f170.google.com[209.85.167.170]
Jan 04 01:10:22 oldmx postfix/smtpd[18273]: 3F2A01234: client=mail-oi1-f170.google.com[209.85.167.170]
Jan 04 01:10:22 oldmx postfix/cleanup[18280]: 3F2A01234: message-id=<CA+demo@example.org>
Jan 04 01:10:23 oldmx postfix/qmgr[912]: 3F2A01234: from=<sender@example.org>, size=1842, nrcpt=1 (queue active)
Jan 04 01:10:23 oldmx postfix/local[18290]: 3F2A01234: to=<user@example.com>, relay=local, delay=1.1, dsn=2.0.0, status=sent

Qué significa: El MX antiguo todavía está recibiendo correo de al menos algunas fuentes. Eso es entrega partida en acción.

Decisión: Decide si reenviar/relé desde el antiguo al nuevo, o mantener el buzón antiguo accesible hasta que los rezagados disminuyan.

Task 16: Medir “quién sigue usando el MX antiguo” muestreando cabeceras Received

cr0x@server:~$ grep -m 1 -i '^Received:' /var/mail/user | head -n 1
Received: from mx1.oldmail.example.net (mx1.oldmail.example.net [203.0.113.10]) by oldmx.example.com with ESMTP id 3F2A01234

Qué significa: El mensaje pasó por la infraestructura antigua. Las cabeceras son oro forense durante migraciones.

Decisión: Si socios clave siguen enroutando al MX antiguo días después, investiga si usan resolutores internos con caché persistente o rutas estáticas.

Tres mini-historias corporativas (cómo falla en la vida real)

Mini-historia #1: El incidente causado por una suposición equivocada

Una compañía mediana pasó de una pila autogestionada Postfix/Dovecot a una plataforma de correo alojada. El plan fue
sencillo: sincronizar buzones, cambiar MX el viernes por la noche y darlo por hecho.

El líder del proyecto supuso que la “propagación DNS” terminaría en minutos porque su consola DNS se actualizó al instante.
No comprobaron el TTL existente. Estaba en 14.400 segundos (4 horas), un relicto de cuando sus
servidores autorizados eran frágiles y trataban de reducir la carga de consultas.

Hicieron el cambio de MX a las 9 p.m. A las 9:15 p.m. llegó la primera alerta: algunos usuarios recibían correo en el nuevo
buzón y otros no. A las 10 p.m., ejecutivos enviaban capturas. A medianoche, el servicio de asistencia tenía una cola
de tickets de “correo perdido” que eran reales, porque el correo estaba dividido entre dos sistemas sin puente automático.

El equipo intentó “forzar la propagación” (lo cual no existe) haciendo más cambios DNS. Eso lo empeoró.
Algunos resolutores se refrescaron y obtuvieron una respuesta diferente; otros permanecieron pegados. Su monitorización,
que usaba un solo resolutor público, mostraba “MX correcto”. A la realidad no le importó.

La solución final no fue heroica. Volvieron a habilitar la entrega en el sistema antiguo, configuraron reenvío desde antiguo a nuevo,
y esperaron a que expirara el TTL. La causa raíz del postmortem fue una frase que debería imprimirse en tazas: confundieron
“el cambio autoritativo está en vivo” con “los clientes han vuelto a consultar”.

Mini-historia #2: La optimización que salió mal

Una gran empresa tenía un equipo central de DNS que se enorgullecía del rendimiento. Ejecutaban resolutores con caché agresiva
e incluso los frontaban con reenvíos internos en sitios remotos. La latencia era excelente. La fiabilidad era
mayormente buena. Y luego el equipo de correo programó una migración de tenant.

El equipo de correo hizo lo correcto: bajó el TTL de MX a 300 segundos una semana antes. Verificaron los servidores autoritativos.
Ejecutaron dig desde un par de portátiles. Todo parecía listo.

El corte ocurrió y… los sitios remotos siguieron entregando al proveedor antiguo durante horas. No minutos.
La “optimización” del equipo DNS era un comportamiento de prefetch y servicio: los resolutores obtenían respuestas antes de la expiración del TTL
y los reenvíos remotos tenían sus propias capas de caché. El TTL se respetó en el sentido literal, pero el comportamiento efectivo
durante la ventana de cambio fue pegajoso.

El equipo de correo culpó inicialmente al proveedor nuevo. El proveedor culpó al remitente. Mientras tanto, el proveedor antiguo
seguía aceptando correo porque nadie quería desmantelar durante la transición. La entrega partida fue un problema de todo el día
que sólo afectó ciertas ubicaciones, que es el peor tipo de problema: el que parece error de usuario.

La solución fue enrutar alrededor de la caché “inteligente” durante el corte: apuntar temporalmente sitios remotos a un resolutor
que no hiciera prefetch ni encadenara caches, luego revertir después de la ventana. Además, el equipo DNS documentó sus capas de caché
y añadió una bandera de gestión de cambios para “ventanas de migración”, donde se desactiva el comportamiento de prefetch.

Mini-historia #3: La práctica aburrida pero correcta que salvó el día

Una firma financiera migró el correo como parte de una renovación de identidad y endpoints. La parte de correo no era
glamorosa. Precisamente por eso funcionó. Ejecutaron una lista de verificación, se mantuvieron en ella y se negaron a cortar sin
evidencia.

Dos semanas antes del corte, bajaron TTL en MX, SPF, selectores DKIM y registros autodiscover. Registraron la hora del cambio
y calcularon el “flip seguro” basado en el TTL antiguo. Ejecutaron consultas contra sus servidores autorizados y tres resolutores
externos dos veces al día y registraron los resultados en un runbook compartido.

El día del corte, su monitorización no solo comprobaba “MX igual al esperado”. Comprobaba “TTL de MX es bajo”, “el banner SMTP
coincide con el sistema nuevo” y “mensajes de prueba son aceptados y rastreados end-to-end”. También mantuvieron el sistema entrante antiguo
activo pero configurado para reenviar correo al nuevo. Eso significó que los rezagados dejaron de ser un problema para los usuarios.
Eran simplemente una métrica.

La migración tuvo todavía problemas menores: algunos socios tenían hosts MX antiguos codificados en sus dispositivos (sí, eso existe),
y una app interna usaba un resolutor local que no se refrescaba a menudo. Pero gracias al escalonado de DNS, pudieron centrarse en esos casos
límite sin caos global.

Su secreto no fue una herramienta. Fue disciplina. La práctica aburrida fue “medir antes de cambiar y mantener una reversión que funcione.”
El resultado fue un corte tan anodino que la dirección olvidó que ocurrió, lo cual es el mayor cumplido en operaciones.

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

1) Síntoma: Algunos remitentes entregan al proveedor antiguo horas después del corte de MX

Causa raíz: No se bajó el TTL con suficiente antelación, o múltiples capas de caché (reenvíos empresariales, resolutores de sitio) mantienen respuestas obsoletas.

Solución: Baja el TTL días antes la próxima vez. Por ahora, mantiene el entrante antiguo aceptando y reenvía/reléalo al sistema nuevo. Identifica resolutores rebeldes y evítalos temporalmente.

2) Síntoma: Colas de correo en el lado del remitente con “connection timed out”

Causa raíz: Puerto 25 bloqueado hacia el nuevo MX, o el nuevo proveedor requiere IPs de origen específicas/configuración de conectores.

Solución: Valida la accesibilidad TCP/25 desde fuera de tu red. Ajusta firewall, grupos de seguridad en la nube y conectores/whitelists del proveedor.

3) Síntoma: Rebotes que dicen “Recipient address rejected” tras el corte

Causa raíz: Dominio no verificado/aceptado totalmente en la plataforma nueva; reglas de enrutamiento mal configuradas; buzón no aprovisionado aún.

Solución: Confirma dominios aceptados, aprovisionamiento de destinatarios y políticas catch-all/alias. Prueba RCPT TO contra múltiples destinatarios.

4) Síntoma: El correo “funciona” pero ahora cae en spam o es rechazado por receptores estrictos

Causa raíz: SPF no actualizado para el nuevo saliente, DKIM no firma o falta selector, DMARC en alineación estricta rechaza.

Solución: Actualiza SPF para incluir los nuevos emisores, publica selectores DKIM, verifica la firma y relaja temporalmente DMARC durante la transición.

5) Síntoma: Usuarios internos ven MX nuevo; socios externos ven MX antiguo

Causa raíz: Tu DNS interno difiere del público (split-horizon) o reenvíos internos sobreescriben el DNS público.

Solución: Asegura que el DNS interno refleje el MX público o se gestione deliberadamente. Durante el corte, evita vistas inconsistentes a menos que estés haciendo enrutamiento por fases intencionalmente.

6) Síntoma: Clientes Outlook/móviles fallan durante el corte aunque la entrega SMTP funcione

Causa raíz: Registros autodiscover/autoconfig aún apuntan a endpoints antiguos; TTL demasiado alto en CNAME/SRV.

Solución: Escalona TTL y actualiza registros de configuración de cliente. Prueba desde dispositivos/networks limpios.

7) Síntoma: Tras cambiar MX, parte del correo desaparece “en el éter”

Causa raíz: El sistema antiguo acepta pero almacena localmente; no hay reenvío/relé; los usuarios dejan de consultar el buzón antiguo.

Solución: Configura el entrante antiguo para relé a lo nuevo durante la transición. Comunica el acceso a los buzones antiguos hasta que el tráfico cese.

Chiste #2: Lo único más persistente que la caché DNS es un directivo que “solo quiere una actualización rápida” durante un incidente.

Listas de verificación / plan paso a paso

Fase 1: Inventario y escalonado (haz esto con antelación)

Lista todos los registros que vas a cambiar: MX, SPF TXT, DKIM TXT, DMARC TXT, autodiscover CNAME/SRV, cualquier gateway entrante.
Registra los TTL actuales y calcula tu ventana de escalonado (el TTL antiguo es la espera mínima antes de que aparezcan los beneficios).
Baja los TTL a 300 segundos en esos registros.
Verifica que el DNS autoritativo esté sirviendo el nuevo TTL (consulta @nameserver, no la caché de tu portátil).
Verifica que múltiples resolutores externos convergen en el TTL más bajo con el tiempo.

Fase 2: Verificación pre-corte (demuestra que el sistema nuevo funciona)

Confirma que los endpoints MX nuevos aceptan TCP/25 y presentan banners SMTP válidos.
Realiza una transacción SMTP controlada a un destinatario de prueba.
Verifica el rastro de mensajes en la plataforma nueva que muestre aceptado y entregado.
Asegura que la plataforma antigua pueda permanecer en línea para recibir/reenviar correo durante la transición.
Prepara la reversión: valores MX antiguos exactos, TTLs y la persona autorizada para ejecutar.

Fase 3: Ejecución del corte (mantén pequeño el radio del impacto)

Cambia MX al nuevo proveedor mientras el TTL está bajo.
Consulta inmediatamente la autoridad y múltiples resolutores para confirmar que las respuestas nuevas están activas.
Envía correos de prueba desde al menos dos fuentes externas (buzón personal + un servicio que controles).
Observa logs del sistema antiguo por tráfico entrante; si todavía recibe, reenvía/forwardea.
Registra fallos: timeouts, rechazos 5xx, colocación en spam. Arregla lo más grave primero (habitualmente accesibilidad o políticas de aceptación).

Fase 4: Estabilización y limpieza (no dejes aristas cortantes)

Una vez estable, sube el TTL a 1800–3600 segundos (o tu estándar).
Revisa la política DMARC si la relajaste; endurece gradualmente.
Mantén el entrante antiguo activo el tiempo suficiente para capturar reintentos y rezagados; luego desmantela deliberadamente.
Escribe lo aprendido: línea temporal real de propagación, resolutores tercos y qué monitorización funcionó.

Preguntas frecuentes

1) Si bajo el TTL a 300 segundos, ¿garantiza que el corte se complete en 5 minutos?

No. Significa que las cachés pueden mantener respuestas durante 5 minutos después de obtenerlas. Si un resolutor obtuvo la respuesta justo antes de que bajaras el TTL, puede mantener la respuesta antigua durante la duración del TTL antiguo. Por eso escalonas con antelación.

2) ¿Con cuánta antelación debo bajar el TTL?

Al menos el TTL actual, más un margen. Si el TTL MX es 3600, bájalo al menos un día antes de un corte mayor para no competir con cachés aleatorios. Para TTLs muy largos (8–24 horas), programa una semana antes y duerme mejor.

3) ¿Debo bajar TTL para SPF/DKIM/DMARC también?

Si planeas cambiarlos durante la ventana de migración, sí. Los fallos de autenticación raramente parecen “caída”, pero sí parecen “el correo dejó de llegar”, que es casi lo mismo.

4) ¿Qué valor de TTL debería usar durante el corte?

300 segundos es un buen predeterminado. Ve más bajo solo si tienes una razón específica y confías en tu proveedor DNS bajo carga.

5) ¿Puedo “forzar la propagación DNS” cambiando registros varias veces?

No. Los cambios repetidos pueden crear oscilación donde diferentes cachés mantienen respuestas distintas. Haz un cambio planificado, verifica la autoridad y deja que las cachés expiren naturalmente.

6) Si el correo se retrasa tras el corte, ¿siempre es DNS?

Ni siquiera cerca. Reintentos SMTP, greylisting, rechazos por políticas entrantes, problemas de negociación TLS y filtrado antispam pueden crear retrasos. El DNS es solo lo primero que debes probar o eliminar.

7) ¿Cuál es el plan de reversión más seguro para cambios de MX?

Mantén los valores MX antiguos y asegúrate de que el sistema antiguo pueda seguir aceptando correo. Con TTL escalonado bajo, revertir es rápido.
Sin escalonado, la reversión puede tardar tanto como el corte—a veces más, porque ahora las cachés están mezcladas.

8) ¿Necesito coordinar con socios o grandes remitentes?

Si tienes socios clave que envían correo de alto valor (bancos, nóminas, sistemas de tickets), infórmales de la ventana de corte.
También pregúntales si tienen rutas codificadas. Algunos sistemas legacy literalmente almacenan el nombre host MX en su configuración.

9) ¿Qué pasa en entornos on-prem con DNS interno split-horizon?

Decide si los usuarios internos deben seguir el MX público o una ruta distinta. Si el DNS interno es diferente, documéntalo y pruébalo. El split-horizon está bien cuando es intencional y doloroso cuando es accidental.

10) ¿Cuándo debo subir el TTL otra vez?

Tras observar una entrega entrante estable y confirmar que el tráfico rezagado al sistema antiguo está cerca de cero
(o al menos se reenvía de forma segura). Típicamente 24–72 horas post-corte es conservador y sensato.

Conclusión: próximos pasos que te mantienen empleado

El escalonado de TTL no es un truco. Es higiene operativa básica. Si lo haces con antelación, tu corte de MX se convierte en un cambio controlado
con una ventana de convergencia corta y una reversión real. Si lo omites, te apuntas a entrega partida, confusión y una llamada de incidente
donde todos discuten sobre “propagación” como si fuera el clima.

Pasos prácticos:

Ahora mismo: ejecuta dig y registra tu TTL MX actual.
Hoy: baja TTL a 300 segundos para cada registro relacionado con correo que esperas cambiar.
Mañana: verifica respuestas autoritativas y compara múltiples resolutores.
Día del corte: cambia MX una vez, prueba aceptación SMTP y monitoriza rutas entrantes antiguas y nuevas.
Después: sube el TTL, luego limpia autenticación y desmantela el entrante antiguo deliberadamente.