Fechas incorrectas tras migración de Zoho a Microsoft 365

Lo que ocurrió en su buzón de correo

Acaba de finalizar la migración de su dominio desde Zoho Mail a Microsoft 365. La infraestructura de Exchange Online está lista, los buzones están aprovisionados, los registros MX actualizados. Y entonces, el lunes por la mañana, un usuario abre Outlook y ve que todos sus correos de 2021 muestran la fecha de hoy. Otro se da cuenta de que sus mensajes del año pasado aparecen arriba de su bandeja de entrada, como si acabaran de llegar. Los tickets empiezan a acumularse.

No es un bug de Outlook. Tampoco es un problema específico de Zoho. Es el comportamiento esperado, pero mal documentado, de cualquier migración IMAP hacia Exchange Online. Entender exactamente por qué ocurre es el primer paso para corregirlo bien.

La causa técnica: INTERNALDATE y cabeceras Received

Un correo almacenado en un servidor IMAP se compone de dos cosas distintas: el contenido bruto del mensaje (las cabeceras RFC 2822, el cuerpo, los archivos adjuntos) y los metadatos de almacenamiento gestionados por el servidor IMAP, entre ellos el INTERNALDATE. Es este metadato el que utilizan los clientes de correo para mostrar y ordenar los mensajes.

La cabecera Date: definida en el mensaje bruto (RFC 2822) representa la fecha en que el mensaje fue redactado o enviado por el remitente. El INTERNALDATE, en cambio, es la fecha en que el servidor IMAP recibió o almacenó el mensaje. Normalmente, en un servidor en buen estado, ambos valores son cercanos. Después de una migración, la historia es otra.

Cómo la migración IMAP corrompe las fechas

Cuando una herramienta de migración (el Zoho Migration Wizard, imapsync, BitTitan, o cualquier otra) transfiere un mensaje de Zoho Mail a Exchange Online, lo hace mediante el protocolo IMAP. La herramienta se conecta a Zoho, recupera el mensaje y lo inserta en Exchange Online mediante un comando IMAP APPEND. Y es ahí donde empieza el problema.

Exchange Online, al recibir cada mensaje, genera una nueva cabecera Received: que añade al inicio del mensaje. Esa cabecera lleva la fecha y hora exactas de la inserción, es decir, la fecha de la migración. Algunas herramientas intentan preservar el INTERNALDATE original pasándolo como parámetro al comando APPEND. Otras no lo hacen, o lo hacen de forma incorrecta, y en ese caso Exchange Online asigna automáticamente la fecha de recepción como INTERNALDATE.

Resultado: tanto si el correo fue enviado en 2019 como en 2022, su INTERNALDATE apunta ahora a la semana de la migración. Outlook lee ese valor en primer lugar. El orden cronológico se rompe por completo.

El comportamiento específico del Zoho Migration Wizard

Zoho ofrece su propia herramienta de migración para abandonar su plataforma: el Zoho Migration Wizard. Es práctica para migraciones sencillas, pero tiene un comportamiento documentado en foros de administradores: no siempre transmite correctamente el INTERNALDATE original al insertar mensajes en el servidor de destino.

Para ser preciso, el problema afecta principalmente a las migraciones hacia servidores que añaden sistemáticamente una cabecera Received: a cada mensaje entrante, que es exactamente el comportamiento de Exchange Online. Aunque el Zoho Migration Wizard pase la fecha original como parámetro APPEND, la cabecera Received: generada por Exchange Online queda en primera posición en la cadena de cabeceras, y Outlook la utiliza para determinar "cuándo llegó el correo".

Los administradores que usan herramientas IMAP genéricas como imapsync para salir de Zoho se encuentran con exactamente el mismo problema, a veces peor, porque la configuración predeterminada de imapsync no está optimizada para Exchange Online. (Por cierto, si alguna vez ha revisado un log de imapsync línea por línea a las 2 de la madrugada buscando un error de sincronización, sabe que es una herramienta potente pero no especialmente tolerante con los casos límite.)

Por qué Outlook muestra la fecha incorrecta

Outlook no usa únicamente la cabecera Date: para mostrar la fecha de un correo. En la mayoría de las vistas, utiliza el INTERNALDATE que proporciona el servidor IMAP/Exchange, especialmente para ordenar la bandeja de entrada. La cabecera Date: original sigue estando en el mensaje, intacta, pero se ignora en favor del INTERNALDATE.

Por eso la opción "Ordenar por fecha de envío" en Outlook no resuelve realmente el problema. Muestra una fecha diferente, sí, pero el comportamiento de ordenación sigue siendo inestable según la versión de Outlook y el modo de vista (conversaciones agrupadas o no). Ordenar por fecha de envío no es una solución. Es un parche que cae a la primera actualización del cliente.

El alcance real del problema

En una migración de Zoho a Microsoft 365 de tamaño medio, hablamos fácilmente de 50.000 a 500.000 mensajes afectados, dependiendo de la antigüedad de los buzones y del tamaño de la organización. Cada correo transferido durante la ventana de migración lleva la misma fecha corrupta, lo que hace que el problema sea visible de inmediato para los usuarios en cuanto abren Outlook por primera vez.

