Análisis forense de correos electrónicos: guía completa 2026

Si tienes que peritar un email y demostrar (o destruir) su autenticidad ante un juzgado español, hay 4 cosas que sí se pueden probar criptográficamente y 2 que NO. Esta guía explica cómo verificar headers RFC 5322, validar DKIM contra DNS público, analizar adjuntos y correlacionar timestamps — con un caso real anonimizado donde el Authentication-Results decía PASS y la verificación independiente dijo FAIL.

Tabla de contenidos

1. Por qué Authentication-Results no es prueba criptográfica
2. Anatomía de un email forense (RFC 5322)
3. Verificación criptográfica: DKIM, SPF, DMARC y ARC
4. Análisis forense de adjuntos
5. Correlación temporal: Date, Received, EXIF
6. Escenario ilustrativo: cuando dkim=pass no basta
7. Preguntas frecuentes

1. Por qué Authentication-Results no es prueba criptográfica

Cuando abres el código fuente de un email recibido y ves una línea como Authentication-Results: mx.google.com; dkim=pass header.i=@empresa.com, es tentador concluir que el email es auténtico. No lo es. Esa línea no es prueba criptográfica de nada.

Authentication-Results es una cabecera definida por el RFC 8601. Quien la escribe es el servidor receptor (Gmail, Microsoft 365, Yahoo, el servidor corporativo del destinatario…) y refleja lo que ese servidor concluyó al procesar el mensaje. Es una declaración del receptor, no una verificación independiente.

El problema forense

El servidor receptor puede equivocarse, estar mal configurado o, en escenarios adversariales, ser manipulado:

• Un MTA con software desactualizado puede declarar dkim=pass aplicando reglas obsoletas que ignoran la canonicalización correcta.
• Un servidor corporativo puede haber sido configurado para “confiar” en ciertos remitentes y marcar dkim=pass sin verificar.
• En un escenario de cliente comprometido, el atacante con acceso al servidor puede reescribir cabeceras Authentication-Results antes de que el email llegue al buzón del usuario.
• En un email forwardeado a otro buzón, la cabecera Authentication-Results original no se preserva por defecto: el segundo MTA escribe la suya tras ejecutar sus propias comprobaciones (un MTA conforme no debe añadir un resultado a un campo existente). Puede conservar, eliminar o ignorar los campos anteriores según su frontera de confianza, pero no «replica» el resultado del anterior.

Para un perito, Authentication-Results registra lo que un MTA afirma haber comprobado. No debe aceptarse por su mera presencia —hay que identificar qué dominio lo insertó y su frontera de confianza—, pero dentro de una frontera establecida puede ser fiable. No es criptografía que el perito reproduzca, pero tampoco «no evidencia».

La alternativa criptográfica: DKIM verificada contra DNS público

DKIM (RFC 6376, sección 3.5) inserta en el email una firma criptográfica generada con la clave privada del dominio firmante. Para verificarla:

1. Se lee la cabecera DKIM-Signature del .eml original.
2. Se extrae el selector y el dominio firmante.
3. Se consulta el registro TXT <selector>._domainkey.<dominio> en DNS público desde la red del perito (no a través del servidor receptor).
4. Se válida la firma matemáticamente contra esa clave pública.

Si la verificación devuelve PASS, acredita que las partes cubiertas por la firma —las cabeceras de h= y la porción del cuerpo indicada por l=, con su canonicalización— no se han alterado desde que ese dominio las firmó, y esa comprobación no depende del servidor receptor. No cubre necesariamente todo el mensaje ni todos los adjuntos, ni identifica a la persona que envió el correo.

Ejemplo práctico de verificación independiente

# El perito hace su propia verificación, no confía en el receptor:
python3 -c "import dkim; print(dkim.verify(open('email.eml','rb').read()))"

Salida posible:

• True → la firma DKIM es válida según verificación criptográfica independiente. El Authentication-Results que dijera dkim=pass queda corroborado.
• False → la firma DKIM NO es válida. Aunque el servidor receptor haya escrito dkim=pass, la criptografía dice otra cosa. Hay un problema (configuración, manipulación, software defectuoso o email no auténtico).

Implicación pericial

