Hosting compartido a M365: el problema de fechas oculto

El problema que nadie le advirtió

Acaba de finalizar la migración de su correo desde OVH, Infomaniak, Ionos u o2switch hacia Microsoft 365. El asistente de migración del EAC (Exchange Admin Center) ha estado trabajando toda la noche, todo aparece en verde y los buzones están llenos. El lunes por la mañana, primer ticket: "Todos mis correos antiguos tienen la fecha de hoy." Luego un segundo. Luego diez.

No es un error de Microsoft 365. Tampoco es casualidad. Es el resultado mecánico de una migración IMAP, y en el caso de un alojamiento compartido, el problema suele ser dos veces más grave que en una migración convencional. Aquí está la razón.

Cómo gestiona IMAP las fechas (y dónde falla)

Cada correo almacenado en un servidor IMAP tiene dos tipos de fecha distintos. Por un lado, la cabecera Date: (definida por la RFC 2822), presente en el propio cuerpo del mensaje, que indica cuándo fue enviado o recibido. Por otro, el INTERNALDATE, un metadato a nivel de servidor que indica en qué fecha se depositó ese mensaje en el buzón. Es este valor el que clientes como Outlook usan por defecto para ordenar y mostrar los correos.

(Por cierto, si alguna vez ha intentado leer las cabeceras brutas de un correo en el EAC, sabe que no es exactamente lectura de verano. Fácilmente hay veinte o treinta líneas de cabeceras antes de llegar al contenido.)

Cuando una herramienta de migración IMAP transfiere un mensaje de un buzón a otro, debe recrear ese INTERNALDATE en el destino. Algunas herramientas lo hacen correctamente. Muchas no, o lo hacen con limitaciones. Y los servidores de destino tienen su propia lógica: Exchange Online, por su parte, conserva lo que recibe: cuando una copia llega con su fecha original, Exchange Online mantiene esa fecha. Así que cuando las fechas salen mal, hay que mirar a la herramienta, no a Microsoft 365.

Resultado: cada correo migrado parece haber sido "recibido" el día de la migración. Da igual que sea de 2019.

El escenario en dos etapas: por qué el hosting compartido agrava todo

Aquí es donde la situación se vuelve realmente problemática en las migraciones desde alojamientos compartidos como OVH, Infomaniak, Gandi, Ionos u o2switch.

Estos proveedores utilizan generalmente servidores compartidos con Postfix, Dovecot o cPanel con configuraciones IMAP estándar. Muchas pymes han acumulado años de correos en ellos, a veces desde 2010 o 2012. Cuando deciden pasarse a Microsoft 365, la migración suele ocurrir en dos tiempos.

Etapa 1: la primera corrupción (antes incluso de Microsoft 365)

En muchos casos, los correos ya han sufrido una migración anterior. La empresa cambió de proveedor de hosting una o dos veces a lo largo de los años: de Gandi a OVH en 2018, luego de OVH a Infomaniak en 2022, por ejemplo. Cada transferencia IMAP pudo restablecer el INTERNALDATE original a la fecha de la transferencia (cuando la herramienta no transmitió la fecha original), y algunas herramientas dejan además sus propias cabeceras de migración, fechadas ese día.

Cuando los correos llegan a Microsoft 365, ya llevan cicatrices. La cabecera Date: original está intacta (forma parte del cuerpo del mensaje, nadie la toca), pero los metadatos de fecha ya han sido alterados una primera vez.

Etapa 2: la segunda corrupción durante el paso a Exchange Online

La herramienta de migración IMAP del EAC, o una herramienta de terceros como BitTitan MigrationWiz en modo IMAP, ingiere entonces esos correos ya dañados. Si esa herramienta tampoco transmite la fecha original de cada correo, Exchange Online lo archiva con la fecha de la transferencia, y esa es la "fecha de recepción" que termina mostrando Outlook.

Un correo enviado en marzo de 2017 puede llevar dos capas de fechas incorrectas: las cabeceras de migración que dejó el traslado de 2022, y la fecha de recepción de la migración a Microsoft 365 en 2024. Outlook muestra 2024. El usuario ve 2024. Es incorrecto en dos niveles.

Para ser más precisos: Outlook determina la fecha de visualización a partir de una combinación entre el INTERNALDATE que registró Exchange Online y las cabeceras presentes. Pero cuando la herramienta de migración no transmite las fechas originales, el traslado a Exchange Online añade una nueva capa de errores sobre la anterior.

Herramientas de migración y proveedores: las combinaciones de riesgo

Algunas combinaciones aparecen con mucha frecuencia en las migraciones desde alojamientos compartidos:

• OVH / Infomaniak / Ionos + herramienta IMAP del EAC: la herramienta nativa de Microsoft es cómoda, pero tiene fama de no preservar correctamente las fechas en migraciones IMAP de gran volumen.
• cPanel (o2switch, LWS, etc.) + BitTitan MigrationWiz en modo IMAP: MigrationWiz en modo IMAP añade sus propias cabeceras de migración. El resultado está documentado, entre otros casos, en la página corregir fechas de BitTitan en Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync es una herramienta potente, pero su gestión del INTERNALDATE depende de la configuración. Sin la opción adecuada, las fechas no se preservan. Vea también imapsync: fechas no conservadas.
• Cualquier migración manual por arrastrar y soltar en Outlook: si alguien copió carpetas enteras haciendo drag-and-drop entre dos cuentas configuradas en Outlook, el INTERNALDATE de cada correo se reescribe con la fecha de la copia. Sin excepción.

El denominador común: todos estos métodos desembocan en Exchange Online con correos cuya fecha mostrada en Outlook ya no corresponde a nada real.

Por qué "corregirlo uno mismo" es mala idea a gran escala

Entender el problema es una cosa. Corregir 8.000 correos repartidos en 40 buzones de Exchange Online, en cuentas con estructuras de carpetas complejas, correos firmados con S/MIME, archivos adjuntos voluminosos e hilos de conversación anidados, es otra muy distinta.

Un script de PowerShell que parece funcionar en diez correos de prueba puede fallar silenciosamente en el mensaje número 4.237 debido a un límite MIME corrompido o a una cabecera codificada en RFC 2047 (ese formato =?UTF-8?B?...?= para los caracteres no ASCII en los nombres de remitentes). Sin un mecanismo de verificación individual, no se enterará. Solo habrá un correo perdido.

Los riesgos concretos del enfoque manual en este tipo de migración:

• Mensajes duplicados si la lógica de inserción falla a mitad de camino
• Archivos adjuntos perdidos si la estructura multipart se reconstruye mal
• Hilos de conversación rotos en Outlook (las conversaciones se basan en cabeceras References: e In-Reply-To: que pueden resultar alteradas)
• Errores 429 (Too Many Requests) de la API de Microsoft Graph a las 3 de la madrugada, que interrumpen el proceso sin posibilidad de rollback
• Ninguna forma sencilla de verificar que las 8.000 correcciones se aplicaron correctamente

Y en el caso específico de las migraciones desde alojamientos compartidos, hay una dificultad adicional: los correos llevan varias capas de cabeceras Received: parásitas, no solo una. Un script simple que elimine "la última cabecera Received:" no basta. Hay que analizar la cadena completa para identificar qué cabecera corresponde a qué migración, y cuál representa realmente la fecha de recepción original.

Lo que Redate.io hace de forma diferente

Cada usuario inicia sesión con su propia cuenta de Microsoft, y Redate.io abre ese buzón con el acceso que concede ese inicio de sesión. El análisis inicial es gratuito: Redate.io identifica todos los correos cuya fecha mostrada no se corresponde con la fecha real, y ofrece una estimación detallada por buzón.

La corrección se basa en un motor propietario que analiza la cadena completa de cabeceras de cada mensaje, sea cual sea la herramienta de migración utilizada, y reconstruye los metadatos de fecha correctamente, incluso cuando se superponen varias capas de corrupción. Cada correo corregido se verifica de forma individual. Los originales se conservan en una carpeta de copia de seguridad visible en su propio buzón, hasta que usted decida eliminarlos.

Para las migraciones desde alojamientos compartidos, el pipeline de análisis multietapa de Redate.io gestiona explícitamente los escenarios de doble corrupción: no se limita a mirar la última cabecera Received:, sino que recorre el historial completo para recuperar la fecha de recepción real. Vea también cómo corregir las fechas tras una migración a Microsoft 365 en general, y la guía específica sobre los INTERNALDATE incorrectos en IMAP para entender la mecánica subyacente.

Antes de migrar o después: dos momentos para actuar

Dos situaciones, dos posiciones.

Todavía no ha migrado. La buena noticia: es posible limitar los daños. Algunas herramientas de migración (MigrationWiz en modo Exchange, CloudM con las opciones correctas) preservan mejor las fechas que otras. Pero incluso en el mejor de los casos, una migración desde un alojamiento compartido sin un historial limpio probablemente dejará rastros. Planifique un análisis con Redate.io después de la migración, antes de entregar los buzones a los usuarios.

Ya ha migrado y los tickets no paran de llegar. Redate.io corrige los buzones existentes en Microsoft 365, independientemente de cuándo se realizó la migración. El análisis le dará una imagen precisa del estado real de cada buzón antes de cualquier intervención. Consulte también la checklist de migración de correo para evitar los mismos problemas en el futuro.

¿Ha migrado desde OVH, Infomaniak, Ionos u o2switch a Microsoft 365 y las fechas están mal? Cree una cuenta en Redate.io para analizar sus buzones de forma gratuita y ver exactamente el alcance del problema antes de tomar ninguna decisión.