Las carpetas de Enviados suelen ser las más problemáticas. Un comercial que busca un presupuesto enviado en marzo de 2022 se encuentra rebuscando entre cientos de correos que muestran todos la fecha de la migración. El impacto operativo es real, no solo estético.

Y al contrario de lo que podría pensarse, el problema no desaparece con el tiempo. El INTERNALDATE queda fijado en el momento de la inserción. No se corrige solo. Sin intervención activa, los correos conservarán su fecha corrupta de forma indefinida.

Por qué corregirlo uno mismo es más arriesgado de lo que parece

La tentación es comprensible: puesto que la cabecera Date: original sigue estando en el mensaje, bastaría con... corregir los metadatos. Sobre el papel tiene lógica. En la práctica, sobre un buzón de producción con 80.000 correos, es una operación que puede salir catastróficamente mal.

Estos son algunos casos límite que un script casero probablemente no gestionará bien:

• Los correos firmados con S/MIME, cuya firma cubre la totalidad de las cabeceras. Modificar cualquier cosa en la estructura del mensaje invalida la firma criptográfica.
• Los mensajes cifrados con PGP, donde el contenido es opaco y cualquier manipulación de los sobres MIME puede corromper el mensaje.
• Las cabeceras no-ASCII codificadas según RFC 2047 (nombres de remitentes con caracteres especiales), que se rompen si el script no gestiona correctamente la codificación.
• Los archivos adjuntos codificados en base64 con líneas mal terminadas, fronteras MIME no estándar o estructuras multipart anidadas.
• Los correos sin cabecera Date: válida (existen, especialmente en exportaciones antiguas de Zoho), donde el script tiene que decidir qué hacer.

Un script que funciona con 50 correos de prueba no funcionará con un buzón de producción exportado desde Zoho con años de historial. ¿Y cómo verificar, mensaje por mensaje, que cada corrección ha quedado intacta y que los adjuntos no se han truncado? La verificación es al menos tan compleja como la corrección en sí.

Está también la cuestión de las cuotas. La API de Exchange Online, a través de Microsoft Graph, impone límites de velocidad estrictos (los famosos errores 429 Too Many Requests). Un batch sin control de throttling sobre 100.000 mensajes puede provocar bloqueos temporales o errores silenciosos difíciles de diagnosticar después. Sin un mecanismo de recuperación ante fallos, hay que empezar desde cero.

Cómo Redate.io corrige las fechas tras la migración desde Zoho

Redate.io se conecta a su tenant de Microsoft 365 mediante los permisos estándar de Azure AD, sin necesidad de acceso de administrador global. El análisis inicial es gratuito: Redate.io identifica los buzones afectados y estima el volumen de correos con fechas incorrectas, comparando el INTERNALDATE con los valores que contiene la cadena de cabeceras del mensaje.

La corrección utiliza un motor propietario que analiza la cadena completa de cabeceras de cada mensaje, identifica las firmas específicas de las herramientas de migración de Zoho (tanto el Zoho Migration Wizard como imapsync configurado para una salida desde Zoho), y reconstruye los metadatos de fecha mediante un pipeline de validación en múltiples etapas. Cada correo corregido se verifica individualmente: integridad del contenido, conservación de los adjuntos, conformidad con el RFC. Los originales se conservan en una carpeta de copia de seguridad accesible durante 30 días.

Sin re-migración. Sin tiempo de inactividad. Los usuarios siguen usando Outlook mientras la corrección se ejecuta en segundo plano.

El precio es un pago único basado en el volumen, sin suscripción. Los detalles están disponibles directamente en el sitio web.

Situaciones relacionadas que conviene conocer

Si gestiona varias migraciones en paralelo, o si es MSP y administra clientes que están saliendo de Zoho, sepa que el mismo problema ocurre al migrar desde otras plataformas hacia Exchange Online. La mecánica es idéntica: la cabecera Received: generada por Exchange sobrescribe el INTERNALDATE independientemente del origen.

Para las migraciones desde Google Workspace, desde Exchange on-premises, o mediante herramientas como BitTitan MigrationWiz o CloudM, los artículos dedicados en el blog de Redate.io detallan los comportamientos específicos de cada herramienta. El artículo sobre fechas incorrectas tras migración IMAP a Exchange Online ofrece una visión general de todos los escenarios que acaban afectando a ese tenant.

Si su migración incluye buzones compartidos o recursos de Exchange (salas, equipos), el problema es el mismo, y las mismas herramientas de corrección se aplican. Los guías de corrección IMAP hacia Exchange en el sitio de Redate.io detallan los pasos para conectarse a su tenant.

Para los equipos que utilizan imapsync específicamente para salir de Zoho, el artículo sobre imapsync: fechas no conservadas documenta las opciones de configuración de imapsync y por qué no bastan para evitar el problema en Exchange Online.

¿Las fechas de su migración desde Zoho siguen apareciendo mal en Outlook? Analice sus buzones gratis en Redate.io para medir el alcance exacto del problema antes de decidir cómo actuar.