En un dictamen pericial conforme a UNE 197001:2019, nunca se debe afirmar la autenticidad de un email basándose solo en Authentication-Results. La metodología defendible ante un juzgado español incluye:

1. Citar la cabecera Authentication-Results declarada por el receptor (es información, no prueba).
2. Verificar criptográficamente DKIM contra DNS público con dkimpy u otra implementación conforme a RFC 6376.
3. Documentar el resultado de la verificación independiente en el cuerpo del informe, con la versión de la herramienta y el comando exacto utilizado (reproducibilidad byte a byte).
4. Si los dos resultados divergen (Authentication-Results dice PASS pero la verificación dice FAIL), explicar la divergencia y qué prevalece criptográficamente.

Confundir lo declarado con lo verificable es uno de los errores forenses más fáciles de impugnar en un contraperitaje.

2. Anatomía de un email forense (RFC 5322)

Antes de verificar nada, hay que saber qué se está mirando. Un email es texto plano estructurado en cabeceras + cuerpo, definido por el RFC 5322. Todas las cabeceras importan, pero no todas tienen el mismo valor probatorio. Para el glosario completo de cabeceras, ver cabeceras de email forenses.

Cabeceras visibles al usuario

Lo que el cliente de correo (Outlook, Gmail, Thunderbird) muestra al destinatario:

• From: — quién dice ser el remitente. Manipulable trivialmente por cualquier MTA. Por sí sola NO es prueba de origen.
• To: / Cc: / Bcc: — destinatarios visibles. Bcc: no aparece en la copia recibida.
• Subject: — asunto. Puede ser modificado en reenvíos (los Fw: y Re: típicos).
• Date: — fecha y hora declaradas por el cliente del remitente. El reloj del cliente (definido por el RFC 5322 §3.6.1). Trivialmente manipulable.
• Message-ID: — identificador único generado por el primer MTA. Útil para correlacionar con archivos de servidor pero NO prueba autenticidad.

Cabeceras técnicas (las que importan forensemente)

Las que el usuario nunca ve sin abrir “Mostrar original” o “View Source”:

• Received: — la cadena de servidores SMTP que tocaron el email. Se lee de abajo hacia arriba: la línea más baja es el primer servidor (más cercano al remitente real); la más alta es el servidor receptor final. Cada Received: añade timestamp, IP de origen y nombre del MTA.
• Return-Path: — la dirección a la que se devolverían los rebotes. La inserta normalmente el servidor de entrega final a partir del reverse-path del sobre (MAIL FROM); sistemas posteriores pueden retirarla.
• DKIM-Signature: — firma criptográfica RFC 6376. La cabecera más importante forensemente.
• Authentication-Results: — declaración del servidor receptor sobre SPF/DKIM/DMARC. Testimonio, no prueba (ver bloque anterior).
• ARC-Seal: / ARC-Message-Signature: / ARC-Authentication-Results: — cadena de autenticación preservada en reenvíos (RFC 8617).

Tabla resumen: confianza forense por cabecera

Cómo extraer el .eml original (sin perder cabeceras)

Esto es el primer paso del trabajo pericial. Si el cliente solo aporta una captura de pantalla o un PDF “imprimido” del email, se pierde la mayor parte de la información técnica verificable: cabeceras, firma DKIM, body hash. La verificación criptográfica deja de ser posible.

Por proveedor:

• Gmail web: abrir el email → menú ⋮ (3 puntos) → “Mostrar original” → “Descargar mensaje original”. Genera un .eml.
• Outlook web (Microsoft 365): abrir el email → ⋮ → “Ver” → “Ver origen del mensaje”. Copiar todo y guardar como .eml.
• Outlook desktop: arrastrar el email al escritorio genera un .msg (formato propietario). Conservar primero el .msg original y su hash; una conversión a .eml (p. ej. con msgconvert) es evidencia derivada y debe documentarse, no sustituir al original.
• Apple Mail: seleccionar el email → menú “Archivo” → “Guardar como…” → “Origen del mensaje sin formato” (Raw Message Source), que genera un .eml. No elegir “Sin formato”/“Plain Text”, que descarta las cabeceras.
• Thunderbird: clic derecho sobre el email → “Guardar como” → .eml.

