Cómo demostrar que enviaste un correo: encabezados y hashes

Para demostrar que se envió un correo electrónico necesitas los encabezados técnicos del mensaje, no una captura de pantalla. La cadena Received, el Message-ID y los Authentication-Results (SPF, DKIM, DMARC) muestran de dónde viene el correo y cómo viajó. Si combinas esos encabezados con un hash SHA-256 del archivo original, tienes una prueba que revela cualquier manipulación y en la que un juez o un responsable de RR. HH. puede confiar de verdad.

Puntos clave

• Una captura de pantalla de la bandeja de entrada no prueba casi nada: se edita con facilidad y no incluye encabezados, ni cadena de transporte, ni hash de integridad.

• La prueba real está en los encabezados del correo: la cadena Received (los saltos que dio), el Message-ID (una huella única) y los veredictos de SPF/DKIM/DMARC que indican si el remitente fue autenticado.

• Un hash SHA-256 del archivo .eml or .msg original actúa como ancla que revela manipulaciones: si cambias un solo byte, el hash cambia.

• Solo el fraude por compromiso del correo electrónico empresarial (Business Email Compromise) causó pérdidas de 2770 millones de dólares en 21 442 denuncias en 2024 (fuente: FBI IC3 2024 Annual Report, 2025), así que la autenticidad del correo importa más que nunca.

• Herramientas como PDFengine convierten un correo en bruto en un informe de autenticidad de una página, con los encabezados y un hash, sin renderizar el cuerpo. Ten presentes los límites, explicados con franqueza más abajo.

Cuando necesitan demostrar que existe un correo, la mayoría de la gente recurre a una captura de pantalla. Parece lo más obvio. El problema es que una captura es la forma más débil de prueba digital, y las personas que importan (jueces, árbitros, investigadores de RR. HH.) lo saben.

La prueba de un correo debe cumplir criterios reales de autenticidad, no solo parecer convincente.

¿Por qué una captura de pantalla de un correo no es una prueba válida?

Una captura de pantalla no demuestra nada desde el punto de vista criptográfico y es fácil de falsificar. Cualquiera puede editar texto con las herramientas para desarrolladores del navegador, reescribir la dirección del remitente o retocar una imagen en segundos. Por eso la pregunta surge tantas veces: en el sitio jurídico de preguntas y respuestas Avvo, la gente pregunta con frecuencia «¿qué admisibilidad tiene como prueba ante un tribunal una captura de pantalla de cuentas no verificadas?». La respuesta sincera es que, por sí sola, tiene muy poco peso.

Una captura de pantalla recoge la superficie renderizada de un correo. Descarta todo lo que hay debajo: los encabezados que registran el servidor de envío, el Message-ID único, los resultados de autenticación y cualquier forma de detectar manipulaciones. A la parte contraria le basta con hacer una pregunta, «¿cómo sabemos que no se editó?», y una captura sin más no tiene respuesta.

Cápsula de cita: Una captura de pantalla de la bandeja de entrada es un resultado renderizado sin metadatos subyacentes. No contiene cadena Received, ni Message-ID, ni hash de integridad, así que por sí sola no puede demostrar que se envió un correo, quién lo envió ni que el contenido no se ha alterado. Una prueba de nivel forense exige los encabezados en bruto y un hash criptográfico del archivo de origen.

Para ver el panorama completo sobre cómo conservar mensajes de forma defendible, consulta nuestra guía sobre archivo de correo y conversión de correo a PDF/A.

¿Qué demuestra realmente que se envió un correo?

La prueba está en los encabezados completos del correo, que la mayoría de las bandejas de entrada ocultan por defecto. En Gmail se muestran con «Mostrar original»; en Outlook, desde las propiedades del mensaje. Estos encabezados son el registro que escriben automáticamente tu servidor de correo y cada relé del camino. Tres campos hacen la mayor parte del trabajo, y cada uno responde a una pregunta distinta.

La cadena Received: ¿por dónde viajó el correo?

