Migración de correo electrónico: el plan sin tiempo de inactividad que no pierde mensajes

Qué significa realmente “sin tiempo de inactividad” para el correo

“Sin tiempo de inactividad” en correo no significa “sin cambios”. Significa que la experiencia del usuario permanece continua mientras se cambia la infraestructura debajo. Los usuarios siguen recibiendo correo. Pueden enviar correo. Sus clientes siguen autenticándose. Y si algo sale mal, puedes revertir sin dejar caer mensajes al suelo.

La parte difícil es que el correo no es un único protocolo o un único servidor. Es un conjunto de contratos:

• Contrato de entrega entrante: Internet sabe dónde entregar correo para tu dominio vía MX, y los receptores confían en ti vía SPF/DKIM/DMARC.
• Contrato de envío saliente: tus usuarios y aplicaciones pueden enviar mensajes, y tus IPs/dominios de salida no están en listas negras.
• Contrato de acceso a buzón: clientes IMAP/POP/ActiveSync/REST pueden autenticarse y encontrar las mismas carpetas y mensajes que ayer.
• Contrato de identidad: direcciones, alias, grupos y permisos significan lo mismo antes y después de la migración.
• Contrato de cumplimiento: retención, journal, retenciones legales y registros de auditoría permanecen intactos.

La mayoría del “correo perdido” durante migraciones no está verdaderamente perdido. Está mal dirigido, rechazado, puesto en cuarentena, duplicado o entregado en un buzón que el usuario ya no revisa. Eso se puede arreglar, pero solo si diseñas para observabilidad y para poder revertir.

Aquí tienes la definición operacional más simple que resiste en las revisiones de incidentes:

• No pérdida de mensajes: cada mensaje aceptado por cualquiera de tus sistemas puede ser contabilizado y entregado una sola vez (o duplicado intencionalmente con trazabilidad).
• No corte drástico el primer día: mantienes la coexistencia el tiempo suficiente para demostrar la corrección del enrutamiento y la sincronización.
• Rollback real: puedes revertir el enrutamiento entrante y saliente sin reconfigurar cada cliente en la empresa.

Una cita para mantener a tu equipo honesto, porque las migraciones son básicamente gestión de riesgo con invitaciones a reuniones más agradables:

“La esperanza no es una estrategia.” — Gen. Gordon R. Sullivan

Broma corta #1: Lo único más permanente que una solución temporal de migración es la invitación de calendario que sigue reprogramándose.

Modelos de migración que realmente funcionan (y cuándo usarlos)

1) Corte total de una vez (evítalo a menos que tengas un dominio pequeño)

Este es el clásico enfoque “cambia el MX y reza”. Puede funcionar para una organización pequeña con bajo volumen de correo y un perfil de clientes simple. En entornos de producción con necesidades de cumplimiento, es pedir una avalancha de tickets de incidentes.

Úsalo solo cuando: tienes unas pocas docenas de buzones, sin enrutamiento complejo, sin emisores externos que no controles y puedes aceptar una ventana corta de riesgo en el flujo de correo.

2) Migración por fases con coexistencia (la opción por defecto para los adultos)

Algunos usuarios (o grupos) se mueven primero. El enrutamiento entre sistemas viejo y nuevo se mantiene correcto en ambas direcciones. Los buzones se sincronizan con antelación. Pruebas de extremo a extremo se ejecutan repetidamente.

Úsalo cuando: tienes desde cientos hasta decenas de miles de buzones, múltiples dominios, buzones compartidos, delegados o un helpdesk serio.

3) Entrega dual (cinturón y tirantes para el correo entrante)

El correo entrante se entrega a ambos sistemas durante un periodo. De ese modo, incluso si un usuario consulta el “buzón equivocado” durante la transición, el mensaje existe en ambos lugares.

Úsalo cuando: toleras duplicados temporales y tienes un plan para reconciliarlos (o aceptarlos como un coste operativo).

4) Estrategia de gateway/re-enrutamiento (útil cuando controlas los bordes SMTP)

Mantienes un gateway SMTP entrante estable (o usas un gateway de seguridad de correo) y direccionas la entrega a viejo vs nuevo según la ubicación del destinatario. MX se mantiene estable; tu enrutamiento interno cambia. Esto reduce el drama de propagación DNS y ofrece mejor rollback.

Úsalo cuando: ya tienes una capa de gateway, o puedes construir una sin empeorar todo.

5) Híbrido/coexistencia vía herramientas del proveedor (funciona, pero verifica las suposiciones)

Las configuraciones híbridas de Microsoft 365 y las herramientas de migración de Google Workspace pueden ser sólidas. También pueden ocultar las palancas operativas que necesitas al solucionar problemas. Trátalas como automatización, no como garantía de corrección.

Úsalo cuando: tienes fuertes necesidades de integración de directorio, quieres transiciones suaves de clientes y puedes invertir tiempo en verificar mailflow y mapeo de identidades.

