Outlook: fecha recibida IMAP vs fecha enviada

El síntoma que todo el mundo conoce

Acaba de terminar una migración IMAP hacia Microsoft 365 o Google Workspace. El lunes por la mañana llegan los tickets: "Todos mis correos tienen la misma fecha", "Mi historial está roto", "Ya no encuentro nada en mi bandeja". Abre Outlook y, efectivamente, miles de correos muestran la fecha del fin de semana pasado. No la fecha en que fueron enviados. La fecha en que tuvo lugar la migración.

Esto no es un bug de Outlook. Es una consecuencia directa del funcionamiento del protocolo IMAP y de las herramientas de migración. Pero para entender por qué, hay que abrir el capó.

Tres fechas en un solo correo

Un correo electrónico es más complejo de lo que parece. Cabeceras, cuerpo del mensaje, archivos adjuntos... y varios sellos de tiempo distintos que conviven. (Por cierto, si alguna vez ha intentado leer las cabeceras en bruto de un correo, sabe que no es exactamente lectura de playa.)

La cabecera Date: (RFC 2822)

Es la fecha que el remitente incluyó en el mensaje en el momento del envío. Definida por el RFC 2822, tiene este aspecto:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Esta cabecera queda grabada en la masa del mensaje. No cambia nunca, salvo que alguien modifique el contenido en bruto del mensaje. Es la "fecha de envío" en sentido estricto.

La cabecera Received: (añadida en cada salto de red)

Cada servidor que toca un correo en tránsito añade una cabecera Received: al principio del mensaje, con su propia fecha. Un correo que pasa por tres servidores acumula por tanto tres cabeceras Received:. La más reciente siempre va primera. El resultado es algo así:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Resultado: cuando una herramienta de migración como BitTitan MigrationWiz, CloudM, imapsync o GSMMO mueve un correo de un servidor origen a un servidor destino, se comporta también como un "salto de red". Inyecta una nueva cabecera Received: en lo alto de la pila, con la fecha y hora de la migración.

El INTERNALDATE de IMAP

Esta es la tercera fecha, y la que genera el problema. El INTERNALDATE es un metadato almacenado en el servidor IMAP, independiente del contenido del mensaje. Representa la fecha en que el correo fue entregado (o insertado) en el buzón. Cuando una herramienta de migración inserta un correo mediante el comando IMAP APPEND, es ella quien decide qué valor asignar al INTERNALDATE. Y en muchos casos, las herramientas utilizan la fecha del momento de la migración. No la fecha original.

Ahí es donde todo se rompe.

Por qué Outlook muestra la fecha de migración

Outlook usa el INTERNALDATE para mostrar la columna "Recibido". Es su comportamiento por defecto, y es coherente con la especificación IMAP: el INTERNALDATE se supone que representa la fecha de recepción en el buzón. En un flujo normal (un correo real que llega), el INTERNALDATE es próximo a la fecha de la cabecera Date:. Los dos son coherentes.

Tras una migración fallida, el INTERNALDATE de todos los correos importados apunta a la noche del 14 al 15 de junio de 2024 (o cualquiera que sea la fecha de migración). Outlook lee ese valor, lo muestra en la columna "Recibido", y el resultado es catastrófico: 45.000 correos parecen haber llegado la misma noche.

Para ser precisos, la primera cabecera Received: (la más reciente en la pila) también influye en la visualización en ciertas configuraciones. Pero el INTERNALDATE sigue siendo el determinante principal de la columna "Recibido" de Outlook en modo IMAP sincronizado.

El truco de "Añadir columna Enviado" en Outlook

Lo primero que hacen la mayoría de administradores de IT cuando descubren el problema es buscar un parche en el lado del cliente. Y existe uno, en efecto.

En Outlook se puede modificar la vista de columnas de una carpeta para reemplazar (o completar) la columna "Recibido" por la columna "Fecha" o "Enviado". La columna "Fecha" lee directamente la cabecera Date: del mensaje, no el INTERNALDATE. Como la cabecera Date: no fue tocada por la migración, las fechas originales vuelven a aparecer.

Para hacerlo en Outlook (escritorio, versión Microsoft 365): clic derecho sobre el encabezado de columna en la lista de mensajes, "Configuración de vista", y luego modificar las columnas para quitar "Recibido" y añadir "Fecha". Se puede hacer mediante GPO para un despliegue masivo.

Sobre el papel, esto resuelve el problema visual. En la práctica, es una tirita sobre una arteria.

Los límites concretos de este parche

Los clientes móviles y web

Outlook en iOS, Android y Outlook Web App (OWA) no tienen las mismas opciones de personalización. La modificación de vista que desplegó en los equipos Windows no se propaga. Los usuarios que consultan su correo desde el móvil siguen viendo la fecha de migración. Y en una empresa de tamaño mediano, eso es probablemente la mitad de los usuarios.

La búsqueda