La cadena Received es una pila de líneas que añade cada servidor de correo (MTA) que gestionó el mensaje. Leída de abajo arriba, traza el recorrido del correo desde el servidor del remitente hasta el tuyo, con marcas de tiempo y direcciones IP en cada salto. Es lo más parecido que tiene el correo a un rastro de matasellos. Si la cadena es coherente en sí misma y coincide con la infraestructura del remitente declarado, respalda con fuerza que el correo viajó realmente por esa ruta.

Message-ID, Return-Path y Reply-To: ¿quién y qué?

El Message-ID es un identificador único a nivel global que se estampa al crear el mensaje; piensa en él como un número de serie. Que el Message-ID coincida entre la copia «Enviados» del remitente y la copia recibida del destinatario es una corroboración muy potente. Los campos Return-Path y Reply-To aportan contexto sobre la cuenta de envío real, que a veces difiere del nombre «De» de apariencia amable que podría suplantar un falsificador.

SPF, DKIM y DMARC: ¿se autenticó al remitente?

Estas tres comprobaciones indican si el correo procede realmente del dominio que dice. SPF verifica que el servidor de envío esté autorizado para ese dominio. DKIM es una firma criptográfica que vincula el mensaje con el dominio. DMARC une ambos con una política. El servidor receptor registra el resultado en el encabezado Authentication-Results como un veredicto: pass, fail, softfail, neutral, none, temperror o permerror. Un pass verde en los tres es una señal sólida de autenticidad.

Aquí hay una trampa que conviene conocer. La autenticación está lejos de ser universal. En la práctica, muchos dominios de envío siguen sin aplicar DMARC, y muchos publican una política «none» que pide a los receptores no hacer nada ante un fallo. Así que la ausencia de un pass, o un pass sin cumplimiento obligatorio, no es prueba de falsificación: a menudo solo significa que el dominio emisor no está bien configurado.

Como la aplicación de estas políticas es tan irregular, la conclusión práctica invierte el consejo convencional. Un resultado DKIM pass es una prueba positiva sólida, pero un resultado ausente o none es una prueba negativa débil. En la mayoría de las disputas, la cadena Received más el Message-ID hacen un trabajo más fiable que perseguir un veredicto DMARC que el dominio del remitente quizá nunca haya admitido.

Lo que contienen realmente los encabezados de un correo en bruto, antes de que ninguna herramienta los capture.

¿Cómo hace un hash SHA-256 que las pruebas de un correo revelen manipulaciones?

Un hash SHA-256 es una huella de longitud fija de un archivo. Si pasas el mismo archivo dos veces por el algoritmo, obtienes el mismo hash; si cambias un solo byte, el hash cambia por completo. Esa propiedad lo convierte en un ancla que revela manipulaciones. Si registras el hash SHA-256 del archivo .eml or .msg original en el momento de archivarlo, cualquiera puede volver a calcular después el hash y confirmar que el archivo no se ha alterado desde entonces.

Esto es lo que una captura de pantalla nunca podrá ofrecer. El hash no demuestra que el contenido del correo sea verdadero, pero sí demuestra que el archivo que presentas hoy es, byte a byte, el mismo que capturaste entonces. Junto con una marca de tiempo UTC y el tamaño del archivo en bytes, forma una cadena de integridad sencilla y verificable que también puede entender un revisor sin conocimientos técnicos.

Cápsula de cita: Un hash SHA-256 de un archivo .eml or .msg original es un mecanismo que revela manipulaciones. Como cualquier cambio en el archivo produce un hash distinto, registrar el hash en el momento de archivar permite que un tercero lo recalcule después y confirme que el archivo no se ha alterado. Esta ancla de integridad es justo lo que le falta a una captura de pantalla.

¿Cómo conviertes un correo en bruto en una prueba lista para el tribunal?

Para un solo correo no necesitas una empresa de análisis forense. El flujo es corto y se reduce a tres pasos:

1. Exporta el mensaje original como archivo .eml o .msg, no como captura de pantalla ni como copia reenviada.