Hechos interesantes y contexto histórico (para que dejes de repetir la historia)

• Los registros MX llegaron a mediados de los 80 para permitir que los dominios especifiquen intercambiadores de correo, reemplazando antes la suposición de “simplemente usa el nombre del host” en la era temprana de SMTP.
• SMTP precede a la autenticación moderna; fue diseñado para una red más pequeña y confiada. Por eso gran parte de la “fiabilidad del correo” actual se añadió después.
• MIME (principios de los 90) es la razón por la que los adjuntos y el contenido enriquecido funcionan entre sistemas. Las migraciones que rompen el manejo MIME “funcionarán” hasta que alguien reenvíe un PDF firmado.
• IMAP se convirtió en el protocolo preferido para buzones almacenados en servidor; es flexible pero fácil de manejar mal durante la migración debido a banderas, UID validity y semántica de carpetas.
• SPF (2000s) redujo la suplantación simple publicando qué servidores pueden enviar por un dominio, pero puede romper emisores legítimos que olvidaste que existían.
• DKIM (2000s) hizo la reputación portátil firmando mensajes; los cortes que cambian selectores/keys pueden hundir la entregabilidad por días si no se hacen por fases.
• DMARC (2010s) dio dientes a la política (reject/quarantine), pero políticas estrictas convierten una pequeña mala configuración en un apagón total del correo.
• El greylisting fue una vez popular como táctica anti-spam; puede amplificar la “lentitud” percibida en una migración porque nuevas IPs parecen sospechosas y son deferidas.
• Los grandes proveedores ahora usan señales de engagement (aperturas, respuestas, quejas de spam) como parte de la reputación; una migración que cambia patrones de envío puede activar filtrado incluso con DNS correcto.

La arquitectura de un movimiento seguro: coexistencia, enrutamiento e identidad

Comienza con invariantes: lo que no debe cambiar

Antes de tocar MX, decide qué permanece estable durante la ventana de migración:

• Direcciones de usuario: las direcciones SMTP primarias no deben cambiar. Los alias no deben desaparecer.
• Nombre de host entrante y postura TLS: si puedes mantener el mismo nombre MX (con un fronting por un gateway), hazlo.
• Identidad saliente: mantiene los patrones de envelope-from y header-from tanto como sea posible.
• Directorio como fuente de la verdad: un sistema es autoritativo para la existencia de buzones y atributos de enrutamiento en cualquier momento.

Estrategia de enrutamiento: el direccionamiento por destinatario vence a la ruleta DNS

DNS es caché global con actitudes. Incluso cuando TTL es bajo, los resolvers te ignoran, los middleboxes reescriben cosas y algunos emisores cachean agresivamente. Un gateway SMTP estable te permite enrutar por destinatario:

• Si el destinatario está migrado: entregar a la nueva plataforma.
• Si no lo está: entregar al sistema antiguo.
• Si hay duda: poner en cola de forma segura, no rebotar.

Así obtienes un rollback real: cambias un mapa de enrutamiento, no el DNS público.

Coexistencia: el superpoder poco glamuroso

La coexistencia no es una casilla. Es un periodo donde demuestras:

• Correo desde internet → usuarios migrados cae en el nuevo buzón.
• Correo desde internet → usuarios no migrados cae en el buzón antiguo.
• Correo entre usuarios viejo ↔ nuevo se comporta normalmente, incluyendo cadenas de respuesta e invitaciones de calendario si aplican.
• Alias, grupos, buzones compartidos y delegados siguen funcionando.

Identidad y auth: estás migrando confianza, no solo datos

El acceso al correo está pegado a la identidad. Si cambias la auth (nuevo IdP, nuevo MFA, nuevo acceso condicional), hazlo como un proyecto separado a menos que disfrutes depurar múltiples variables caóticamente.

Mi sesgo: estabiliza la identidad primero, luego migra los buzones. O migra los buzones primero manteniendo la identidad estable. No hagas ambos simultáneamente a menos que tengas un laboratorio que replique producción y tiempo para usarlo.

Realidad del almacenamiento: los buzones son conjuntos de datos, no sensaciones

Los almacenes de buzones se comportan como bases de datos. El rendimiento de la migración depende de:

• IOPS y latencia en los almacenes origen y destino
• Comportamiento de indexación y reconstrucción de búsquedas
• Límites de concurrencia (por usuario, por tenant, por conector)
• Throughput de red y pérdida de paquetes
• Políticas de throttling (especialmente en SaaS)

Si quieres cero tiempo de inactividad, diseña para colas y reintentos, y asume que serás rate-limited.

Listas de verificación / plan paso a paso: el corte por fases

Fase 0: Decide tus criterios de éxito de la migración (ponlos por escrito)

