¿Se puede cambiar la fecha de un email recibido?

La pregunta que todo el mundo hace (y por qué esconde dos situaciones muy distintas)

Escriba "cambiar la fecha de un email recibido" en Google. Aparecen decenas de hilos en los foros de Microsoft Q&A, threads de Reddit, preguntas en Quora. La demanda es clara, pero las razones detrás son radicalmente distintas según quien pregunta.

Hay quienes buscan falsificar una fecha de forma retroactiva, por motivos que prefiero no imaginar. Y hay administradores IT que, tras una migración IMAP, ven todos sus correos mostrando el mismo día (el de la migración), y simplemente quieren recuperar las fechas reales. Estas dos situaciones no tienen nada que ver entre sí, pero comparten la misma búsqueda.

Este artículo responde a las dos. Spoiler: en el primer caso, la modificación no es realmente posible de forma indetectable. En el segundo, es completamente legítima y es exactamente lo que hace Redate.io.

Primero: ¿qué es la "fecha" de un email?

Un email no contiene una sola fecha. Contiene varias, almacenadas en sitios distintos, controladas por entidades distintas.

La cabecera Date: (RFC 2822)

Es la fecha que el cliente del remitente inscribe en el mensaje en el momento del envío. Es visible en las cabeceras en bruto con este formato:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Esta cabecera forma parte del cuerpo del mensaje. Técnicamente puede modificarse si se accede al archivo en bruto. Pero "técnicamente" es la palabra clave aquí.

Las cabeceras Received:

Cada servidor de correo por el que pasa un email añade su propia cabecera Received: con un timestamp. Estas cabeceras forman una cadena cronológica, desde el servidor del remitente hasta su buzón. (Por cierto, si alguna vez ha intentado leer las cabeceras en bruto de un email, sabe que no es exactamente lectura de playa. Decenas de líneas de metadatos técnicos, en un orden que va del más reciente al más antiguo.)

El INTERNALDATE IMAP

Es el metadato más importante para entender por qué ciertas modificaciones no tienen ningún efecto visible. El INTERNALDATE es un atributo almacenado en el lado del servidor IMAP, independientemente del contenido del mensaje. Es el que la mayoría de los clientes de correo utilizan para ordenar los emails en las carpetas. Outlook lo usa. Gmail también. Apple Mail, en la mayoría de los casos, igual.

El INTERNALDATE no está en el mensaje. Está en la base de datos del servidor. No puede modificarse editando un archivo .eml en su disco.

Qué ocurre realmente cuando se modifica localmente

Editar un archivo .eml

Técnicamente, un archivo .eml es un archivo de texto. Puede abrirlo en un editor, cambiar la línea Date: y guardarlo. Si reimporta ese archivo en un cliente de correo local, la fecha mostrada puede cambiar, según el cliente.

Pero esto es lo que no cambia:

• El INTERNALDATE en el servidor IMAP (sigue intacto)
• Las cabeceras Received: añadidas por los servidores intermedios
• Los registros de entrega en Google, Microsoft o su proveedor
• La firma DKIM, si el mensaje la tenía

Resultado: en su máquina local quizás ve una fecha distinta. Desde Outlook conectado a Exchange Online, o Gmail en un navegador, nada ha cambiado.

Cambiar el reloj del sistema

Algunos foros sugieren modificar el reloj del equipo para "engañar" al cliente de correo. No funciona. Outlook y Gmail no leen la hora del sistema para mostrar las fechas de los emails recibidos. Leen el INTERNALDATE desde el servidor, o las cabeceras del mensaje. El reloj local no interviene en ningún punto de ese proceso.

La manipulación mediante Thunderbird

Thunderbird ofrece más flexibilidad que la mayoría de los clientes. Con extensiones o manipulando directamente el perfil (archivos mbox, archivos .msf), algunos intentan modificar la visualización de las fechas. Puede funcionar dentro de Thunderbird para emails almacenados localmente en modo POP3. Pero en cuanto Thunderbird está conectado por IMAP, resincroniza con el servidor. La "corrección" desaparece en la siguiente sincronización.

DKIM: la barrera invisible que nadie menciona

La mayoría de los emails enviados desde 2018 están firmados con DKIM (DomainKeys Identified Mail). Una firma DKIM tiene este aspecto en las cabeceras:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

El campo h= lista las cabeceras cubiertas por la firma. En el ejemplo anterior, Date está firmado. Si modifica la cabecera Date: del mensaje, la verificación DKIM falla. Cualquier servidor de correo, cualquier herramienta de análisis forense, puede detectar la modificación recalculando la firma.

