Todos mis emails antiguos tienen la misma fecha: ¿qué ocurre?

El síntoma: todos sus emails antiguos agrupados en la misma fecha

Abre Outlook, Gmail o Apple Mail una mañana. Algo no cuadra. Cientos, a veces miles de emails antiguos muestran todos la misma fecha: la de hace unos días, o hace unas semanas. Mensajes de 2021, de 2019, de 2016 aparecen como si los hubiera recibido ayer. El orden por fecha ya no tiene ningún sentido. Busca un email importante del año pasado y está sepultado en un bloque de miles de mensajes que parecen llegar todos del mismo día.

Los emails nuevos, en cambio, muestran fechas correctas. Solo los mensajes antiguos están afectados.

¿Qué ha podido pasar?

El primer reflejo: culpar al software

Lo normal es pensar en un error. Outlook que ha fallado. Una actualización que salió mal. Un archivo corrupto. Y ahí empieza a menudo un calvario: se busca "error fecha Outlook", se encuentran foros que hablan de archivos OST, de SCANPST.exe, de recrear el perfil de Outlook desde cero...

Se pasan dos horas probando todo. El problema persiste.

Por cierto, SCANPST es una herramienta de reparación de archivos de datos locales de Outlook. Puede corregir ciertas corrupciones de archivo, pero no toca los datos almacenados en el servidor de correo. Es decir, aunque repare su archivo OST a la perfección, las fechas seguirán siendo incorrectas, porque el problema no está en su equipo.

El problema está en los propios emails, en el servidor.

Lo que ha pasado realmente: una migración

En prácticamente todos los casos, este síntoma aparece después de una migración de correo. Su empresa cambió de un sistema antiguo a Google Workspace, a Microsoft 365, o a un nuevo servidor. Alguien, en algún momento, usó una herramienta para transferir todos sus emails de un sitio a otro.

Quizás nadie se lo comunicó. O lo supo, pero no relacionó eso con el problema de fechas. Es completamente normal.

Estas herramientas de migración hacen un trabajo considerable: copian miles de mensajes, carpetas enteras, archivos adjuntos. Pero tienen un efecto secundario bastante traicionero. Cuando un email se transfiere de un servidor a otro, la herramienta añade una pequeña línea técnica en el mensaje, llamada cabecera "Received:", que indica cuándo llegó el mensaje al nuevo servidor. Es decir: la fecha de la migración.

Y ahí está el nudo del problema.

Cómo decide su cliente de correo qué fecha mostrar

Un email contiene en realidad varias fechas distintas, ocultas en sus datos técnicos. Está la fecha de envío original (la que normalmente ve), pero también hay cabeceras "Received:" que registran cada etapa del recorrido del mensaje por Internet.

(Si alguna vez ha hecho clic en "Ver fuente" o "Ver cabeceras completas" de un email, puede que haya visto esas líneas crípticas que parecen un bloque de texto incomprensible. Exactamente eso.)

En condiciones normales, su cliente de correo lee la cabecera "Received:" más reciente para determinar cuándo mostrar el email. Esta lógica funciona perfectamente: el último "Received:" siempre corresponde a la llegada del mensaje a su bandeja, pocos segundos después del envío.

Pero tras una migración, esa lógica se vuelve en su contra. La herramienta de migración ha añadido una nueva cabecera "Received:" al principio, con la fecha de la transferencia. Su cliente de correo lee esa cabecera primero, ve la fecha de migración y la muestra. La fecha de envío original sigue ahí, intacta, enterrada más abajo en los datos del email. Pero su cliente no la ve, porque se detiene en la primera cabecera.

Resultado: 8.000 emails que parecen llegar todos del mismo martes de noviembre.

¿Qué herramientas provocan este problema?

Las herramientas de migración más habituales tienen todas este comportamiento. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (la herramienta gratuita de Google para migrar desde Outlook), y muchas otras. No es exactamente un fallo de su parte: es una consecuencia del funcionamiento técnico del protocolo de correo. Estas herramientas añaden esa cabecera porque es lo que prevé el protocolo cuando un mensaje se transfiere de un servidor a otro.

El problema es que nadie avisa a los usuarios de que esto va a ocurrir.

Si su empresa ha cambiado recientemente de sistema de correo, o si su departamento de informática ha realizado una "migración a la nube", ese es muy probablemente el origen del problema. Puede verificarlo mirando las fechas afectadas: ¿corresponden todas aproximadamente al mismo período? Si es así, ese período es el de la migración.

