Nuevo Outlook: fechas incorrectas tras migración, causas reales

Dos Outlook, dos comportamientos ante los mismos correos

Si ha migrado buzones a Microsoft 365 recientemente y algunos usuarios se quejan de que todos sus correos antiguos muestran la misma fecha (la de la migración), quizás ha notado algo extraño: los usuarios con el Outlook clásico a veces ven la fecha correcta en el panel de lectura, mientras que los del nuevo Outlook para Windows ven sistemáticamente la fecha de migración. El mismo buzón. Los mismos correos. Resultados diferentes.

No es un bug en sentido estricto. Es una decisión de arquitectura que tiene consecuencias directas sobre cómo se muestran las fechas tras una migración IMAP. Para entender qué ocurre, hay que entrar en los detalles de las cabeceras de correo y del protocolo IMAP, lo cual no es exactamente lectura ligera, pero permite comprender por qué ninguna manipulación en el cliente basta para resolver el problema.

El INTERNALDATE de IMAP: el verdadero culpable

Cuando un correo se almacena en un servidor IMAP, tiene dos tipos de fechas que coexisten sin confundirse.

La primera es la cabecera Date:, definida por la RFC 2822. Es la fecha escrita en el propio mensaje, la que el remitente indicó al enviarlo. Forma parte del cuerpo del mensaje y nunca cambia, sea cual sea el recorrido que haga el correo después.

La segunda es el INTERNALDATE, un metadato gestionado por el servidor IMAP, externo al mensaje. Es la fecha en que el servidor registró el mensaje. En una migración normal, las herramientas serias preservan el INTERNALDATE original. Pero en una migración mal configurada, o con ciertas herramientas que no gestionan correctamente este metadato, el INTERNALDATE se reinicia a la fecha del día de la migración. El resultado: todos los correos migrados llevan la misma fecha de recepción desde el punto de vista del servidor.

(Por cierto, si alguna vez ha leído los logs de imapsync o de MigrationWiz, sabe que existen opciones específicas para intentar preservar el INTERNALDATE. Estas opciones no siempre funcionan, y algunos servidores de destino se niegan a respetarlas.)

Outlook clásico: cómo lee las fechas

El Outlook clásico, es decir, las versiones COM instaladas localmente (Outlook 2016, 2019, 2021 y el cliente de escritorio Microsoft 365 Apps), usa un mecanismo algo más complejo para determinar qué fecha mostrar en la lista de mensajes.

Para los correos de la carpeta Enviados, se basa en la cabecera Date:. Para los correos recibidos, utiliza preferentemente el INTERNALDATE del servidor, pero en ciertos contextos (especialmente cuando está implicada la caché OST o en la primera visualización en el panel de lectura), también puede leer la cadena de cabeceras Received: para reconstruir una fecha de origen aproximada.

Por eso se observa ese comportamiento inconsistente: el Outlook clásico puede mostrar a veces la fecha correcta en el panel de lectura, porque lee la cabecera Date: original del mensaje en la vista detallada, aunque la lista de correos siga usando el INTERNALDATE corrupto. Ojo, esto no es fiable y no corrige nada. El orden sigue roto, las búsquedas por fecha siguen siendo incorrectas.

El nuevo Outlook: una arquitectura radicalmente diferente

El nuevo Outlook para Windows, desplegado de forma progresiva desde finales de 2023, ya no es una aplicación COM. Es esencialmente una Progressive Web App (PWA) basada en el mismo código que Outlook en la web (OWA). Esta renovación tiene implicaciones profundas.

El nuevo Outlook delega completamente la visualización de fechas a la API de Microsoft 365. No lee las cabeceras Received:, no examina la cadena de cabeceras para recuperar una fecha de origen, y no intenta ninguna reconstrucción en el cliente. Muestra simplemente lo que el servidor devuelve: el INTERNALDATE.

Resultado: si el INTERNALDATE se corrompió durante la migración, el nuevo Outlook no duda. Muestra la fecha de migración en cada correo afectado, sin excepción, sin matices. Es un comportamiento más coherente y predecible que el del Outlook clásico, pero hace que el problema de migración sea inmediatamente visible e imposible de ignorar.

Un administrador que migra 300 buzones un viernes por la noche va a descubrir el lunes por la mañana que todos los usuarios del nuevo Outlook ven sus archivos enteros fechados el fin de semana pasado. Los tickets llegan rápido.

Por qué ninguna solución en el cliente funciona

Muchos administradores intentan soluciones en el cliente antes de entender que el problema está en los datos del servidor. Estas son las tentativas habituales, y por qué fallan.

Ordenar por "Fecha de envío" en lugar de "Fecha de recepción"

Ordenar por fecha de envío en Outlook se basa en la cabecera Date: del mensaje, que está intacta. Así que sí, este orden puede funcionar. Pero es un parche, no una solución. Las búsquedas por fecha siguen rotas. Las reglas basadas en la fecha siguen siendo inutilizables. Y sobre todo, el usuario tiene que reconfigurar manualmente cada carpeta, cada buzón. En 300 buzones, eso es inviable. Ordenar por fecha de envío no es una solución, y los usuarios finales no entienden por qué se les pide que cambien sus hábitos.