La búsqueda de Outlook usa el índice de Windows Search (o el índice de Exchange/Microsoft 365 en el servidor). Ese índice se construye a partir del INTERNALDATE, no de la cabecera Date:. Si un usuario busca "correos de enero de 2022", la búsqueda devuelve los correos cuyo INTERNALDATE es de enero de 2022. No los que tienen la cabecera Date: en enero de 2022. El resultado: los correos antiguos ya no aparecen en los filtros de fecha. Cambiar la columna de visualización no cambia nada en esto.

Las reglas de mensajería

Las reglas de Outlook ("si el correo fue recibido antes del...", "si el correo fue recibido después del...") también usan el INTERNALDATE. Una regla de clasificación o archivado basada en rangos de fechas dejará de funcionar correctamente tras la migración si el INTERNALDATE no se ha corregido.

Cumplimiento normativo y eDiscovery

Quizás es el punto más serio. Las herramientas de cumplimiento, archivado legal y eDiscovery (Microsoft Purview, por ejemplo) usan el INTERNALDATE como referencia de fecha para las consultas legales. Si su empresa está sujeta a obligaciones de retención o debe responder a solicitudes de discovery, unos INTERNALDATE corruptos pueden generar problemas jurídicos reales. Una auditoría que pida "todos los correos entre tal y tal fecha" no devolverá los resultados correctos. En Europa, esto puede tener implicaciones directas bajo el RGPD y otras normativas sectoriales.

Las herramientas de terceros

CRM, herramientas de ticketing, archivadores... todo lo que se conecta a su servidor de correo mediante IMAP o las API de Microsoft 365/Google Workspace lee el INTERNALDATE. Cambiar la vista de Outlook no corrige nada para esos sistemas.

La única solución real: corregir a nivel del servidor

Ordenar por fecha de envío en Outlook no es una solución. Es una tirita. La corrección real debe hacerse a nivel de los metadatos del servidor, no de la vista del cliente.

En concreto, esto significa corregir el INTERNALDATE de cada correo para que corresponda a la fecha original de la cabecera Date:. La cabecera Date: original sigue presente en el mensaje (la migración no la borró), lo que hace posible la corrección. Ahí está la información de fecha real.

En Google Workspace, la API de Gmail expone un parámetro internalDate que permite actuar directamente sobre ese metadato. En Microsoft 365, el mecanismo es diferente pero el resultado esperado es el mismo. En un servidor IMAP estándar, la norma prevé que la fecha puede especificarse al insertar un mensaje.

En la práctica, realizar esta operación sobre decenas de miles de correos en producción, sin pérdida de datos, sin duplicados, sin romper hilos de conversación ni etiquetas, gestionando los casos límite (mensajes firmados con S/MIME, estructuras MIME complejas, codificaciones no ASCII según el RFC 2047, archivos adjuntos voluminosos)... es otra historia. Un script que funciona con 50 correos de prueba no aguantará en un buzón de 40.000 mensajes. Gestionar los errores 429 (cuota de API superada), los timeouts de red a las 2 de la mañana, los mensajes cuya estructura MIME ya está parcialmente corrompida tras la migración... todo eso requiere una ingeniería seria.

Eso es precisamente lo que hace Redate.io. El motor de corrección propietario analiza la cadena de cabeceras de cada correo, identifica la fecha original fiable, y aplica una corrección de metadatos sin tocar el contenido del mensaje. Cada correo corregido se verifica individualmente. Los originales se conservan en una carpeta de copia de seguridad durante 30 días, lo que hace posible una vuelta atrás en cualquier momento. Algo que ningún script casero ofrece.

Identificar la herramienta de migración responsable

El problema se manifiesta de la misma forma independientemente del origen de la migración, pero los detalles varían según la herramienta utilizada. BitTitan MigrationWiz, CloudM, imapsync y GSMMO tienen cada uno su firma en las cabeceras Received: que inyectan. El pipeline de análisis de Redate.io mantiene una base de correspondencia sobre cientos de firmas de herramientas de migración conocidas para distinguir la cabecera de migración del resto de la cadena de tránsito legítima.

Si no sabe qué herramienta se usó en su migración (ocurre, sobre todo cuando se recupera un entorno después de otro MSP), el escáner gratuito de Redate.io identifica los buzones afectados y ofrece una estimación del volumen a corregir antes de cualquier compromiso.

Para contextos específicos, hay guías detalladas disponibles: corregir las fechas de imapsync en Outlook, corregir las fechas de BitTitan en Outlook, o también corregir las fechas de CloudM en Outlook.

Qué hacer ahora

Si está leyendo este artículo después de una migración, la buena noticia es que la cabecera Date: original está intacta en cada uno de sus correos. La información de fecha real está ahí, presente en cada mensaje. El problema está en los metadatos, no en el contenido. Y los metadatos se pueden corregir.

También puede consultar el artículo IMAP INTERNALDATE: por qué las fechas se rompen para profundizar en la mecánica del problema, o la guía completa sobre fechas erróneas en Outlook tras migración si quiere una visión general de los diferentes escenarios.

¿Listo para corregir las fechas de sus buzones? Lance un escaneo gratuito en Redate.io para identificar los correos afectados y estimar el volumen antes de cualquier corrección.