• El correo entrante aceptado nunca se pierde; en el peor caso queda en cola y se entrega tarde.
• La entregabilidad saliente se mantiene dentro de una tolerancia acordada (rebotes, spam, retrasos).
• Los usuarios pueden acceder a los buzones mediante los clientes acordados (escritorio, móvil, web).
• Los controles de cumplimiento (journaling, retenciones legales, retención) siguen siendo efectivos.
• Rollback: inbound y outbound pueden revertirse dentro de una ventana temporal definida.

Fase 1: Inventario y mapeo de dependencias (la parte que la gente se salta)

• Lista todos los dominios y subdominios que envían o reciben correo.
• Identifica todas las rutas entrantes: directo a MX, vía gateway de seguridad, vía filtrado en la nube.
• Identifica emisores salientes: envío por usuario, relés SMTP, apps, impresoras, sistemas de monitorización.
• Catálogo de buzones compartidos, grupos, alias, buzones de recursos y delegados.
• Exporta una lista de usuarios “especiales”: asistentes ejecutivos, legal, finanzas, colas de soporte.
• Documenta SPF/DKIM/DMARC existentes y cualquier emisor tercero.

Fase 2: Construye el enrutamiento de coexistencia

• Despliega o configura tu borde SMTP estable (gateway) si es posible.
• Implementa enrutamiento por destinatario hacia lo viejo o lo nuevo.
• Establece tiempos de vida de cola conservadores y backoff en los reintentos en el gateway.
• Activa logging con IDs de mensaje que permitan trazar de extremo a extremo.

Fase 3: Migra identidades y objetos (antes que los datos de correo)

• Provisiona usuarios habilitados para correo en destino con direcciones primarias/alias correctas.
• Recrea buzones compartidos, grupos, recursos y mapeos de permisos.
• Configura atributos de enrutamiento de buzón (o mapas de enrutamiento) para que la coexistencia sepa dónde entregar.
• Prueba rutas de autenticación con un grupo piloto.

Fase 4: Pre-semilla de datos de buzón (copia masiva mientras los usuarios siguen trabajando)

• Ejecuta sincronización inicial del correo histórico y calendarios si aplica.
• Espera que esto tome más tiempo y sufra más throttling.
• Mide throughput; ajusta concurrencia; no sobrecargues el servidor origen.
• Verifica recuentos de carpetas, recuentos de elementos y revisa la integridad de mensajes al azar.

Fase 5: Corte piloto (radio de impacto pequeño)

• Selecciona usuarios piloto a través de roles, no solo IT.
• Haz el cambio de enrutamiento para los pilotos (no todo el dominio).
• Cambia la autodetección/configuración de cliente para los pilotos.
• Monitorea retrasos, rebotes y anomalías reportadas por usuarios al menos un día hábil completo.

Fase 6: Migraciones por oleadas (repetible, aburrido, controlado)

• Migra por oleadas dimensionadas según tu capacidad de soporte y throttling de la plataforma.
• Ejecuta sincronización delta cerca del corte de cada oleada.
• Mantén el enrutamiento de coexistencia hasta que la última oleada sea estable.
• Mantén el sistema antiguo recibiendo (o al menos encolando) hasta tener confianza y copias de seguridad.

Fase 7: Corte a nivel de dominio (si es necesario)

• Sólo después de que la coexistencia haya demostrado ser correcta.
• Reduce TTL con antelación, pero asume que no te salvará en todas partes.
• Cambia MX y actualiza SPF/DKIM/DMARC deliberadamente y por etapas.
• Mantén el MX antiguo (o gateway) capaz de aceptar correo por un tiempo para atrapar rezagados.

Fase 8: Desmantelamiento seguro

• Congela cambios y mantén acceso de solo lectura a los buzones antiguos por un periodo acordado.
• Exporta logs finales e informes de migración.
• Confirma comportamiento de retención y retenciones legales en destino.
• Desmantela en pasos: receptor entrante al final, almacenamiento al final, DNS al final.

Tareas prácticas con comandos: verificar, decidir, proceder

Estas son las tareas que te mantienen fuera de reuniones de estado donde nadie tiene datos. Cada una incluye: comando, qué significa la salida y la decisión que tomas.

Tarea 1: Comprueba los registros MX actuales y lo que ve el mundo

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

Significado: MX apunta al sistema antiguo, TTL es 300 segundos. Ese TTL es orientativo, no una promesa.

Decisión: Si planeas cambiar MX, reduce el TTL con días de antelación y asegúrate de que los hosts antiguos seguirán aceptando correo durante la propagación.

Tarea 2: Valida el TTL de DNS para MX y registros relacionados antes de cambiar nada

cr0x@server:~$ dig example.com MX +noall +answer
example.com.           3600    IN      MX      10 mx-gw.example.com.

Significado: TTL es 3600 segundos (1 hora). Algunos emisores cachearán más tiempo igualmente.

Decisión: Si quieres una ventana de corte más estrecha, reduce el TTL ahora y espera al menos el TTL antiguo (preferiblemente 24–48 horas) antes de cambiar MX.