2. Pásalo por una herramienta que extraiga los encabezados y calcule un hash, como PDFengine email-to-evidence.

3. Guarda el informe de una página que recoge los encabezados y el hash SHA-256.

En la práctica, lo que la gente hace mal es la exportación. Reenviarte un correo a ti mismo reescribe los encabezados y rompe la cadena. Usa siempre «Guardar como» o «Descargar mensaje original» para que el archivo .eml/.msg conserve intactas sus líneas Received originales y su Message-ID.

Qué contiene el informe de pruebas de PDFengine:

• Integridad: el hash SHA-256 del archivo original (en monoespaciado), el tamaño del archivo en bytes y una marca de tiempo UTC. El hash es una instantánea del archivo original; no se recalcula después del procesamiento.

• Identidad: From, To, Subject, Date, Message-ID, Return-Path y Reply-To.

• Autenticación: veredictos SPF, DKIM y DMARC extraídos del encabezado Authentication-Results, con código de colores: pass se muestra en verde y fail en rojo. Si no existe ese encabezado, los campos quedan vacíos; nunca se inventan.

• Transporte: la cadena Received completa.

• Además, el estado de firma S/MIME y el host informante (el servidor que estampó los resultados de autenticación).

Cabe destacar que el informe no renderiza el cuerpo del mensaje. Es deliberado. Omitir el cuerpo evita disputas sobre cómo se mostró el contenido y mantiene el foco en los metadatos forenses que prueban el recorrido y la integridad del correo.

Añadir una página de pruebas a la exportación de un correo lleva un solo clic.

Los límites, con total honestidad

Ninguna herramienta es mágica, y fingir lo contrario es como se acaba descartando una prueba. Hay dos advertencias que importan.

En primer lugar, en un archivo subido suelto .eml/.msg, los resultados SPF/DKIM/DMARC y los encabezados Received se toman del archivo proporcionado. PDFengine no los vuelve a verificar de forma independiente, porque quien aportó el archivo podría, en teoría, haber alterado esos encabezados antes de subirlo. Es una cuestión de cadena de custodia, no un defecto de la herramienta: el archivo es tan fiable como su origen.

En segundo lugar, incluso en los correos enviados directamente a un buzón de PDFengine (entrantes), donde los valores de autenticación los estampó el propio servidor receptor de PDFengine en la entrega, PDFengine no vuelve a verificar la firma criptográfica DKIM en sí. La nueva verificación criptográfica independiente de DKIM está prevista, pero todavía no está activa. Por eso no afirmes que el informe vuelve a comprobar DKIM criptográficamente. Informa del veredicto; no repite el cálculo.

PDFengine frente a Adobe Acrobat para pruebas de correo

Acrobat es excelente para convertir un correo en un PDF limpio y legible. No está pensado para producir pruebas de autenticidad. Según las funciones documentadas de Adobe Acrobat, el complemento de Outlook captura el cuerpo visible y los campos básicos De/Para/Asunto, pero no los encabezados técnicos completos, ni un hash del archivo, ni el análisis de SPF/DKIM/DMARC. Aquí tienes la comparación, con franqueza.

En resumen: usa Acrobat cuando quieras una copia compartible e imprimible del contenido de un correo. En cambio, usa una herramienta de pruebas específica cuando necesites demostrar el origen y la integridad del correo. Resuelven problemas distintos. Acrobat funciona por suscripción y está orientado al escritorio (consulta los precios actuales en Adobe), mientras que la extracción de pruebas por correo es mucho más barata para un uso ocasional.

La autenticación y la integridad son lo que separa una prueba de una captura de pantalla.

¿Necesitas capturar más de un mensaje? Nuestra herramienta de correo a PDF gestiona mensajes sueltos, mientras que PST a PDF convierte buzones enteros para archivarlos.

Preguntas frecuentes

¿Cómo demuestro que envié un correo?