Una vez obtenido el .eml, lo primero que hace un perito es:

shasum -a 256 email.eml > email.eml.sha256

Esto fija la evidencia origen (ISO/IEC 27037). Cualquier modificación posterior, incluso de un solo carácter, cambia el hash y rompe la cadena de custodia.

Con el .eml y su hash registrados, ya se puede empezar a leer y verificar.

3. Verificación criptográfica: DKIM, SPF, DMARC y ARC

Cuatro protocolos definen la autenticidad técnica de un email. No son equivalentes y no aportan el mismo valor probatorio. Un perito tiene que entender qué prueba cada uno y, sobre todo, qué NO prueba. Para definiciones rápidas consulta el glosario SPF/DKIM/DMARC.

3.1 DKIM (RFC 6376) — la firma criptográfica

DKIM (DomainKeys Identified Mail, RFC 6376) es el único de los cuatro que aporta una comprobación criptográfica: vincula el dominio d= con las partes que firma (h=, l=), no con todo el mensaje ni con el autor aparente. El servidor del dominio firmante (por ejemplo, los servidores de salida de Yahoo, Google o el dominio corporativo) firma el email con una clave privada. La clave pública se publica en DNS bajo <selector>._domainkey.<dominio>.

Cabecera DKIM-Signature típica:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=empresa.com;
    s=s2048; h=From:To:Subject:Date:Message-ID; bh=47DEQpj8HBSa+...;
    b=jXh3kVf2pQ8mLXxx...

Componentes clave:

• d= dominio firmante (no necesariamente igual al From: visible).
• s= selector — apunta al registro DNS donde está la clave pública.
• h= lista de cabeceras protegidas por la firma.
• bh= body hash — hash del cuerpo del email (incluye adjuntos). Si el cuerpo se modifica post-firma, el bh recalculado no coincide y la firma falla.
• b= firma RSA o Ed25519 sobre las cabeceras seleccionadas + body hash.

3.2 SPF (RFC 7208) — política, no firma

SPF (Sender Policy Framework, RFC 7208) es una política, no una firma. El dominio publica en DNS qué IPs están autorizadas a enviar correo en su nombre:

dig +short empresa.com TXT | grep "v=spf1"
# v=spf1 ip4:185.16.5.20 include:_spf.google.com ~all

Durante la sesión SMTP, el receptor evalúa la IP del cliente que se conecta y la identidad MAIL FROM (o HELO) contra esa política, y declara spf=pass o spf=fail. Una reevaluación forense posterior necesita esos datos del sobre y la política DNS vigente en aquel momento: no basta con tomar una IP de una cabecera Received: y consultar el DNS de hoy. Pero SPF no firma el contenido: solo válida que la IP de origen está autorizada. Un atacante con acceso a una IP autorizada (cuenta corporativa comprometida, hosting compartido) pasa SPF sin haber suplantado nada criptográficamente.

Para un perito, SPF es circunstancial: si dice pass, es coherente; si dice fail, es señal de problema. Pero no aporta integridad del cuerpo del mensaje. El ~all (soft-fail) y -all (hard-fail) al final indican qué hacer con IPs no autorizadas.

3.3 DMARC (RFC 9989) — alineación y política agregada

DMARC (RFC 9989, que sustituye al RFC 7489) construye sobre SPF y DKIM. Define:

1. Alineación: el dominio del From: visible debe alinearse con el dominio firmante DKIM (d=) o con el dominio del Return-Path: SPF.
2. Política: qué hacer con emails que fallen alineación (none, quarantine, reject).
3. Reportes: el dominio puede pedir informes RUA (agregados) y RUF (forenses) al receptor.

dig +short _dmarc.empresa.com TXT
# v=DMARC1; p=reject; rua=mailto:dmarc@empresa.com; ruf=mailto:forensic@empresa.com; adkim=s; aspf=s

Para el perito, DMARC importa porque un email con DKIM PASS pero alineación rota (el d= del DKIM no coincide con el dominio del From:) puede indicar suplantación legítima vía proveedor SaaS o intento de spoofing. Hay que documentar la divergencia.

3.4 ARC (RFC 8617, Experimental) — cadena en reenvíos