Tarea 3: Inspecciona SPF para encontrar emisores terceros que romperás

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.vendor-a.example include:_spf.vendor-b.example -all"

Significado: Tienes al menos tres fuentes de envío: una IP y dos includes.

Decisión: Inventorya qué representa cada include. Si cambias el saliente, asegúrate de que las nuevas IPs/hosts estén incluidas o verás fallos silenciosos de entregabilidad.

Tarea 4: Comprueba el nivel de política DMARC (porque las políticas estrictas magnifican errores)

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

Significado: DMARC está en reject, con alineamiento estricto. Bueno para seguridad, implacable para migraciones.

Decisión: Si no puedes garantizar alineamiento DKIM durante la transición, planifica una relajación temporal de la política (con cuidado) o usa un gateway que mantenga el firmado de forma consistente.

Tarea 5: Verifica el certificado TLS servido por tu endpoint SMTP entrante

cr0x@server:~$ echo | openssl s_client -starttls smtp -connect mx-gw.example.com:25 -servername mx-gw.example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates
subject=CN = mx-gw.example.com
issuer=CN = Example Intermediate CA
notBefore=Jan  5 00:00:00 2026 GMT
notAfter=Apr  5 23:59:59 2026 GMT

Significado: El certificado es válido y no expira mañana. TLS importa para entregabilidad y gateways de seguridad.

Decisión: Si el certificado está mal/expirado, arréglalo antes del corte. Si no, depurarás “problemas aleatorios de entrega” que en realidad son fallos TLS.

Tarea 6: Confirma que tu gateway (Postfix) está encolando de forma segura, no rebotando prematuramente

cr0x@server:~$ postconf | egrep 'maximal_queue_lifetime|bounce_queue_lifetime|minimal_backoff_time|maximal_backoff_time'
maximal_queue_lifetime = 5d
bounce_queue_lifetime = 1d
minimal_backoff_time = 300s
maximal_backoff_time = 4000s

Significado: Los mensajes pueden permanecer en cola hasta 5 días. Los rebotes ocurren después de 1 día para correo no entregable.

Decisión: Durante la migración, prefiere tiempo de vida de cola más largo y menos rebotes. Si el destino tiene un problema temporal, quieres retrasos, no NDRs.

Tarea 7: Observa la profundidad de la cola de correo durante las oleadas de migración

cr0x@server:~$ mailq | tail -n 5
-- 25 Kbytes in 12 Requests.
-- 18 Kbytes in 9 Requests.
-- 302 Kbytes in 140 Requests.
-- 1.8 Mbytes in 820 Requests.
-- 6.2 Mbytes in 2900 Requests.

Significado: La cola está creciendo. Si sigue creciendo, tu downstream es lento o está rechazando.

Decisión: Si el crecimiento de la cola se correlaciona con una oleada de corte, pausa las migraciones, inspecciona errores downstream y protege la aceptación entrante.

Tarea 8: Encuentra por qué el correo está atascado (razones de deferimiento)

cr0x@server:~$ grep -E 'status=deferred|status=bounced' /var/log/mail.log | tail -n 6
Feb  4 10:11:02 mx-gw postfix/smtp[23144]: 9A2C11234: to=<user@example.com>, relay=new-mx.example.net[198.51.100.20]:25, delay=1220, delays=0.2/0.1/900/320, dsn=4.2.0, status=deferred (host new-mx.example.net[198.51.100.20] said: 451 4.2.0 Temporary server error)
Feb  4 10:11:07 mx-gw postfix/smtp[23146]: 8BCDE1234: to=<user2@example.com>, relay=new-mx.example.net[198.51.100.20]:25, delay=980, delays=0.1/0.1/600/380, dsn=4.7.0, status=deferred (host new-mx.example.net[198.51.100.20] said: 421 4.7.0 Too many connections)

Significado: El destino está haciendo throttling o devolviendo errores temporales (451/421). Tu gateway está haciendo lo correcto al deferir.

Decisión: Reduce concurrencia hacia el destino y coordina con los límites de la plataforma destino; no “arregles” esto rebotando.

Tarea 9: Verifica la ruta de salida y la identidad (qué servidor está enviando realmente)

cr0x@server:~$ grep -R "relayhost" /etc/postfix/main.cf
relayhost = [smtp-out.newplatform.example.net]:587

Significado: El saliente se relaya a un endpoint de envío de la nueva plataforma.

Decisión: Asegura que SPF incluya el nuevo saliente, verifica que DKIM firme correctamente y vigila límites de tasa o errores de autenticación.

Tarea 10: Comprueba que tu IP saliente coincide con lo que verán los receptores (sanity básica)

cr0x@server:~$ curl -s ifconfig.me
203.0.113.55

Significado: Esta es la IP pública del host desde el que pruebas (útil si este host envía correo directamente).

Decisión: Si la IP saliente cambió, actualiza SPF y considera una estrategia de warm-up; una IP fría con alto volumen es filtrada.

