El problema: todos los correos muestran la misma fecha
Tras una migración IMAP, los usuarios abren su buzón y se encuentran con algo desconcertante: cada correo electrónico muestra exactamente la misma fecha. En lugar de la fecha original de envío o recepción, todos los mensajes llevan la fecha en que se realizó la migración. Años de correspondencia que parecen haber llegado el mismo día.
Para los administradores de TI, esto es una pesadilla. Los tickets se acumulan, los usuarios ya no encuentran nada por fecha, y el historial cronológico del buzón queda, en la práctica, destruido.
Cómo se ve en Outlook
En Microsoft Outlook, la columna "Recibido" muestra la fecha de migración para cada correo. Da igual que un mensaje se haya enviado en 2018 o en 2023: Outlook muestra la misma fecha, la del día en que la herramienta de migración procesó el buzón. La bandeja de entrada, los elementos enviados, cada carpeta está afectada. Los usuarios que dependen del orden por fecha ven su flujo de trabajo completamente roto.
Cómo se ve en Apple Mail
Apple Mail en macOS e iOS se comporta de forma similar. La fecha que aparece junto a cada mensaje refleja la marca de tiempo de migración en vez de la fecha original. Como Apple Mail utiliza los metadatos del servidor IMAP para determinar las fechas de visualización, el mismo problema subyacente produce el mismo resultado visible. Al recorrer la bandeja de entrada, solo se ve un muro de fechas idénticas.
Cómo se ve en Gmail (interfaz web)
La interfaz web de Gmail presenta una situación ligeramente distinta. El cliente web de Gmail generalmente usa la cabecera "Date" del propio correo, por lo que los mensajes pueden aparecer con la fecha correcta en Gmail. Pero el INTERNALDATE IMAP sigue siendo incorrecto, lo que significa que cualquier cliente IMAP conectado a esa cuenta de Gmail (Outlook, Thunderbird, Apple Mail) mostrará la fecha de migración. De hecho, el mismo buzón parece correcto en un cliente pero incorrecto en otro. Bastante confuso.
¿Por qué ocurre esto? La causa técnica
La causa de fondo está en cómo las herramientas de migración IMAP gestionan las cabeceras de correo y en cómo los clientes de correo determinan qué fecha mostrar. Entender esto requiere un breve vistazo al protocolo IMAP y a la estructura de cabeceras.
Cómo las herramientas de migración IMAP tratan las cabeceras
Cuando un correo se migra de un servidor a otro, la herramienta de migración descarga el mensaje en bruto del servidor origen y lo sube al servidor destino mediante el comando IMAP APPEND. Durante este proceso, el protocolo IMAP obliga al servidor destino a añadir una cabecera "Received" al mensaje. Esta cabecera contiene la marca de tiempo del momento en que el mensaje se insertó en el nuevo servidor, es decir, la fecha de migración.
La cabecera "Received" que lo rompe todo
Los mensajes de correo suelen contener varias cabeceras "Received", cada una añadida por un servidor de correo que gestionó el mensaje durante su entrega original. Clientes como Outlook determinan la "fecha de recepción" leyendo la cabecera "Received" más reciente, la que está en la parte superior de la cadena. Cuando una herramienta de migración añade una nueva cabecera "Received" con la marca de tiempo de migración, esta se convierte en la más reciente, y los clientes de correo muestran esa fecha en lugar de la original.
No es un fallo de la herramienta de migración ni del cliente de correo. Ambos siguen correctamente los estándares IMAP y de correo electrónico. El problema viene de que estos estándares nunca se diseñaron para la migración masiva, y la interacción entre IMAP APPEND y la lógica de visualización de fechas produce este resultado no deseado.
INTERNALDATE vs cabecera Date
Los servidores IMAP almacenan dos valores de fecha distintos para cada mensaje. La cabecera "Date" forma parte del propio mensaje de correo y registra cuándo se compuso y envió originalmente. El INTERNALDATE es un metadato almacenado por el servidor IMAP que representa cuándo el mensaje fue entregado o insertado en ese servidor concreto.
Algunas herramientas de migración intentan preservar el INTERNALDATE original definiéndolo durante el comando APPEND. Pero incluso cuando el INTERNALDATE se define correctamente, la cabecera "Received" añadida sigue causando problemas en los clientes que priorizan la fecha "Received" sobre el INTERNALDATE.
¿Qué herramientas de migración causan este problema?
Prácticamente todas las herramientas de migración IMAP pueden provocar este problema. La cuestión es inherente al protocolo IMAP, no específica de una herramienta. Algunas, sin embargo, se asocian más frecuentemente al problema por su uso extendido.
BitTitan MigrationWiz
BitTitan MigrationWiz es una de las herramientas de migración comerciales más populares entre MSP y consultores de TI. MigrationWiz añade una cabecera "Received" que contiene "mx.migrationwiz.com" durante el proceso de migración. Esta cabecera pasa a ser la más reciente en la cadena, provocando que Outlook y otros clientes IMAP muestren la fecha de migración. Consulte las guías detalladas para corregir fechas BitTitan en Outlook, Microsoft 365, Google Workspace y Exchange Online.
CloudM Migrate
CloudM Migrate (anteriormente Cloud Migrator) se utiliza mucho para migraciones a Google Workspace. Como las demás herramientas, CloudM añade su propia cabecera "Received" durante la inserción IMAP. Los correos migrados con CloudM muestran la fecha de migración en los clientes que se basan en la cabecera "Received". Consulte las guías para corregir fechas CloudM en Gmail, Outlook, Google Workspace y Microsoft 365.
imapsync
imapsync es una herramienta de código abierto muy utilizada por administradores Linux y proveedores de hosting. Aunque imapsync intenta preservar el INTERNALDATE, el servidor destino añade igualmente una cabecera "Received" durante la operación APPEND. La FAQ de imapsync reconoce esta limitación pero no ofrece solución integrada para eliminar la cabecera añadida tras la migración. Consulte las guías para corregir fechas imapsync en Outlook, Gmail, Microsoft 365 y Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) es la herramienta propia de Google para migrar desde Exchange o archivos PST de Outlook a Google Workspace. GSMMO puede producir el mismo problema de fechas, especialmente cuando la migración involucra un paso IMAP intermedio. Consulte las guías para corregir fechas GSMMO en Outlook, Gmail y Apple Mail.
Exchange Admin Center (importación IMAP nativa)
El Centro de administración de Exchange de Microsoft incluye una funcionalidad de importación IMAP nativa para migrar a Exchange Online (Microsoft 365). Esta herramienta de migración integrada añade cabeceras "Received" durante la importación, causando el mismo problema de visualización de fechas. Consulte las guías para corregir fechas de migración Exchange IMAP en Outlook y OWA.
Copia IMAP manual
Incluso la copia manual de correos entre servidores IMAP a través de un cliente como Thunderbird puede producir este problema de fechas. Cuando un cliente de correo copia un mensaje vía IMAP, el servidor destino lo trata como una nueva inserción y añade su propia cabecera "Received" con la marca de tiempo actual. Consulte las guías para corregir fechas de copia IMAP manual en Outlook, Gmail, Thunderbird y Apple Mail.
¿Por qué las soluciones habituales no funcionan?
Ante este problema, usuarios y administradores suelen probar varias opciones antes de darse cuenta de que ninguna resuelve realmente el asunto.
"Ordene por fecha de envío": por qué no basta
La sugerencia más habitual es cambiar el orden de "recepción" a "envío" en el cliente de correo. Eso cambia efectivamente el orden de visualización, pero no corrige los datos subyacentes. Los resultados de búsqueda siguen mostrando la fecha incorrecta. Las integraciones de calendario, herramientas de cumplimiento normativo y flujos automatizados que dependen de la fecha de recepción siguen fallando. Y los usuarios deben acordarse de cambiar este ajuste en cada dispositivo y en cada carpeta.
Re-migración: costosa y arriesgada
Algunos administradores consideran volver a ejecutar la migración, esperando evitar el problema de fechas en el segundo intento. Esta opción es costosa (500 a 5.000 EUR según el número de buzones), lenta y arriesgada. Una segunda migración introduce el mismo problema de cabecera "Received", duplica el riesgo de pérdida de datos y requiere un tiempo de inactividad significativo. La re-migración no resuelve el problema de fechas a menos que la herramienta de migración se modifique fundamentalmente.
Edición manual de cabeceras: requiere acceso al servidor
Técnicamente, la corrección implica eliminar la cabecera "Received" de migración de cada correo. Pero hacerlo manualmente requiere acceso directo al servidor, conocimiento de la estructura de cabeceras de correo y scripting personalizado. Para un buzón de 10.000 correos, la edición manual resulta impracticable y peligrosamente propensa a errores. Correos firmados con S/MIME, mensajes cifrados con PGP, estructuras multipart con límites MIME anidados, problemas de Content-Transfer-Encoding, cabeceras no ASCII (RFC 2047), archivos adjuntos sobredimensionados: cada uno de estos casos puede hacer que un script básico corrompa datos de forma irreversible. ¿Cómo confirmar que 10.000 correos corregidos están todos intactos? No se puede, salvo con un sistema de verificación diseñado específicamente para eso.
La solución real: restaurar las fechas originales
El enfoque correcto consiste en identificar los artefactos de migración en la cadena de cabeceras de cada correo y aplicar correcciones dirigidas que restauren el orden cronológico original en todos los clientes de correo. No es una simple edición de cabeceras. El proceso implica validación de conformidad RFC, preservación de la estructura del mensaje y coincidencia de patrones en cientos de firmas de herramientas de migración conocidas.
Cómo Redate.io corrige este problema
Redate.io se conecta al buzón (Google Workspace, Microsoft 365 o cualquier servidor IMAP) y analiza cada correo para identificar los mensajes afectados por cabeceras de migración. El análisis es gratuito y muestra exactamente cuántos correos están afectados antes de cualquier pago.
Para cada correo afectado, el motor de corrección propietario de Redate.io pasa el mensaje por un pipeline de análisis multietapa. El motor aplica coincidencia de patrones en cientos de firmas de herramientas de migración conocidas, construidas a partir del procesamiento de grandes volúmenes de datos de correo reales. Gestiona problemas de codificación, estructuras multipart, adjuntos en línea y decenas de casos especiales que harían que un script casero corrompiera los datos (no es el tipo de descubrimiento que uno quiere hacer un lunes por la mañana). Cada correo corregido pasa por una verificación de integridad antes de finalizarse. El mensaje original se mueve a una carpeta visible "Redate.io - Originals" (no se elimina) y se conserva durante 30 días.
¿El resultado? Los correos muestran sus fechas originales correctas en todos los clientes. El orden por fecha funciona de nuevo. El historial cronológico del buzón queda restaurado.
Preguntas frecuentes
¿Se pueden corregir las fechas meses después de la migración?
Sí. La cabecera "Date" original se preserva dentro del mensaje de correo independientemente de cuándo se haya realizado la migración. Redate.io puede corregir las fechas semanas, meses o incluso años después de la migración. La corrección funciona siempre que las cabeceras originales del correo estén intactas.
¿La corrección eliminará correos?
No. Redate.io nunca elimina correos electrónicos. Los mensajes originales se mueven a una carpeta visible llamada "Redate.io - Originals" dentro del buzón, donde permanecen accesibles durante 30 días. Cada correo corregido se verifica contra el original antes de finalizar el proceso. Si la verificación falla para un mensaje, el original permanece intacto.
¿Funciona con buzones compartidos?
Sí. Redate.io funciona con buzones compartidos en Google Workspace y Microsoft 365. Para buzones compartidos, se requiere acceso de nivel administrador para autorizar la conexión. El proceso es idéntico al de los buzones individuales: análisis, corrección, verificación.
¿Listo para restaurar las fechas correctas? Inicie un análisis gratuito para descubrir cuántos correos están afectados en cada buzón.