Vaciar la caché de Outlook o recrear el perfil

Esto no afecta al INTERNALDATE en el servidor. Tras recrear el perfil, Outlook vuelve a sincronizar los correos desde el servidor y recupera exactamente los mismos metadatos corruptos. La caché no es el problema.

Usar OWA en su lugar

OWA y el nuevo Outlook comparten la misma base de datos. Si el INTERNALDATE está corrupto en el servidor Exchange Online, OWA muestra exactamente la misma fecha incorrecta. Cambiar de cliente no cambia los datos.

El problema está en el servidor, en los metadatos de cada mensaje. Ninguna acción en el cliente puede corregir datos almacenados en el servidor.

La trampa de las cabeceras Received: por qué lo complican todo

Cuando una herramienta de migración copia un correo de un servidor a otro vía IMAP, el servidor de destino añade automáticamente una cabecera Received: al principio de la cadena, con la fecha y hora de la inserción. Es el comportamiento normal de los servidores SMTP e IMAP conformes a las RFC.

Estas cabeceras se acumulan en orden inverso al recorrido del correo. La más reciente está arriba. Algunos clientes de correo leen el primer Received: para estimar la fecha de recepción, lo que da la fecha de migración en lugar de la fecha original.

Aclaración: este comportamiento no es exclusivo de una sola herramienta. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, e incluso una copia manual IMAP entre dos clientes Thunderbird producen todos este resultado. La cabecera Date: original permanece intacta en el mensaje. Es precisamente lo que hace que la corrección sea técnicamente posible. Pero el INTERNALDATE es un metadato distinto gestionado por el servidor, y no puede corregirse simplemente manipulando las cabeceras del mensaje en el cliente.

Para profundizar en este mecanismo, el artículo sobre IMAP INTERNALDATE y las fechas incorrectas detalla cómo se gestiona este metadato según los servidores.

Qué herramientas de migración causan este problema en Microsoft 365

La pregunta vuelve a menudo: ¿todas las herramientas de migración provocan este problema?

La respuesta corta es que depende de la configuración y de la plataforma de destino. En Exchange Online / Microsoft 365, el servidor es especialmente estricto en la gestión del INTERNALDATE. Incluso herramientas que intentan preservarlo fallan a veces, ya que la API Graph y EWS (Exchange Web Services) tienen comportamientos diferentes según la ruta de inserción utilizada.

BitTitan MigrationWiz es una de las herramientas más extendidas para las migraciones hacia Microsoft 365, y también una de las cuyos problemas de fechas están mejor documentados. La página dedicada a corregir las fechas de BitTitan en Microsoft 365 cubre las configuraciones específicas que hay que vigilar. CloudM e imapsync tienen sus propias particularidades, documentadas respectivamente en corregir las fechas de CloudM en Microsoft 365 y corregir las fechas de imapsync en Microsoft 365.

Lo que tienen en común todas estas herramientas: la cabecera Date: original sobrevive a la migración. Es la base sobre la que una corrección es posible.

Por qué un script casero es mala idea aquí

Entender el problema da a veces la ilusión de que la solución es sencilla. No lo es, no a escala de producción.

Modificar los metadatos de correos almacenados en Exchange Online no es trivial. La API Graph de Microsoft impone límites de tasa estrictos (el error 429 Too Many Requests en un batch nocturno aparece rápido). La gestión de correos firmados S/MIME o cifrados con PGP requiere atención especial para no invalidar las firmas. Las estructuras multipart con archivos adjuntos voluminosos añaden restricciones sobre los timeouts de red. Y sobre todo: ¿cómo verificar, correo a correo, que la corrección ha funcionado sin alterar el contenido ni los adjuntos?

Un script que funciona bien con 50 correos de prueba no se comportará igual en un buzón de 40.000 mensajes con 8 años de historial. La probabilidad de que un caso límite rompa algo aumenta con cada millar de mensajes adicional. Y sin mecanismo de rollback, un error a mitad del proceso deja el buzón en un estado inconsistente.

Véase también: corregir fechas de correo tras migración a Microsoft 365 para un resumen completo de las opciones disponibles.

Qué hace Redate.io concretamente

Redate.io abre el buzón de Microsoft 365 mediante el inicio de sesión propio de cada usuario, sin portal ni aplicación que registrar, analiza de forma gratuita los correos con fechas incorrectas y aplica un motor de corrección propietario sobre los mensajes identificados. El pipeline de análisis multi-etapa realiza una correspondencia sobre cientos de firmas de herramientas de migración conocidas, una validación de conformidad RFC y un análisis de la cadena de cabeceras para reconstruir los metadatos de fecha correctos.

Cada correo corregido se verifica individualmente. Los mensajes originales se conservan en una carpeta de copia de seguridad visible dentro de su propio buzón, hasta que usted decida eliminarlos. El modelo de precios es un pago único por buzón, sin suscripción.

El nuevo Outlook muestra entonces las fechas correctas, porque los datos del servidor están corregidos, no enmascarados.

¿Tiene buzones afectados en el nuevo Outlook? Lance un análisis gratuito en Redate.io para identificar exactamente cuántos correos están afectados antes de decidir cómo actuar.