Tarea 11: Verifica la lista de carpetas IMAP en origen (lo que debes preservar)

cr0x@server:~$ doveadm mailbox list -u alice@example.com | head
INBOX
Archive
Drafts
Sent
Trash
Projects
Projects/2025

Significado: La estructura de carpetas existe; las carpetas anidadas importan. Los usuarios notarán si “Projects/2025” se convierte en “Projects.2025” o desaparece.

Decisión: Configura tu herramienta de migración para preservar la jerarquía y carpetas de uso especial; prueba con buzones reales y desordenados, no con los ordenados de IT.

Tarea 12: Confirma recuentos de mensajes en carpetas clave (spot-check, no confíes en resúmenes)

cr0x@server:~$ doveadm mailbox status -u alice@example.com messages INBOX Archive Sent
INBOX messages=18421
Archive messages=90211
Sent messages=13105

Significado: Recuentos base. No perfectos (banderas y duplicados pueden sesgar), pero buenos para detectar discrepancias groseras.

Decisión: Si los recuentos en destino son mucho menores, no cortes a ese usuario. Investiga throttling, carpetas excluidas o límites de tamaño.

Tarea 13: Verifica que un mensaje específico exista por Message-ID (la forma forense)

cr0x@server:~$ doveadm search -u alice@example.com mailbox INBOX header Message-ID "<CA+abc123@example.net>" | head
1

Significado: El resultado “1” indica que se encontró un UID de mensaje coincidente. Si está vacío, no está en ese buzón/carpeta.

Decisión: Usa búsquedas por Message-ID para demostrar si el correo falta o está entregado en otro lado. Así evitas discusiones en la sala de incidentes.

Tarea 14: Vigila disco y presión de IO en el almacén origen (la migración puede DoS tu propio almacenamiento)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (mailstore01)  02/04/2026  _x86_64_  (16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.10    0.00    5.80   28.30    0.00   53.80

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         820.0  1200.0 84500.0 91000.0  8.20   0.40  82.0

Significado: iowait es alto; utilización del dispositivo alta. Await de 8ms puede estar bien o no dependiendo de tu almacén, pero aumentar await durante la migración es una señal roja.

Decisión: Si %iowait sube y los usuarios se quejan, reduce la concurrencia de migración o programa sincronizaciones masivas fuera de horario. Protege el acceso al correo de producción primero.

Tarea 15: Confirma que el servidor antiguo sigue aceptando correo tras el corte (siempre hay rezagados)

cr0x@server:~$ swaks --to user@example.com --server mx1.oldmail.example.com --from external-test@sender.example --data "Subject: old-mx test"
=== Trying mx1.oldmail.example.com:25...
=== Connected to mx1.oldmail.example.com.
<= 220 mx1.oldmail.example.com ESMTP
=> EHLO mailtester
<= 250-mx1.oldmail.example.com
=> MAIL FROM:<external-test@sender.example>
<= 250 2.1.0 Ok
=> RCPT TO:<user@example.com>
<= 250 2.1.5 Ok
=> DATA
<= 354 End data with <CR><LF>.<CR><LF>
=> .
<= 250 2.0.0 Ok: queued as 12345ABCDE

Significado: El MX antiguo sigue aceptando y poniendo en cola. Bien: puede reenviar, relayer o mantener durante la propagación.

Decisión: Mantén esta capacidad hasta estar seguro de que todos los emisores se han movido. No desmanteles el borde antiguo solo porque tu portátil resuelve el nuevo MX.

Tarea 16: Valida que los cambios DNS se han propagado en varios resolvers

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do echo "Resolver $r"; dig @$r +short example.com MX; done
Resolver 1.1.1.1
10 mx-gw.example.com.
Resolver 8.8.8.8
10 mx-gw.example.com.
Resolver 9.9.9.9
10 mx1.oldmail.example.com.
20 mx2.oldmail.example.com.

Significado: Diferentes resolvers ven distintos MX. Esto es normal durante la propagación. También es por qué “girar MX a las 21:00” no es un plan real.

Decisión: Mantén aceptación dual y reenvío. No asumas que la vista de un solo resolver representa a internet.

Guía de diagnóstico rápido: encuentra el cuello de botella en minutos

Las migraciones de correo no fallan de forma creativa. Fallan de manera predecible: confusión DNS, bucles de enrutamiento, throttling, deriva de autenticación o sobrecarga de almacenamiento. Cuando los usuarios dicen “el correo está roto”, tu trabajo es identificar primero qué contrato está roto.

Primero: ¿se acepta correo entrante en algún sitio?

1. Comprueba logs del gateway o MX para conexiones nuevas y si los mensajes son aceptados (250) o rechazados (5xx).
2. Comprueba la profundidad de la cola. Si la aceptación entrante está bien pero la cola explota, el problema es downstream.
3. Envía un mensaje de prueba controlado desde una fuente externa usando una herramienta como swaks y captura el ID de cola.

Qué te dice esto: ¿Estás perdiendo mensajes en el borde (rechazos) o retrasándolos (defer/cola)? Los retrasos son sobrevivibles; los rechazos dañan la reputación.

Segundo: ¿está correcto el enrutamiento para un destinatario específico?

1. Elige un usuario afectado y determina si está “migrado” según tu mapa de enrutamiento/atributo de directorio.
2. Traza un mensaje por Message-ID a través de logs y búsqueda de buzón en ambos lados.
3. Busca bucles: patrones gateway → nuevo → antiguo → gateway aparecen como cabeceras Received repetidas o intentos de cola repetidos.

Qué te dice esto: Si la lógica de enrutamiento de coexistencia está mal, desactualizada o inconsistente.

Tercero: ¿está el destino limitando o fallando?

1. Busca ráfagas de 4xx SMTP como 421 demasiadas conexiones, 451 errores temporales, 452 almacenamiento insuficiente, 4.7.x límites de tasa.
2. Mide latencia (desglose de retraso en la cola) en los logs del gateway.
3. Revisa dashboards de salud del destino si están disponibles, pero confía primero en tu propia telemetría.

Qué te dice esto: Si debes pausar migraciones, reducir concurrencia o escalar al proveedor destino.

Cuarto: ¿está cayendo la entregabilidad saliente?

1. Inspecciona respuestas SMTP de dominios receptores por bloqueos, fallos de política o fallos de autenticación.
2. Comprueba alineamiento SPF/DKIM en una muestra de mensajes salientes.
3. Confirma señales de reputación IP/dominio mediante tus logs de rebote y feedback loops si los tienes.

Qué te dice esto: Si tienes un desajuste de autenticación o un cambio de patrón de reputación/volumen.

Quinto: ¿fallan los clientes (auth/autodiscover) en lugar del flujo de correo?

1. Revisa logs de autenticación por bloqueos de MFA/acceso condicional.
2. Confirma que autodiscover o endpoints de configuración resuelven al tenant/servicio correcto.
3. Prueba con webmail para aislar la configuración del cliente de problemas del servidor.

Qué te dice esto: Si el buzón existe y el correo fluye, pero los clientes no lo encuentran, tu problema es identidad/configuración, no SMTP.

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

1) Síntoma: “Algunos emisores no nos alcanzan, otros sí” tras el corte de MX