Exporta el mensaje original como archivo .eml o .msg desde tu carpeta «Enviados» y captura sus encabezados, sobre todo el Message-ID y la cadena Received, en lugar de fiarte de una captura de pantalla. En la Comunidad de Gmail es una pregunta habitual, y la respuesta duradera es la misma: los encabezados, junto con un hash del archivo original, son lo que tiene peso.

¿Vale una captura de pantalla de un correo ante un tribunal?

Por sí sola, rara vez. Como preguntan en los foros jurídicos de Avvo, las capturas de cuentas no verificadas son fáciles de impugnar porque no contienen encabezados, ni cadena de transporte, ni forma de detectar ediciones. Pueden apoyar un caso como contexto, pero no son una prueba de autenticidad independiente. Acompaña cualquier captura con el archivo original y sus encabezados.

¿Cómo demuestro que un correo se entregó (y no solo que se envió)?

Demostrar la entrega es más difícil que demostrar el envío. La cadena Received del destinatario muestra que el mensaje llegó a su servidor de correo, y que no rebotara es un indicio. Pero los verdaderos acuses de lectura son poco fiables y se desactivan con facilidad. Como refleja el hilo de la Comunidad de Gmail «anyway to prove my email was delivered?», la prueba más sólida disponible suele ser la de los encabezados del lado del destinatario que muestran la aceptación por su servidor.

¿Qué son los encabezados de un correo y dónde los encuentro?

Los encabezados son los metadatos ocultos que escribe cada servidor de correo mientras el mensaje viaja. En Gmail, abre el mensaje, haz clic en el menú de tres puntos y elige «Mostrar original». En Outlook, abre las propiedades del mensaje o «Ver origen». Ahí aparecen la cadena Received, el Message-ID, el Return-Path y los Authentication-Results, los campos que de verdad prueban el origen.

¿Se pueden falsificar los encabezados de un correo?

Los veredictos relacionados con la autenticación (sobre todo DKIM) son difíciles de falsificar de forma convincente. Pero los encabezados de un archivo .eml suelto que te han entregado pueden haber sido alterados por quien lo aportó, y por eso importa la cadena de custodia. Los encabezados entrantes estampados por un servidor receptor de confianza son más sólidos que los de un archivo de procedencia desconocida.

¿PDFengine vuelve a verificar DKIM criptográficamente?

Todavía no. PDFengine informa de los veredictos SPF/DKIM/DMARC presentes en el encabezado Authentication-Results y calcula un hash SHA-256 del archivo original. La nueva verificación independiente de la firma DKIM está prevista, pero hoy no está activa, así que el informe muestra el veredicto registrado en lugar de repetir la comprobación criptográfica.

Conclusión

Saber cómo demostrar que se envió un correo no depende de lo convincente que sea tu captura de pantalla. Depende del registro técnico que hay debajo: la cadena Received que traza el recorrido del correo, el Message-ID que lo identifica, los veredictos SPF/DKIM/DMARC que ponen a prueba al remitente y un hash SHA-256 que blinda el archivo frente a manipulaciones. Si reúnes todo eso, tienes pruebas que resisten el examen en lugar de venirse abajo ante la primera pregunta de «¿cómo sabemos que es real?»

Cuando lo que está en juego lo justifica, y dado que solo el fraude por compromiso del correo electrónico empresarial provocó pérdidas de 2770 millones de dólares en 2024 (fuente: FBI IC3 2024 Annual Report, 2025), archivar de forma proactiva es un seguro barato. Exporta el .eml o .msg original, pásalo por una herramienta de pruebas y guarda el informe de una página.

¿Quieres convertir un correo en bruto en un informe de autenticidad de una página con encabezados y un hash SHA-256? Prueba PDFengine email-to-evidence, sin Outlook ni software de escritorio. Para trabajos más grandes, nuestro conversor de PST a PDF archiva buzones enteros de una vez.

Sobre el autor — Daan van Tongeren es el fundador de PDFengine (pdfen.com), una plataforma online de conversión de PDF, preparación de PDF listos para imprimir y archivo de correo.