ARC (Authenticated Received Chain, RFC 8617) resuelve el problema de los reenvíos: cuando un MTA intermedio (mailing list, regla de forwarding) modifica cabeceras From:/Subject:, la firma DKIM original se rompe pero ARC preserva el resultado de verificación que el primer MTA obtuvo.

Cabeceras ARC típicas en un email forwardeado:

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=mta-intermedio.com; s=arc;
    t=1709568000; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mta-intermedio.com;
    s=arc; t=1709568000; h=from:to:subject:date:message-id;
    bh=47DEQpj8HBSa+...; b=...
ARC-Authentication-Results: i=1; mta-intermedio.com;
    dkim=pass header.i=@empresa-original.com;
    spf=pass smtp.mailfrom=empresa-original.com;
    dmarc=pass action=none header.from=empresa-original.com

El perito lee la cadena ARC: si el primer eslabón (i=1) muestra dkim=pass con el dominio original, el reenvío preservó la autenticación aunque la firma DKIM original se haya roto en el camino. Si la cadena ARC también está rota o ausente, el reenvío no es trazable y la prueba de origen se debilita.

Tabla resumen forense

En un dictamen pericial, DKIM verificada contra DNS público es el pilar. SPF, DMARC y ARC complementan el análisis y permiten entender el contexto de reenvíos, pero no sustituyen la firma criptográfica.

4. Análisis forense de adjuntos

Los adjuntos del email son evidencia tan importante como el cuerpo. La buena noticia: DKIM los protege automáticamente. La mala: la mayoría de los hallazgos forenses interesantes están en los metadatos de los adjuntos, no en el adjunto en sí.

Cómo DKIM protege los adjuntos

La firma DKIM incluye un body hash (bh=) calculado sobre el cuerpo MIME según el alcance de l=: si l= limita la parte firmada, el resto del cuerpo (y de los adjuntos) queda fuera. Cuando el adjunto está dentro de la parte cubierta, modificar un solo byte tras la firma hace que:

1. El cuerpo MIME cambia.
2. El body hash recalculado por el verificador no coincide con el bh= declarado.
3. La verificación DKIM devuelve FAIL.

Esto significa que un email con DKIM PASS verificado contra DNS público garantiza criptográficamente que los adjuntos cubiertos por la firma llegaron al receptor exactamente como salieron del dominio firmante. Si un adjunto cubierto se manipula, DKIM lo detecta sin necesidad de comparar con el original; un adjunto que quede fuera del alcance de l= no está protegido.

Análisis de imágenes adjuntas con exiftool

Las imágenes adjuntas a un email pueden revelar mucho más que su contenido visual. exiftool (v13.50+ en este proyecto) es la herramienta estándar:

# Extraer todos los metadatos relevantes
exiftool -G1 -s adjunto.jpg | grep -E "EncodingProcess|YCbCr|ICC|JFIF|Make|Model|GPS|CreateDate|ModifyDate|Software"

# Marcadores JPEG (Baseline DCT, ICC, SOF, DQT) — útil para identificar pipeline encoder
djpeg -verbose -outfile /dev/null adjunto.jpg 2>&1 | grep -E "Start Of|Define|JFIF"

Hallazgos típicos en peritajes reales:

• Discrepancia geo-temporal: el email dice venir de un dominio español a las 10:00 CET, pero el EXIF de la imagen adjunta tiene GPS: -33.4489, -70.6693 (Santiago de Chile) y OffsetTime: -04:00. Algo no cuadra: o la imagen se creó en otro continente o se manipuló post-captura.
• Software de origen distinto al declarado: el email dice “te mando la captura de pantalla”, pero el EXIF revela Software: Adobe Photoshop 25.0 en una imagen supuestamente “tomada con el móvil”. Hay edición intermedia.
• Pipeline de encoder JPEG inconsistente: las dos imágenes adjuntas que el cliente dice haber sacado con el mismo móvil tienen tablas DQT distintas y EncodingProcess: Baseline DCT vs Progressive DCT. Probablemente proceden de fuentes distintas.
• Thumbnails embebidos que no coinciden con la imagen principal: indicador clásico de edición — el thumbnail (IFD1) se mantiene del archivo original mientras la imagen visible se ha editado.