Causa raíz: Variación en la propagación DNS y caché de resolvers; MX antiguo desmantelado demasiado pronto; algunos emisores aún apuntan al MX antiguo.

Solución: Mantén el MX antiguo aceptando y reenviando durante un solapamiento definido. Si es posible, mantén MX apuntando a un gateway estable y enruta internamente por destinatario.

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

Causa raíz: Throttling del destino (421/451/4.7.x), demasiada entrega concurrente o comportamiento de greylisting activado por nueva IP/host.

Solución: Reduce la concurrencia SMTP y ajusta intervalos de reintento. Si controlas el gateway, implementa límites por dominio. No rebotes; encola.

3) Síntoma: El correo saliente llega a spam tras la migración, aunque SPF pasa

Causa raíz: DKIM ausente o desalineado; DMARC fallando; reputación de IP de envío reiniciada; cambio de HELO/EHLO y mismatch de rDNS.

Solución: Estabiliza el firmado DKIM y la alineación. Asegura rDNS/HELO coherentes. Incrementa volumen gradualmente en lugar de lanzar desde IP fría.

4) Síntoma: Usuarios reportan carpetas faltantes o “Enviados” vacío

Causa raíz: Diferencias en el mapeo de carpetas; flags de uso especial no preservadas; herramienta de migración excluyó carpetas; cliente está conectado a un perfil nuevo y vacío.

Solución: Verifica mapeo de carpetas de uso especial (Sent/Drafts/Trash). Prueba con un buzón con anidamiento profundo y nombres no ASCII. Fuerza la actualización del perfil del cliente sólo después de que los datos estén presentes.

5) Síntoma: Algunos correos internos entre usuarios viejo y nuevo rebotan

Causa raíz: Coexistencia de enrutamiento faltante para subdominios o alias; el directorio muestra “ubicación de buzón” incorrecta; reglas de conectores incompletas.

Solución: Implementa enrutamiento determinista: si el destinatario está migrado, enruta a nuevo; si no, a viejo. Asegura que alias y expansión de grupos ocurran en el sistema correcto.

6) Síntoma: Mensajes entrantes duplicados para usuarios migrados

Causa raíz: Entrega dual habilitada sin plan de desduplicación; reglas de reenvío en el sistema antiguo; usuarios con clientes POP que descargan y borran de forma inconsistente.

Solución: Elige un mecanismo de entrega dual (copia en gateway o journaling), no tres. Desactiva reenvíos a nivel de usuario durante la transición si es factible. Comunica claramente sobre POP.