No es una protección perfecta (un remitente malintencionado controla su propia clave DKIM y puede firmar lo que quiera en el momento del envío). Pero para un email ya recibido y firmado, modificar la cabecera Date: deja un rastro detectable.

Los registros del servidor: la verdadera fuente de verdad

Aunque lograra modificar todos los metadatos visibles de un email (cabeceras, INTERNALDATE, todo), los proveedores conservan sus propios registros.

Google Workspace registra cada mensaje en los logs de auditoría de la Admin Console. Microsoft 365 hace lo mismo en el Centro de cumplimiento (Purview). Esos registros incluyen los timestamps de entrega, con independencia de lo que se muestre en los clientes. Un abogado, un departamento jurídico o un equipo de seguridad informática puede recuperar esos datos. La fecha visible en Outlook no tiene validez ante un tribunal ni durante una auditoría de seguridad.

Para ser precisos: ni siquiera un administrador con acceso al buzón mediante delegación de dominio puede reescribir esos registros de forma retroactiva. Están fuera del alcance de los usuarios, incluso de los más privilegiados.

El caso legítimo: la corrección post-migración

Acaba de terminar una migración de 150 buzones desde un Exchange on-premise a Microsoft 365. El lunes siguiente llegan los tickets: "todos mis correos antiguos tienen fecha del viernes pasado". La fecha de la migración.

Este es un problema bien documentado y completamente distinto de lo que acabamos de describir. Aquí nadie quiere falsificar nada. Las fechas originales reales siguen existiendo, intactas, en la cabecera Date: de cada mensaje. El problema viene de otro lado: la herramienta de migración (BitTitan MigrationWiz, CloudM, imapsync u otra) insertó una cabecera Received: con la fecha de migración al inicio de la cadena. Outlook, que en ciertos contextos se basa en las cabeceras Received: más recientes en lugar del INTERNALDATE, muestra esa fecha en su lugar.

En este caso, la "corrección" consiste en restablecer la coherencia entre lo que dice el mensaje (la cabecera Date: original, que sigue ahí) y lo que cree el servidor (el INTERNALDATE, fijado en el momento de la migración). No es falsificación. Es restauración.

Es exactamente el problema que una migración mal configurada impone a miles de buzones. Y es lo que Redate.io resuelve.

Por qué hacerlo uno mismo falla a escala

Entender el problema es una cosa. Corregirlo en 40.000 correos repartidos en 150 buzones sin perder ni uno, es otra muy distinta.

Los scripts que se encuentran en GitHub o Stack Overflow funcionan con 20 correos de prueba. En producción se encuentran con problemas que el autor del script no había anticipado:

• Los correos firmados con S/MIME o cifrados con PGP tienen estructuras que no se manipulan como mensajes ordinarios
• Los mensajes multipart con fronteras MIME no estándar provocan errores de análisis
• Las cabeceras codificadas en RFC 2047 (caracteres no ASCII en los campos From: o Subject:) rompen los parsers más básicos
• Las APIs de Google y Microsoft imponen límites de tasa (rate limiting): a las 3 de la madrugada durante un lote de 30.000 correos, el error 429 Too Many Requests no está gestionado, el script se detiene y nadie sabe dónde se quedó
• Sin mecanismo de reversión: si un mensaje resulta dañado durante el procesamiento, no hay forma de volver atrás

Redate.io conserva una copia de cada email original en una carpeta de copia de seguridad visible durante 30 días. Cada corrección se verifica de forma individual. El motor de análisis gestiona cientos de firmas de herramientas de migración conocidas, además de todos los casos límite que un script casero no trataría.

Para profundizar según la herramienta utilizada: BitTitan MigrationWiz y las fechas de correo, o CloudM Migrate: corregir fechas incorrectas.

Qué cambia y qué no cambia nunca

La distinción es clara. Las tres primeras filas de la tabla describen modificaciones superficiales o detectables. La última describe una corrección legítima de metadatos, alineada con el contenido original del mensaje, después de una migración que introdujo una incoherencia.

Si está en la situación descrita en la última fila, tras una migración con imapsync, BitTitan, CloudM u otra herramienta, Redate.io está diseñado para eso.

¿Sus correos muestran la fecha de migración en lugar de las fechas reales? Escanee gratuitamente sus buzones con Redate.io y vea exactamente cuántos correos están afectados antes de decidir.