Antedatar un email: posible y detectable

Antedatar un correo: ¿de qué hablamos exactamente?

La pregunta aparece con frecuencia en foros de administración de sistemas y grupos de Slack de MSPs: ¿se puede modificar la fecha de un correo electrónico después de enviarlo? La respuesta corta es sí, técnicamente. Pero la respuesta completa es mucho menos tranquilizadora para quien quiera hacerlo con fines dudosos.

Un correo electrónico no es un archivo monolítico. Es una colección de encabezados de texto seguidos de un cuerpo de mensaje. Entre esos encabezados, varios contienen información de fecha. Y algunos son más fáciles de modificar que otros.

Tres capas de datación coexisten en cada correo:

• El encabezado Date: (RFC 2822), escrito por el cliente de correo en el momento del envío
• Los encabezados Received:, añadidos por cada servidor que retransmite el mensaje
• El INTERNALDATE de IMAP, un metadato almacenado en el servidor, independiente del contenido del mensaje

Cada una de estas capas es modificable. Ninguna lo es sin dejar rastro.

Modificar el encabezado Date:: la manipulación más evidente

El encabezado Date: es texto plano dentro del archivo .eml. Técnicamente, cualquier editor hexadecimal o script de Python puede reescribirlo en cuestión de segundos. Si alguna vez ha abierto los encabezados brutos de un correo en Gmail (el pequeño menú "Mostrar original"), sabe que cualquiera puede leerlos.

El problema es que desde 2004, la gran mayoría de los servidores de correo firman los mensajes salientes con DKIM (DomainKeys Identified Mail). Esta firma criptográfica cubre explícitamente varios encabezados: Date:, From:, Subject: y el cuerpo del mensaje. La firma se almacena en el encabezado DKIM-Signature:.

Modificar el Date: después de la firma invalida mecánicamente la verificación DKIM. Cualquier servidor receptor puede comprobar la firma recuperando la clave pública del DNS del dominio remitente. Si la firma ya no coincide, el mensaje queda marcado como alterado. Gmail, Outlook.com y todos los grandes proveedores realizan esta verificación de forma automática.

(Por cierto, si quiere ver una firma DKIM en concreto, abra los encabezados brutos de cualquier correo recibido desde Gmail o Office 365: encontrará una línea DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... que parece ruido pero que en realidad es un hash criptográfico de todo el mensaje.)

Resultado: modificar el Date: en un correo firmado con DKIM es romper el sello. La modificación es visible para cualquier administrador que sepa dónde buscar.

Reescribir los encabezados Received:: una cadena difícil de falsificar

Los encabezados Received: trazan el recorrido de un correo entre el remitente y el destinatario. Cada servidor SMTP que toca el mensaje añade uno, con su nombre, su dirección IP y una marca de tiempo. Un correo que pasa por dos o tres relés contiene dos o tres encabezados Received: apilados.

¿Se pueden modificar? Técnicamente sí, en la propia copia del mensaje. Pero aquí está la trampa: el destinatario también tiene una copia. Y su servidor añadió su propio encabezado Received: al final. Ese encabezado está bajo el control del destinatario, no del remitente. Es imposible falsificarlo desde fuera.

La coherencia de la cadena es verificable. Si las marcas de tiempo de los Received: sucesivos son incoherentes (un relé intermedio habría recibido el mensaje antes de que el remitente lo enviara, por ejemplo), eso resulta sospechoso de inmediato. Herramientas de análisis forense como MXToolbox o las utilidades internas de los equipos de seguridad verifican exactamente eso.

La verdad es que no es del todo exacto decir que los Received: son completamente imposibles de falsificar: un atacante que controla su propia infraestructura de correo puede fabricar encabezados creíbles para los relés que domina. Pero nunca controla el último eslabón: el servidor del destinatario.

El INTERNALDATE de IMAP: el caso más técnico

El INTERNALDATE es un metadato IMAP almacenado en el servidor. No es un encabezado dentro del propio mensaje: es un valor que el servidor asocia al mensaje en su base de datos interna. Es ese valor el que la mayoría de los clientes de correo utilizan para ordenar los mensajes en la bandeja de entrada.

El comando IMAP APPEND permite depositar un mensaje en un servidor especificando explícitamente un INTERNALDATE. Es una funcionalidad legítima del protocolo, documentada en la RFC 3501. Las herramientas de migración la usan constantemente: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... todas depositan correos en el servidor de destino con un INTERNALDATE especificado.

En teoría, alguien con acceso IMAP a su propio buzón podría depositar un correo con cualquier INTERNALDATE. Pero esa manipulación no modifica los encabezados del mensaje. El Date: original sigue intacto, los Received: siguen intactos, la firma DKIM sigue intacta. Solo cambia el metadato de ordenación en el servidor.

Para un experto que examine el mensaje en bruto, la discordancia entre el INTERNALDATE y el Date: es visible de inmediato. Y si el mensaje está firmado con DKIM, la fecha original queda atestiguada criptográficamente.

El Message-ID: una huella difícil de falsificar