7) Síntoma: La herramienta de migración dice “completado”, pero los usuarios no encuentran correo

Causa raíz: “Completado” significa “no se descubrieron más elementos en el último escaneo”, no “corrección visible por el usuario”. También: algunos sistemas excluyen archivos/archivos históricos por defecto.

Solución: Valida con recuentos de mensajes, listas de carpetas y búsquedas por Message-ID. Incluye archivos explícitamente en el alcance.

8) Síntoma: Acceso a buzón compartido falla para delegados

Causa raíz: Modelos de permisos diferentes; derechos de delegado no migrados; automapping/autodiscover cambió; permisos basados en grupos no sincronizados.

Solución: Exporta y reaplica permisos como un flujo de migración separado. Prueba con escenarios de asistente ejecutivo. Haz los cortes de buzones compartidos explícitos, no accidentales.

Tres microhistorias corporativas desde las trincheras de migración

Microhistoria 1: El incidente causado por una suposición equivocada

Tenían un plan que lucía bien en una diapositiva: reducir TTL, cambiar MX, monitorizar, celebrar. La suposición fue que un TTL de 300 segundos significaba que la mayoría de emisores cambiarían en pocos minutos. Esa suposición pertenece al mismo museo que “nadie usa fax ya”.

Sus servidores entrantes antiguos se apagaron temprano porque la nueva plataforma recibía correo y las pruebas internas parecían limpias. Entonces comenzó el problema: un puñado de socios externos críticos — grandes empresas con caché de resolvers conservadora y MTAs configurados por alguien que se jubiló en 2012 — seguían entregando al MX antiguo. Esas entregas empezaron a fallar de forma permanente.

Los reportes del helpdesk fueron extrañamente específicos: “El proveedor A no puede enviar a AP”, “El banco B dice que los mensajes rebotan”, mientras los demás estaban bien. El equipo pasó dos horas mirando la nueva plataforma porque “ahí ocurrió la migración”. La nueva plataforma era inocente.

La solución fue vergonzosamente simple: volver a poner el MX antiguo en línea, aceptar correo y reenviar al sistema nuevo. La parte dolorosa fue el golpe reputacional: los mensajes de rebote no solo hieren sentimientos, entrenan a los emisores a desconfiar de tu dominio.

Después del incidente, reconstruyeron alrededor de un gateway estable para que MX no tuviera que cambiar por oleada. La lección clave no fue “reduce TTL antes”. Fue “DNS es una pista; tu borde debe ser resiliente a emisores que no recibieron el memo”.

Microhistoria 2: La optimización que salió mal

Otra compañía quería que la migración fuera rápida. Aumentaron la concurrencia agresivamente: más hilos, más copias paralelas de buzones, lotes más grandes. Los dashboards se veían geniales por una hora. Entonces los servidores origen empezaron a arrastrarse.

Los usuarios se quejaron de que la búsqueda iba lenta, la apertura de mensajes tardaba y la interfaz web se timeouteaba. La herramienta de migración siguió reintentando tras fallos, lo que aumentó la carga. Un bucle de retroalimentación clásico: los errores crean reintentos, los reintentos crean carga, la carga crea más errores.

La capa de almacenamiento fue la víctima silenciosa. El almacén de buzones estaba en discos compartidos dimensionados para “uso normal”, no para una lectura masiva de cada buzón además de la actividad de usuarios. La latencia subió; las colas IO se profundizaron. La plataforma de correo no cayó, simplemente se volvió insoportable.

Intentaron “optimizar” más desactivando tareas de indexación y mantenimiento de fondo para liberar recursos. Eso ayudó a corto plazo y luego les pasó factura: los usuarios más tarde se quejaron de resultados de búsqueda incompletos y algunas carpetas parecían vacías hasta que la reindexación se puso al día.

Se recuperaron limitando la concurrencia de migración, programando sincronizaciones masivas fuera de horas y protegiendo explícitamente la QoS de producción. La optimización más valiosa fue aburrida: establece una tasa de migración segura y cúmplela, aunque extienda el calendario. Broma corta #2: Si crees que puedes “meter más hilos”, felicidades—has inventado un ataque de denegación de servicio contra tu propio correo.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Esta es menos dramática, que es el punto. El equipo construyó un gateway SMTP estable frente a ambos sistemas, viejo y nuevo. Mantuvieron una tabla de enrutamiento indexada por dirección de destinatario: viejo vs nuevo. También registraron cada decisión: aceptado, enrutado, diferido, entregado, rebotado.

Durante la oleada tres, ocurrió un evento de throttling en el lado del destino. Los mensajes empezaron a diferirse con respuestas 421. Los usuarios notaron retrasos para destinatarios recién migrados. Pero no hubo rebotes. No hubo pánico. El gateway encoló los mensajes con calma, como un adulto.