Las falsas pistas que hay que evitar

Algunas soluciones que se encuentran habitualmente en los foros, y que no funcionan:

Reparar el archivo de datos con SCANPST

Ya lo hemos mencionado: SCANPST repara los archivos locales de Outlook (los archivos .pst o .ost almacenados en su equipo). No modifica los emails en el servidor. Tras la reparación, sus emails seguirán teniendo las mismas fechas incorrectas, porque esas fechas están en los propios emails, no en el archivo local.

Recrear el perfil de Outlook

Misma lógica. Recrear un perfil de Outlook equivale a partir de cero localmente y volver a descargar todos sus emails desde el servidor. Los emails descargados de nuevo tendrán exactamente las mismas fechas incorrectas que antes. Solo habrá perdido tiempo reconfigurando todo.

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

Algunos foros sugieren cambiar el criterio de ordenación en Outlook, pasando de la fecha de recepción a la fecha de envío. Puede ayudar en ciertos casos... pero no siempre. Y no resuelve nada para otros programas, otros dispositivos, ni para otras personas que accedan a su buzón. La causa de fondo sigue ahí. Ordenar por fecha de envío no es una solución, es un parche. (Puede leer más sobre esto en nuestro artículo sobre por qué ordenar por fecha de envío no resuelve el problema.)

Reinstalar el cliente de correo

No. Los emails están en el servidor, no en el software. Reinstalar Outlook, Gmail, Apple Mail o Thunderbird no cambia nada en los datos almacenados en línea.

La buena noticia: las fechas reales siguen ahí

Hay algo importante que entender, y que hace posible la corrección: la fecha de envío original de cada email no ha sido borrada. Sigue ahí, en el mensaje, en una cabecera llamada "Date:" que corresponde a la fecha de envío elegida por el remitente. Es un estándar de correo (definido por una especificación técnica llamada RFC 2822) que todas las herramientas de migración respetan, porque modificarlo supondría una violación grave de los estándares.

O sea, si recibió un email el 14 de marzo de 2022, ese email todavía contiene esa fecha en algún lugar de sus datos. Simplemente ya no es la que su cliente muestra en primer lugar.

Eso es precisamente lo que hace posible la corrección. El problema no es una pérdida de datos. Es una cuestión de lectura de metadatos: su cliente de correo lee la fecha incorrecta, mientras que la fecha correcta sigue presente.

¿Por qué no intentar corregirlo uno mismo?

Puede que se pregunte si un técnico informático puede simplemente escribir un script para corregir el problema. Entender lo que ocurre es una cosa. Corregirlo correctamente en miles de emails sin perder ninguno es otra muy distinta.

Un email no es un simple archivo de texto. Puede contener archivos adjuntos, firmas digitales, contenidos codificados en formatos complejos. Modificar los metadatos de un mensaje así sin deteriorarlo exige gestionar decenas de casos particulares: mensajes firmados electrónicamente (S/MIME), emails cifrados (PGP), codificaciones no estándar, estructuras de varias partes... Un script casero que funciona con 20 emails de prueba muy probablemente no funcionará bien en un buzón de producción de 15.000 mensajes. Y si algo sale mal, ¿cómo asegurarse de que ningún email se ha dañado o perdido? Con un script casero: imposible.

Sin un mecanismo de copia de seguridad y verificación individual para cada email, el riesgo de daños colaterales es real.

Qué hace Redate.io

Redate.io es un servicio diseñado específicamente para este problema. Se conecta a su buzón de correo (Google Workspace, Microsoft 365, o un servidor IMAP), identifica los emails cuyas fechas han sido alteradas por una migración, y los corrige mediante un motor propietario que analiza la cadena completa de cabeceras y reconstruye los metadatos de fecha de cada mensaje.

Cada email corregido se verifica de forma individual. Los originales se conservan en una carpeta de copia de seguridad visible durante 30 días. Si algo no va bien, puede dar marcha atrás.

El análisis inicial es gratuito: Redate.io examina su buzón y le muestra exactamente cuántos emails están afectados antes de que tome ninguna decisión. Sin sorpresas.

El precio es un pago único, basado en el volumen de emails a corregir. Sin suscripción. Paga una vez, el problema queda resuelto.

¿Quiere ver el alcance del problema antes de comprometerse? Lance un análisis gratuito de su buzón en Redate.io y descubra en pocos minutos cuántos emails están afectados.