Cada correo genera un identificador único, el encabezado Message-ID:. Ese identificador lo construye el servidor SMTP remitente en el momento del envío, combinando generalmente una marca de tiempo, un identificador aleatorio y el nombre de dominio del servidor.

Un Message-ID típico tiene este aspecto: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. La marca de tiempo suele estar codificada directamente en el identificador. Modificar la fecha del mensaje dejando un Message-ID con una marca de tiempo incompatible crea una incoherencia que se detecta de inmediato.

Además, los Message-ID están indexados por los grandes sistemas de mensajería. Google, Microsoft y otros actores mantienen registros que permiten rastrear cuándo circuló realmente un mensaje por sus infraestructuras. En un contexto legal o forense, esos registros son accesibles mediante procedimientos judiciales.

En la práctica: ¿quién puede detectar un intento de manipulación?

Planteemos la pregunta de forma concreta. Recibe un correo del que sospecha que la fecha ha sido modificada. ¿Qué puede hacer un administrador de IT o un abogado con un mínimo de conocimientos técnicos?

• Verificación DKIM: en Gmail, el menú "Mostrar original" muestra directamente el resultado de la verificación DKIM al principio de la página. Un "PASS" confirma la integridad del mensaje desde el envío. Un "FAIL" o "SOFTFAIL" señala una alteración.
• Análisis de encabezados: herramientas como MXToolbox Header Analyzer o Google Admin Toolbox analizan automáticamente la cadena de Received: y señalan las incoherencias temporales.
• Coherencia Message-ID / Date: un analista puede comparar la marca de tiempo codificada en el Message-ID con el valor del Date: declarado.
• Registros del servidor: si el correo ha pasado por un servidor del que es administrador, los registros SMTP contienen la fecha y hora reales de aceptación del mensaje, con independencia de cualquier encabezado.

En definitiva, las herramientas de detección son accesibles, gratuitas y no requieren experiencia forense avanzada. Un administrador de IT medianamente curioso puede verificar la integridad de un correo en menos de dos minutos.

El único caso legítimo de modificación masiva de fechas: la migración IMAP

Existe un escenario en el que cientos de miles de correos acaban con fechas incorrectas sin ninguna intención maliciosa: la migración IMAP.

Acaba de terminar la migración de 150 buzones de Exchange a Google Workspace. El lunes por la mañana empiezan a llegar los tickets. Los usuarios reportan que todos sus correos antiguos se muestran con la misma fecha, la del fin de semana de la migración. Sus bandejas de entrada son ilegibles.

Lo que ocurrió está documentado y es predecible: la herramienta de migración (BitTitan, CloudM, imapsync, da igual cuál) depositó los correos en Google Workspace mediante IMAP APPEND. Especificó un INTERNALDATE correspondiente a la fecha de la migración, no a la fecha original del correo. Resultado: Outlook, que ordena por INTERNALDATE de forma predeterminada, muestra la fecha de migración para todos los mensajes. Fechas incorrectas en emails tras migración IMAP explica este mecanismo en detalle.

El encabezado Date: original está intacto en cada mensaje. Las firmas DKIM están intactas. El contenido no ha cambiado. Solo el INTERNALDATE en el servidor es incorrecto.

Este problema afecta a BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO y a todas las herramientas que usan IMAP APPEND sin preservar correctamente el INTERNALDATE. El artículo dedicado a BitTitan MigrationWiz cubre las particularidades de esa herramienta. El checklist de migración de correo lista los puntos que hay que verificar antes y después de una migración para evitar este tipo de problema.

La diferencia entre corregir y falsificar

La corrección que realiza Redate.io es todo lo contrario de un intento de falsificación. El motor de corrección propietario analiza la cadena de encabezados de cada mensaje, identifica la fecha original codificada en el encabezado Date: (RFC 2822) que nunca ha cambiado, y corrige los metadatos de fecha para alinearlos con esa información auténtica ya presente en el mensaje.

El encabezado Date: es la fuente de verdad. Lo escribió el cliente de correo del remitente en el momento del envío. Está cubierto por la firma DKIM. Redate.io no lo modifica. Lo que se corrige es la discordancia introducida por la herramienta de migración, no la fecha original.

Corregir 47.000 correos tras una migración fallida sin perder ninguno, sin romper los hilos de conversación, sin corromper los archivos adjuntos, sin provocar un error 429 a las 3 de la madrugada en la API de Google: eso exige un pipeline de análisis en múltiples etapas con gestión de casos límite (S/MIME, PGP, codificaciones no ASCII según RFC 2047, estructuras multipart complejas). Un script de Python de cinco líneas no sobreviviría al primer buzón de producción. ¿Se pueden corregir fechas de email tras migración? detalla por qué el enfoque DIY es arriesgado con volúmenes reales.

Redate.io escanea los buzones de correo de forma gratuita, identifica los mensajes con fechas incorrectas y los corrige mediante un pipeline de validación que verifica cada mensaje individualmente. Los originales se conservan en una carpeta de copia de seguridad visible durante 30 días. Si algo sale mal, el rollback es posible.

¿Su migración ha desplazado las fechas de sus correos? Lance un escaneo gratuito en Redate.io para medir el alcance del problema antes de decidir qué hacer.