El ingeniero on-call ejecutó una inspección rápida de la cola, identificó el throttle del destino y redujo la concurrencia hacia la nueva plataforma. Pausaron la siguiente oleada. El backlog se drenó durante la noche. A la mañana siguiente, los usuarios tenían su correo; un puñado llegó tarde, pero nada desapareció.

Más tarde, legal solicitó prueba de que un mensaje específico enviado durante la ventana del incidente no se había perdido. El equipo sacó la línea de log del gateway con el ID de cola y la correlacionó con la confirmación de entrega del destino y la búsqueda por Message-ID en el buzón. Eso terminó la conversación de forma rápida y educada.

La conclusión: un gateway estable más un logging disciplinado no es emocionante. También convierte “creemos que falta correo” en “aquí está la cadena de custodia”.

Preguntas frecuentes

1) ¿Realmente se puede hacer una migración de correo sin tiempo de inactividad?

Sí, si defines correctamente el downtime: capacidad continua de enviar/recibir, más colas seguras durante problemas transitorios. Aún puedes tener algunos momentos de reconfiguración de clientes, pero el flujo de correo debe permanecer continuo.

2) ¿Debemos cambiar MX temprano o tarde?

Si puedes evitar cambiar MX usando un gateway estable, hazlo. Si debes cambiar MX, hazlo después de que la coexistencia esté probada y mantén el MX antiguo aceptando/reenviando para solapamiento.

3) ¿Cuánto tiempo debemos mantener el sistema antiguo funcionando?

Como mínimo: hasta la propagación DNS más una ventana de confianza definida por el negocio (a menudo semanas). Mantén la capacidad de aceptación/reenvío entrante más tiempo del que crees; el desmantelamiento de almacenamiento viene al final.

4) ¿Qué pasa con el “correo perdido” durante la ventana de migración?

La mayoría del “correo perdido” está mal dirigido o retrasado. Diseña para trazabilidad: IDs de cola del gateway, logs con Message-ID y la capacidad de buscar Message-ID en buzones en ambos lados.

5) ¿Vale la pena la entrega dual?

A veces. Reduce la posibilidad de que un mensaje exista solo en el “otro” buzón durante la transición. También crea duplicados y trabajo de limpieza. Si la usas, hazlo deliberadamente y por un tiempo limitado.

6) ¿Cuál es el mayor riesgo de entregabilidad durante la migración?

Los cambios en autenticación y reputación: DKIM roto o desalineado, inclusiones SPF faltantes para nuevos emisores o enviar gran volumen desde una IP/dominio frío. El correo puede “entregarse” pero quedar efectivo en spam.

7) ¿Cómo manejamos emisores terceros como CRMs y sistemas de tickets?

Haz inventario temprano, actualiza includes de SPF y decide si deben firmar DKIM con tu dominio o usar el propio. Prueba el alineamiento DMARC con tus políticas reales antes de cortar.

8) ¿Podemos migrar e cambiar identidades/MFA al mismo tiempo?

Puedes, pero multiplicas modos de fallo. Si quieres una migración tranquila, mantiene la identidad estable o migra la identidad como una fase separada con su propio despliegue y plan de rollback.

9) ¿Cuál es la mejor manera de demostrar a la dirección que la migración es segura?

Métricas y evidencia de cadena de custodia: tamaños de cola, tasas de defer, códigos de rebote, percentiles de latencia de entrega y muestras de traza por Message-ID entre viejo/nuevo. Los gráficos superan la confianza.

10) ¿Cómo evitamos machacar los servidores origen?

Limita la concurrencia de migración, programa lecturas masivas fuera de horas y vigila latencia IO. Protege el acceso de producción al correo. Tu migración no puede convertirse en la carga principal del almacén de buzones.

Conclusión: próximos pasos que puedes ejecutar mañana

Si quieres una migración sin tiempo de inactividad que no pierda mensajes, deja de pensar en “mover buzones” y empieza a tratarlo como mantener contratos mientras cambias infraestructura. A los usuarios no les importa dónde vive el buzón. Les importa que la bandeja de entrada siga siendo un sistema fiable.

Pasos prácticos siguientes:

1. Elige un modelo de enrutamiento: coexistencia por destinatario por fases, idealmente detrás de un gateway SMTP estable.
2. Escribe tu plan de rollback en términos operativos: qué se revierte, quién lo hace y en qué orden.
3. Haz inventario de emisores y autenticación DNS: includes SPF, selectores DKIM, severidad DMARC y sistemas terceros.
4. Construye tu rutina de verificación: monitorización de colas, trazado en logs, búsquedas por Message-ID y envíos de prueba externos.
5. Ejecuta un piloto que incluya usuarios raros: delegados, buzones compartidos, grandes archivos y restricciones de cumplimiento.
6. Frena para la estabilidad: las migraciones terminan cuando terminan; las interrupciones crean cronogramas más largos que la paciencia.

Haz el trabajo aburrido. Es como consigues el resultado emocionante: nada se rompe, nadie lo nota y mantienes tu fin de semana.