Por qué un email no es lo que parece: la estructura oculta
Cuando abres un correo electrónico, tu cliente de correo te muestra cuatro datos: el remitente (From), el destinatario (To), el asunto (Subject) y el cuerpo del mensaje. Parece simple, directo, completo. Pero esos cuatro campos son solo la superficie visible de una estructura mucho más compleja que el usuario nunca ve —y que, en un contexto judicial, contiene la información más valiosa.
Debajo de esa capa visible existe un bloque de headers (cabeceras técnicas) que el servidor de correo genera automáticamente cada vez que el mensaje se envía, retransmite o recibe. Estos headers incluyen campos como Received (que traza la ruta completa del email entre servidores), Message-ID (identificador único e irrepetible del mensaje), DKIM-Signature (firma criptográfica del dominio remitente), Authentication-Results (resultado de las verificaciones SPF, DKIM y DMARC) y Return-Path (dirección real de rebote, que puede diferir del From visible).
La diferencia entre lo que el usuario ve y lo que realmente contiene el email es enorme. El campo From que aparece en pantalla es un dato que el remitente puede configurar libremente —incluso con una dirección falsa—. Los headers, en cambio, son generados por los servidores que procesan el mensaje y contienen la traza real de la comunicación: por dónde pasó, quién lo envió realmente, si la firma criptográfica coincide con el dominio declarado y si los mecanismos anti-suplantación validaron o rechazaron el mensaje.
Para un perito informático, los headers son el ADN del email. Sin ellos, un correo electrónico presentado como prueba no es más que un texto formateado que cualquiera podría haber fabricado. Con ellos, es posible verificar la autenticidad del remitente, reconstruir la cronología exacta del envío y la recepción, y detectar intentos de manipulación o suplantación.
Headers de email: qué revelan y cómo se analizan
El análisis de headers es el núcleo del peritaje de correo electrónico. Cada header aporta una pieza del rompecabezas que permite reconstruir qué ocurrió realmente con un mensaje.
Received (cabeceras de ruta)
Cada servidor de correo que procesa el mensaje añade un header Received con su identidad, la IP de origen, el protocolo utilizado y la marca temporal. Se leen de abajo hacia arriba: el último Received es el primer salto (el servidor de envío) y el primero es el servidor de destino. Permiten trazar la ruta completa del email y detectar saltos anómalos, servidores intermedios sospechosos o inconsistencias temporales.
Message-ID
Identificador único generado por el servidor de envío en el momento de la creación del mensaje. Tiene formato <cadena-unica@dominio> y no debería repetirse nunca. Permite vincular un email con los logs del servidor de correo y demostrar que un mensaje concreto existió y fue procesado. Si se detectan dos emails con el mismo Message-ID y contenido distinto, hay evidencia de manipulación.
DKIM-Signature
Firma criptográfica que el servidor de envío genera usando la clave privada del dominio. Cubre campos específicos del header y el cuerpo del mensaje. El receptor verifica esta firma consultando la clave pública en el registro DNS del dominio. Si la verificación es positiva, acredita que el email fue enviado por un servidor autorizado del dominio y que el contenido firmado no fue alterado. Es una de las pruebas más robustas de autenticidad.
SPF y DMARC
SPF (Sender Policy Framework) verifica que la IP del servidor que envió el email está autorizada por el dominio del remitente, consultando un registro TXT en el DNS. DMARC (Domain-based Message Authentication, Reporting and Conformance) combina los resultados de SPF y DKIM y define la política del dominio ante fallos de autenticación. Los resultados de ambas verificaciones se registran en el header Authentication-Results, que el perito analiza para confirmar o descartar la legitimidad del envío.
El perito no se limita a leer headers individuales: los correlaciona entre sí y con fuentes externas (logs del servidor, registros DNS históricos, bases de datos de reputación IP) para construir una conclusión sólida sobre la autenticidad, integridad y cronología del mensaje.
Metadatos de adjuntos: la evidencia dentro de la evidencia
Un email no es solo texto: los archivos adjuntos contienen sus propios metadatos, que a menudo aportan evidencia independiente y complementaria al propio mensaje. Estos metadatos son generados automáticamente por las aplicaciones que crearon los archivos y no son visibles para el usuario en condiciones normales.
Los documentos de Microsoft Office (Word, Excel, PowerPoint) almacenan en sus propiedades campos como el autor original, el último usuario que los modificó, la empresa configurada en la instalación de Office, las fechas de creación y última modificación, el tiempo total de edición y el número de revisiones. Si un contrato que supuestamente firmó una empresa tiene como autor registrado a un empleado de la empresa contraria, o si la fecha de creación del documento es posterior a la fecha del email que lo adjunta, esas discrepancias son evidencia pericial de primer orden.
Los archivos PDF también contienen metadatos relevantes: aplicación con la que fueron generados (Adobe Acrobat, LibreOffice, wkhtmltopdf), autor, fechas de creación y modificación, y, en el caso de PDFs firmados digitalmente, la información del certificado utilizado. Un PDF que dice haber sido creado con Adobe Acrobat Pro pero cuyos metadatos internos revelan que fue generado con una herramienta de edición de PDFs puede indicar una manipulación.
Las imágenes (JPEG, PNG, TIFF) contienen datos EXIF que pueden incluir el modelo de cámara o dispositivo, la fecha y hora de captura, las coordenadas GPS de la ubicación y los parámetros de la toma. En un litigio, una fotografía adjunta cuyo EXIF muestre una geolocalización incompatible con la versión de los hechos del remitente puede resultar decisiva. El perito extrae y documenta todos estos metadatos como parte del análisis integral del email.
Cómo preservar un email como prueba: lo que NO debes hacer
La forma en que se preserva un email determina su valor como prueba. La mayoría de errores que comprometen la evidencia ocurren antes de que el perito intervenga, cuando el propio cliente o su abogado intentan «guardar» el correo sin conocer las implicaciones técnicas.
No reenvíes el email
Al reenviar, el cliente de correo genera nuevos headers (nuevo Message-ID, nuevas cabeceras Received) y los headers originales se pierden o quedan incrustados como texto plano. El email reenviado es, técnicamente, un mensaje distinto del original, sin posibilidad de verificación criptográfica.
No lo imprimas
Una impresión pierde los headers, la firma DKIM, los metadatos MIME, los metadatos de los adjuntos y la estructura técnica completa. Lo que queda en papel es solo la capa visual, que cualquier persona con conocimientos de HTML podría fabricar desde cero.
No hagas una captura de pantalla
Una captura pierde absolutamente todo lo verificable: headers, firma DKIM, metadatos de adjuntos, estructura MIME. Es una imagen de píxeles sin ninguna información técnica que permita acreditar la autenticidad. Además, es trivial manipular lo que aparece en pantalla con las herramientas de inspección del navegador.
Lo correcto: preservación con garantías
- 1Exportar como .eml o .msg directamente desde el cliente de correo (Outlook, Thunderbird, Gmail mediante Google Takeout). Estos formatos preservan los headers completos, la estructura MIME y todos los adjuntos con sus metadatos.
- 2Calcular el hash (SHA-256) del archivo exportado inmediatamente después de la exportación. Este valor será la referencia de integridad que permitirá demostrar que el archivo no ha sido modificado desde su extracción.
- 3Documentar la cadena de custodia: quién realizó la exportación, desde qué cuenta y dispositivo, en qué fecha y hora, y dónde se almacena el archivo. Sin esta documentación, el hash por sí solo no es suficiente.
Suplantación de email (spoofing): cómo detectarla pericialmente
La suplantación de identidad en correo electrónico (email spoofing) consiste en enviar un email con un campo From falso —una dirección que no pertenece al remitente real— para hacer creer al receptor que el mensaje proviene de una persona o entidad de confianza. Es una técnica habitual en fraudes empresariales (estafas BEC/CEO fraud), en campañas de phishing y en la fabricación de evidencia digital.
Desde el punto de vista pericial, la detección del spoofing se basa en la comparación entre lo que dice el email en su capa visible y lo que revelan los headers técnicos. El campo From puede mostrar «director@empresa.com», pero los headers Received muestran que el mensaje fue enviado desde un servidor con IP 185.XX.XX.XX que no tiene ninguna relación con el dominio empresa.com. Esa discrepancia es la primera señal.
La segunda línea de verificación es la firma DKIM. Si el email fue enviado desde un servidor no autorizado por el dominio, la firma DKIM estará ausente o fallará la verificación. El header Authentication-Results registrará dkim=fail o dkim=none, evidencia técnica objetiva de que el servidor de envío no estaba autorizado.
Lo mismo ocurre con SPF: si la IP del servidor de envío no está incluida en el registro SPF del dominio del remitente, el resultado será spf=fail. Y si el dominio tiene configurada una política DMARC estricta (p=reject o p=quarantine), el propio servidor receptor debería haber bloqueado el mensaje —lo que implica que, si llegó a la bandeja de entrada, o el dominio no tenía DMARC configurado, o la política era laxa.
En la práctica pericial, he analizado casos donde un email supuestamente enviado por un directivo autorizando una transferencia bancaria resultó tener un header Received que apuntaba a un servidor en un país distinto, con DKIM ausente y SPF en fallo. La empresa realizó la transferencia por el aspecto legítimo del email, pero el análisis técnico demostró que el mensaje nunca salió del servidor de correo de la organización. Estos casos subrayan la importancia de verificar los headers antes de confiar en el From visible.
El informe pericial de email: qué debe acreditar
Cuando un perito informático judicial elabora un informe sobre evidencia de correo electrónico, el documento debe cubrir cuatro pilares fundamentales para que el tribunal pueda valorar la prueba con todas las garantías:
Autenticidad del remitente
Verificación de que el email fue efectivamente enviado desde el dominio y la cuenta que aparecen en el campo From. Se acredita mediante el análisis de la firma DKIM (verificación criptográfica contra la clave pública del dominio), el resultado SPF (IP de envío autorizada) y la coherencia de los headers Received con la infraestructura de correo del dominio remitente.
Integridad del contenido
Demostración de que el email no ha sido modificado desde su envío. La firma DKIM cubre el cuerpo del mensaje y ciertos headers: si la verificación es positiva, el contenido firmado está intacto. Adicionalmente, el hash del archivo .eml/.msg calculado en el momento de la adquisición garantiza que la copia analizada no ha sido alterada durante el proceso pericial.
Cronología verificable
Análisis de los timestamps contenidos en los headers Received para establecer la secuencia temporal del envío: cuándo salió del servidor de origen, cuándo fue procesado por cada servidor intermedio y cuándo llegó al buzón del destinatario. Estos timestamps se contrastan entre sí y con los husos horarios de cada servidor para detectar inconsistencias o manipulaciones temporales.
Identidad del emisor y receptor
Vinculación del email con personas concretas. Más allá de la dirección de correo, el perito correlaciona la IP de envío con registros WHOIS, logs de acceso al servidor de correo, configuraciones de clientes de correo (headers X-Mailer, X-Originating-IP) y, en su caso, metadatos de los adjuntos que identifiquen al autor de los documentos.
El informe debe ser técnicamente riguroso pero comprensible para un juez no especializado. Las conclusiones deben apoyarse en datos verificables y reproducibles: otro perito, con acceso al mismo archivo .eml y a las mismas fuentes, debería poder confirmar o refutar cada afirmación del informe. Esta reproducibilidad es lo que distingue un informe pericial sólido de una opinión técnica subjetiva.
¿Necesitas certificar emails como prueba judicial?
Analizo los headers, verifico la autenticidad mediante DKIM/SPF y documento la cadena de custodia para que tus emails tengan pleno valor probatorio ante cualquier tribunal de Mallorca.
Preguntas frecuentes
Un email reenviado tiene un valor probatorio muy reducido. Al reenviarlo, el cliente de correo genera nuevos headers (nuevo Message-ID, nuevos Received), y los headers originales que acreditan la ruta y autenticación del mensaje se pierden o quedan embebidos como texto plano sin posibilidad de verificación técnica. Un juez puede admitirlo como indicio, pero la parte contraria podrá impugnarlo fácilmente argumentando que el contenido pudo ser manipulado antes del reenvío. Lo correcto es exportar el email original en formato .eml o .msg con todos sus headers intactos.
Sí, la suplantación del remitente (email spoofing) es técnicamente sencilla: el protocolo SMTP permite configurar cualquier dirección en el campo From. Sin embargo, los mecanismos de autenticación modernos —DKIM, SPF y DMARC— dejan evidencia verificable de si el email realmente fue enviado desde el servidor autorizado del dominio. Un perito analiza los headers Received, la firma DKIM y el registro SPF para determinar si el remitente mostrado coincide con el servidor que realmente envió el mensaje.
DKIM (DomainKeys Identified Mail) es un mecanismo de autenticación que firma criptográficamente ciertos campos del email (incluido el cuerpo) con la clave privada del servidor de envío. El receptor puede verificar esa firma consultando la clave pública publicada en el DNS del dominio remitente. Si la firma DKIM es válida, acredita dos cosas: que el email fue enviado desde un servidor autorizado por ese dominio y que el contenido no fue alterado en tránsito. Para un perito, una firma DKIM válida es una de las pruebas más sólidas de autenticidad.
Una impresión en papel de un email pierde toda la información técnica que permite verificar su autenticidad: los headers completos, la firma DKIM, los metadatos de los adjuntos y la estructura MIME del mensaje. Cualquier persona con conocimientos básicos puede fabricar un email visualmente idéntico mediante edición HTML. Por sí sola, una impresión tiene un valor probatorio mínimo. Necesita complementarse con una certificación pericial que acredite la autenticidad del original digital, o al menos con un acta notarial de la pantalla del buzón.
Depende del servidor y del tiempo transcurrido. En servidores corporativos (Exchange, Google Workspace con retención), los emails eliminados pueden permanecer en una papelera administrativa o en backups durante un periodo configurable (30, 90 o más días). En servidores IMAP estándar, una vez purgados del buzón y del backup, la recuperación requiere técnicas forenses sobre el disco del servidor, con posibilidades que disminuyen con el tiempo y la actividad posterior.
Los formatos .eml (estándar RFC 5322, utilizado por Thunderbird y otros clientes) y .msg (formato propietario de Microsoft Outlook) preservan los headers completos, la estructura MIME, los adjuntos y sus metadatos. El formato .pst/.ost de Outlook conserva buzones completos. En cambio, exportar como PDF, imprimir o hacer capturas de pantalla pierde toda la información técnica necesaria para una verificación pericial. Siempre se debe exportar en .eml o .msg y calcular el hash del archivo resultante.
No de forma fiable y universal. Algunos sistemas de correo corporativo (Exchange, Google Workspace) registran en logs del servidor cuándo se accedió a un mensaje. Los acuses de recibo (disposition notifications) dependen de que el receptor los acepte. Los píxeles de seguimiento (tracking pixels) pueden detectar la apertura, pero son bloqueados por muchos clientes de correo. Un perito puede correlacionar logs del servidor de correo, metadatos del cliente y otros indicios para establecer una ventana temporal probable de lectura, pero rara vez puede certificar el momento exacto con certeza absoluta.
El acta notarial digital consiste en que un notario da fe de lo que ve en pantalla en un momento determinado: que en el buzón del cliente aparece un email concreto con determinado contenido. Sin embargo, el notario no analiza los headers, no verifica DKIM/SPF ni examina los metadatos técnicos. La certificación pericial va más allá: el perito extrae el email con headers completos, verifica su autenticidad mediante análisis de DKIM, SPF y la cadena de Received, analiza los metadatos de los adjuntos y documenta técnicamente la integridad del mensaje. Ambas son complementarias, pero la pericial aporta la capa técnica que el acta notarial no cubre.