Análisis de PDFs adjuntos

Los PDFs adjuntos requieren tres comprobaciones:

1. Metadatos básicos (autor, software, fechas):

   exiftool -G1 documento.pdf | grep -E "Producer|Creator|Author|CreateDate|ModifyDate"

2. Firma digital embebida (PAdES, eIDAS):

   pdfsig documento.pdf
   # Salida típica:
   #   Signature #1:
   #     Signer Certificate Common Name: Apellido Nombre - 12345678A
   #     Signing Time: 2024-03-15T10:23:45+01:00
   #     Signature Validation: Signature is Valid.

   Una firma digital válida en un PDF anexo a un email autenticado por DKIM aporta doble cadena de prueba: criptográfica del PDF + criptográfica del transporte.

3. Hash de integridad para cadena de custodia:

   shasum -a 256 documento.pdf > documento.pdf.sha256

Cadena de custodia de adjuntos extraídos

Cada adjunto extraído del .eml para análisis se trata como evidencia derivada y entra en cadena de custodia:

1. Extraer adjunto del .eml (usar munpack, parser Python con email.parser, o herramienta del cliente).
2. Calcular SHA-256 inmediatamente y registrarlo.
3. Documentar el procedimiento en el informe (versión de la herramienta, comando exacto, hash resultante).
4. Cualquier análisis posterior se hace sobre la copia, nunca sobre el .eml origen.

5. Correlación temporal: Date, Received, EXIF

El tiempo es la dimensión más fácil de manipular en un email — y por eso una de las más reveladoras cuando hay incoherencias. Un perito tiene que cruzar al menos tres fuentes temporales independientes antes de aceptar un timestamp como evidencia.

Las tres fuentes temporales de un email

Ninguna de las tres es prueba absoluta por sí sola. La técnica forense consiste en cruzarlas y buscar incoherencias.

Patrones de incoherencia detectables

Cuatro patrones concretos que un perito busca rutinariamente:

1. Date: posterior al primer Received: — físicamente imposible. El email no puede haber llegado al servidor SMTP antes de haberse “creado” según la cabecera Date. Indica reloj del cliente desincronizado o manipulación deliberada de la cabecera Date.

2. Date: con timezone que no corresponde al ISP del IP del primer hop — si el Date: declara +09:00 (Japón) pero el IP del primer Received: (consultado vía WHOIS) está en un proveedor europeo, hay incoherencia. Posible explicación legítima: viajero con portátil; posible explicación maliciosa: timestamp falsificado.

3. EXIF de foto adjunta anterior a la creación supuesta del email — el cliente dice “te mando la foto que acabo de hacer”, el Date: del email marca 2024-03-15 10:00, pero el EXIF DateTimeOriginal de la foto marca 2023-11-22 17:35. La foto preexiste al email, no es “lo que acaba de hacer”.

4. Received: con saltos temporales imposibles entre hops — la cadena Received: debe mostrar timestamps monotónicamente crecientes (cada servidor sucesivo debe tener timestamp posterior o igual al anterior). Saltos hacia atrás indican relojes desincronizados de servidores intermedios o cabeceras inyectadas.

Cómo cruzar las tres fuentes

# 1. Date: y cadena Received: del .eml. Cada MTA ANTEPONE su linea, asi
#    que el 'primer salto' esta entre los ULTIMOS; head tomaria los de
#    arriba (receptor final) y perderia continuaciones plegadas.
grep -E "^Date:|^Received:" email.eml

