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. Caso real anonimizado: cuando dkim=pass mentía
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. Si el primer MTA mintió o se equivocó, el segundo replica el error.

Para un perito informático, Authentication-Results es testimonio, no evidencia. Es lo que dice el receptor, no lo que demuestra la criptografía.

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 valida la firma matemáticamente contra esa clave pública.

Si la verificación devuelve PASS, es matemáticamente cierto que el contenido firmado (cabeceras seleccionadas + cuerpo + adjuntos) procede del dominio firmante y no ha sido alterado. Esa cadena no depende de lo que diga el servidor receptor.

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. Establecida por el primer MTA durante el MAIL FROM SMTP.
• 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 toda la información técnica: cabeceras, firma DKIM, body hash, todo. 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 desde la bandeja al escritorio → genera .msg (formato propietario; convertir a .eml con herramienta tipo msgconvert).
• Apple Mail: seleccionar email → menú “Archivo” → “Guardar como…” → formato “Sin formato”.
• 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 prueba criptográfica de integridad y origen. 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

El receptor compara la IP del primer hop SMTP (que aparece en Received:) contra esa política y declara spf=pass o spf=fail. Pero SPF no firma el contenido: solo valida 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 7489) — alineación y política agregada

DMARC (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) — 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 del email, incluyendo todos los adjuntos codificados en base64. Si alguien modifica un solo byte de un adjunto post-firma:

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 llegaron al receptor exactamente como salieron del dominio firmante. Si los adjuntos están manipulados, DKIM lo detecta sin necesidad de comparar con el original.

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 primer Received: del .eml
grep -E "^Date:|^Received:" email.eml | head -5

# 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 timestamp del email tiene fuerza probatoria robusta. 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: “Los tres timestamps independientes (Date cliente, primer hop SMTP, EXIF de adjuntos) son coherentes entre sí dentro de una ventana de ±5 minutos, lo que respalda la cronología declarada”.

6. Caso real anonimizado: cuando dkim=pass mentía

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

El email NO era auténtico criptográficamente. El dkim=pass declarado por el servidor del cliente era incorrecto — posible bug de configuración, posible manipulación intermedia, posible procesamiento erróneo. La verificación independiente contra DNS público demostró que la firma DKIM no validaba.

Lo que el caso enseña

• Authentication-Results no es defensa: aunque el receptor diga pass, hay que verificar.
• dkimpy es independiente: no confía en el servidor receptor, lee la clave pública del DNS y valida la firma matemáticamente.
• 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 valida 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 determinar su autenticidad, integridad y origen real. 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 probar (o refutar) que el email no ha sido alterado y que procede del dominio que dice.

¿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í, son admisibles como prueba documental electrónica en juicios civiles, laborales, mercantiles y penales en España. La fuerza probatoria depende de la cadena de custodia y de la verificación criptográfica: un email con DKIM PASS verificado contra DNS público y peritado conforme a UNE 197001 tiene fuerza probatoria robusta. 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.

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, Version 1. https://datatracker.ietf.org/doc/html/rfc7208
• RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://datatracker.ietf.org/doc/html/rfc7489
• 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 y dictámenes periciales. https://www.une.org/encuentra-tu-norma/busca-tu-norma/norma?c=N0062451
• 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