# 2. EXIF de cada adjunto
for f in adjuntos/*.jpg adjuntos/*.pdf; do
  echo "=== $f ==="
  exiftool -G1 -DateTimeOriginal -ModifyDate -CreateDate "$f"
done

# 3. WHOIS del IP del primer hop (de Received:)
whois 185.16.5.20 | grep -iE "country|org-name|netname"

Construir una timeline forense en el informe pericial cruzando las tres fuentes en orden cronológico declarado. Marcar en rojo las incoherencias y explicarlas.

El valor de la convergencia

Cuando las tres fuentes convergen (Date coherente con Received, EXIF coherente con Date), el indicio temporal es más sólido —aunque Date y EXIF pueden proceder del mismo actor y su valor depende de la incertidumbre de reloj, zona horaria y método de adquisición—. Si una de las tres diverge, hay que explicarla; si dos divergen, la cronología no es fiable y hay que declararlo como limitación en el dictamen.

Una metodología defensiva ante un contraperitaje siempre incluye este cruce explícito: “Las fuentes temporales disponibles (Date del cliente, primer hop SMTP y EXIF de adjuntos) son coherentes entre sí dentro de un margen razonable, lo que respalda la cronología declarada” — advirtiendo que Date y EXIF pueden proceder del mismo actor y son editables, por lo que no son necesariamente independientes ni admiten una tolerancia universal fija.

6. Escenario ilustrativo: cuando dkim=pass no basta

Hipótesis inicial

Si la cabecera Authentication-Results decía dkim=pass, el email “debería” ser auténtico según el servidor receptor. Pero, como vimos en el bloque 1, esa cabecera la escribe el servidor receptor — no es prueba criptográfica.

Procedimiento aplicado

Conclusión forense

En este escenario, la verificación independiente contra el DNS devolvió False. Ahora bien, un False obtenido HOY no distingue por sí solo una falsificación de una rotación o revocación de la clave, de la ausencia del registro histórico o de un error de entrada: la consulta actual recupera la clave actual, no necesariamente la que existía cuando se recibió el mensaje. Para concluir sobre la autenticidad histórica hay que localizar la clave del selector vigente en la fecha relevante y dejar constancia de si no existe.

Lo que el caso enseña

• Authentication-Results no es defensa: aunque el receptor diga pass, hay que verificar.
• dkimpy verifica de forma independiente: no confía en el servidor receptor; lee la clave pública del DNS y comprueba la firma sobre las partes que esta cubre (h=, l= y la canonicalización empleada), no «todo el email».
• Cadena de custodia desde el .eml: si el cliente reenvía el email como PDF o captura, perdemos la posibilidad de verificar.

Lo que NO se acreditó

• Quién manipuló o configuró erróneamente el Authentication-Results (servidor receptor, intermediario, atacante).
• La identidad jurídica de quien envió realmente el email (DKIM solo prueba que algo está firmado por X dominio, no quién opera ese dominio).
• El contenido sustantivo del mensaje (eso lo evalúa el juez, no el perito).

Si el caso involucra fraude tipo BEC (Business Email Compromise) — emails de “CEO” pidiendo transferencias urgentes o cambios de cuenta bancaria de proveedor — el servicio de certificación de mensajería cubre el peritaje completo del incidente.

Otros posts del cluster email forensics:

• Si eres abogado y necesitas validar un peritaje de email (propio o contrario) o construir argumentos de impugnación: cómo un abogado válida el trabajo de un perito en emails — checklist 8 preguntas + cuándo impugnar.
• Si acabas de recibir un email BEC (CEO o proveedor pidiendo transferencia) y necesitas saber qué hacer en los primeros 5 minutos: email sospechoso del jefe pidiendo transferencia: qué hacer — preservar evidencia, primeras 24 h, denuncia GDT.

7. Preguntas frecuentes

¿Qué es el análisis forense de correos electrónicos?

Es el examen técnico-criptográfico de un email para evaluar indicios técnicos de su integridad y de qué dominio reclama la firma. Combina parseo de cabeceras RFC 5322, verificación de firma DKIM contra DNS público, análisis de adjuntos con exiftool y correlación temporal entre Date:, Received: y EXIF. El objetivo es aportar indicios de si las partes firmadas del email se han alterado y de qué dominio reclama su firma; no identifica a la persona que lo envió ni acredita por sí solo el dominio visible en From.

¿Cómo se utilizan los correos electrónicos en el análisis forense?

Como evidencia documental electrónica (art. 326-329 LEC en España). El perito extrae el .eml original (no PDFs ni capturas), lo hashea SHA-256 para cadena de custodia ISO/IEC 27037, verifica criptográficamente la firma DKIM contra DNS público con dkimpy, analiza adjuntos y emite dictamen UNE 197001:2019. El email validado se incorpora al procedimiento como anexo del informe pericial.

¿Los correos electrónicos son pruebas en un juicio?

Sí, pueden aportarse como prueba en el proceso civil (art. 326 LEC) y, con sus propias reglas, en otros órdenes. Un email con DKIM verificado y peritado con método documentado refuerza el análisis técnico, pero la admisión, autenticidad y valoración dependen del caso, de una eventual impugnación y del conjunto probatorio (arts. 326 y 384 LEC; la prueba pericial, arts. 335 y ss.): DKIM no crea por sí solo una fuerza probatoria predeterminada. Un email aportado solo como captura de pantalla, sin .eml ni hash, es fácilmente impugnable.

¿Cuáles son 3 señales de phishing?

(1) Dominio sutilmente distinto del legítimo (empresa-soporte.com en vez de empresa.com). (2) Urgencia artificial (“transfiere antes de las 17h o se cierra el contrato”). (3) Ausencia de DKIM verificable o Authentication-Results: dkim=fail declarado por el servidor receptor. Otras señales: enlaces que no coinciden con el texto visible, faltas ortográficas en castellano profesional, peticiones fuera del protocolo habitual.

¿Por qué no confiar en Authentication-Results?

Porque la escribe el servidor receptor a su criterio. Es una declaración del receptor, no una verificación criptográfica. La prueba real es DKIM verificada contra el DNS público del dominio firmante con una herramienta independiente (dkimpy, por ejemplo).

¿DKIM PASS en un email reenviado (Fw_)?

Sí, si quien reenvió no modificó las cabeceras firmadas ni el cuerpo. La firma DKIM del primer hop sigue siendo válida. Si el reenvío sí modificó cabeceras (típico en mailing lists), la firma original falla pero ARC (RFC 8617) preserva el resultado de verificación del primer servidor.

¿Qué es el bh= (body hash) y por qué importa?

Es el hash del cuerpo del email incluido dentro de la firma DKIM. Si alguien modifica el cuerpo o un adjunto después de la firma, el hash recalculado no coincide con bh= y la verificación falla. Es lo que hace que los adjuntos estén protegidos por DKIM.

¿Cuánto cuesta un peritaje forense de correos electrónicos?

Depende del volumen de emails (uno solo vs cientos), de la complejidad (DKIM directo vs cadenas ARC con múltiples reenvíos), de si hay adjuntos a analizar (imágenes, PDFs firmados) y del plazo. En digitalperito.es se hace presupuesto a medida tras valoración inicial gratuita del caso. Solicita una valoración aquí describiendo qué emails tienes y qué quieres acreditar. Sobre el autor: Jonathan Izquierdo es perito informático forense especializado en análisis forense de correo electrónico, con metodología ISO/IEC 27037 y dictámenes UNE 197001:2019.

Referencias y fuentes

• RFC 5322 — Internet Message Format. https://datatracker.ietf.org/doc/html/rfc5322
• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures. https://datatracker.ietf.org/doc/html/rfc6376
• RFC 7208 — Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Versión 1. https://datatracker.ietf.org/doc/html/rfc7208
• RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC), que sustituye al RFC 7489. https://www.rfc-editor.org/rfc/rfc9989.html
• RFC 8601 — Message Header Field for Indicating Message Authentication Status. https://datatracker.ietf.org/doc/html/rfc8601
• RFC 8617 — The Authenticated Received Chain (ARC) Protocol. https://datatracker.ietf.org/doc/html/rfc8617
• ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence. https://www.iso.org/standard/44381.html
• UNE 197001:2019 — Criterios generales para la elaboración de informes periciales. https://www.une.org/encuentra-tu-norma/busca-tu-norma/norma?c=N0062378
• Ley 1/2000 de Enjuiciamiento Civil — arts. 326-329 (prueba documental electrónica) y 335-352 (prueba pericial). https://www.boe.es/eli/es/l/2000/01/07/1/con
• dkimpy — Python library implementing RFC 6376. https://launchpad.net/dkimpy
• AEPD — Agencia Española de Protección de Datos. https://www.aepd.es/
• INCIBE-CERT — Buenas prácticas en autenticación de correo. https://www.incibe.es/incibe-cert