De DKIM-Signature a Received: cómo leer cabeceras de email como un forense

Un informe DMARC RUA muestra una anomalía. Identificas una IP externa enviando volumen bajo tu dominio, pero desconoces la carga útil exacta. El departamento de IT de tu cliente afirma que su infraestructura está intacta, pero los correos transaccionales siguen siendo catalogados como suplantaciones. La única forma de probar un fallo técnico o una intrusión es abandonar el cliente visual y solicitar el archivo .eml original.

Los gestores de correo como Outlook o Gmail mienten por diseño; ocultan la cadena de transporte real para presentar una interfaz simplificada. La seguridad de tu red exige acceder al registro inmutable del mensaje. En este documento aprenderás a diseccionar los metadatos de las cabeceras de correo, a trazar la ruta de enrutamiento mediante los saltos de servidor y a verificar la integridad criptográfica de un envío para emitir un diagnóstico concluyente.

Qué es exactamente una cabecera de email y dónde se extrae

Las cabeceras de correo electrónico son bloques de metadatos estandarizados bajo la RFC 5322. Cada vez que un mensaje transita por un Mail Transfer Agent (MTA), dicho servidor inyecta líneas de texto en la parte superior del código fuente del mensaje antes de enrutarlo al siguiente destino. Este proceso conforma un historial de auditoría adjunto al propio correo.

Para acceder a estos datos, la acción requerida varía según el proveedor. En Gmail de escritorio, exige seleccionar "Mostrar original" en el menú desplegable del mensaje. En Microsoft 365, requiere acceder a "Ver origen del mensaje". El resultado es un volcado de texto plano donde la información crítica precede al cuerpo del mensaje HTML.

Si intentas diagnosticar un fallo de entrega analizando únicamente el campo "De:" y el "Para:" visibles en la pantalla de usuario, operas a ciegas. Cualquier actor puede falsificar el Header From en milisegundos. La autenticación real y la procedencia técnica residen exclusivamente en los metadatos ocultos.

La cronología inversa: el bloque Received

El componente fundamental para establecer la cadena de custodia de un mensaje es el bloque de cabeceras Received:. Cada servidor que procesa el correo añade su propio sello Received: en la parte superior del documento. Esto significa que la cronología se lee en orden inverso: de abajo hacia arriba.

El origen: el salto inferior

El registro Received: más cercano al cuerpo del mensaje (el último si lees de arriba a abajo) indica la máquina exacta, la dirección IP local o pública, y el cliente (MUA) que generó el envío original. Si este salto muestra una IP residencial dinámica cuando esperas un servidor de envío corporativo, has localizado el origen de una suplantación.

Los MTAs de tránsito: el enrutamiento intermedio

Los saltos centrales documentan el viaje del mensaje a través de pasarelas de seguridad, balanceadores de carga y servidores de filtrado (como Proofpoint o Mimecast). Analizar estas líneas permite detectar latencias en la transferencia; cada sello incluye una marca de tiempo estandarizada.

El receptor final: el salto superior

La cabecera Received: ubicada en la parte más alta del documento es insertada por el servidor del destinatario (por ejemplo, los servidores MX de Google). Esta línea dicta el momento exacto en el que el correo ingresó a la infraestructura de destino, sellando la auditoría de transporte.

Si necesitas acelerar el análisis de una ruta compleja, la herramienta de lectura de cabeceras de Smartxpression procesa el texto plano y mapea los saltos geográficamente sin transferir el contenido del mensaje a servidores externos.

Anatomía de la autenticación: DKIM y Authentication-Results

El tránsito documentado carece de validez si la carga útil ha sido alterada. Dos cabeceras específicas determinan el estado de las firmas criptográficas y las políticas de evaluación.

DKIM-Signature: el sello criptográfico

Esta cabecera contiene la firma digital del mensaje. Requiere el análisis de etiquetas precisas: d= indica el dominio que asume la responsabilidad de la firma, s= detalla el selector DNS donde reside la clave pública, bh= es el hash del cuerpo del correo, y b= es el hash criptográfico de las cabeceras seleccionadas.

Authentication-Results: el veredicto del receptor

Insertada por el servidor de destino final, esta cabecera compila los resultados de las evaluaciones SPF, DKIM y DMARC. Muestra el diagnóstico técnico directo (ej. spf=pass, dkim=fail, dmarc=pass). Cruza esta información con los dominios evaluados para verificar la alineación estricta.

Return-Path: el buzón de rebote

Define la dirección técnica hacia la cual el servidor receptor enviará los mensajes de error (bounces). Es el dominio que SPF utiliza para su validación de origen, independientemente de lo que el usuario final visualice en su pantalla.

La clave: la alteración en tránsito

Cuando un correo transita por una lista de distribución o un servicio de reenvío automático (forwarder), el servidor intermedio frecuentemente modifica el asunto ("Subject: [Lista]...") o inyecta texto en el cuerpo. Estas adiciones alteran el documento original. Consecuentemente, los valores bh= y b= de la cabecera DKIM-Signature dejan de coincidir con el correo recibido, provocando un fallo DKIM ineludible en el destino.

Cuatro categorías para clasificar el riesgo forense

Al inspeccionar un archivo .eml, el cruce de datos entre las distintas cabeceras define el diagnóstico. Debes clasificar cualquier correo analizado en uno de estos cuatro vectores operativos.

Falsificación de origen

Se diagnostica cuando el Return-Path (el remitente técnico) pertenece a un dominio no relacionado o a un servicio de envío masivo genérico, mientras que el Header From visible muestra tu dominio corporativo. Si la cabecera Authentication-Results indica fallo o ausencia de firma DKIM para tu dominio, estás ante un intento de phishing directo.

Inyección en tránsito

Detectada exclusivamente mediante el bloque Received:. El correo muestra autenticación correcta desde una herramienta autorizada, pero los saltos de red exponen direcciones IP intermedias pertenecientes a redes anónimas, ASNs de baja reputación o países sin operativa comercial. Indica una cuenta comprometida enviando desde la infraestructura legítima.

Alteración de carga útil

Ocurre cuando Authentication-Results muestra un dkim=neutral o fail con el código de error body hash did not verify. El origen es lícito, pero el contenido del mensaje fue modificado después de la firma criptográfica. Requiere investigar si los firewalls de salida o los agentes de firma en el MTA local están manipulando la codificación MIME de los adjuntos.

Integridad confirmada

El escenario óptimo. El salto Received: inferior corresponde a una IP documentada en tu inventario, el Return-Path coincide con el Header From, y Authentication-Results expone dmarc=pass con alineación validada.

Este proceso de evaluación secuencial es la base de las auditorías estructurales. Cuando los administradores IT delegan estas investigaciones, en Smartxpression aplicamos este rigor analítico en nuestras auditorías de infraestructura de correo, aislando el vector de fallo en menos de 48 horas.

Un ejemplo práctico: autopsia de un correo suplantado

Analizaremos la sección superior de un archivo .eml comprometido para aplicar la taxonomía descrita.


Authentication-Results: mx.google.com;
       dkim=neutral (body hash did not verify) header.i=@empresa-legitima.com;
       spf=pass (google.com: domain of admin@server-hacker.ru designates 192.0.2.50 as permitted sender) smtp.mailfrom=admin@server-hacker.ru;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=empresa-legitima.com
Received: from mail.server-hacker.ru (mail.server-hacker.ru. [192.0.2.50])
        by mx.google.com with ESMTPS id ...
Received: from [10.0.0.5] (unknown [203.0.113.15])
        by mail.server-hacker.ru with SMTP id ...
Return-Path: <admin@server-hacker.ru>
From: "Soporte Técnico" <soporte@empresa-legitima.com>
DKIM-Signature: v=1; a=rsa-sha256; d=empresa-legitima.com; s=k1; ...

Paso 1: Identificar la discrepancia visual. El campo From: muestra empresa-legitima.com. El usuario confía en el remitente.

Paso 2: Rastrear el origen real. El Return-Path pertenece a server-hacker.ru. La evaluación SPF es técnica y estrictamente correcta (spf=pass), porque la IP 192.0.2.50 está autorizada en el DNS de server-hacker.ru.

Paso 3: Validar DMARC. DMARC exige alineación. El dominio evaluado por SPF (server-hacker.ru) no coincide con el visible (empresa-legitima.com). La firma DKIM adjunta está rota (body hash did not verify), sugiriendo que copiaron una firma antigua de un correo real, pero alteraron el cuerpo del mensaje. DMARC dicta un fallo categórico (dmarc=fail).

Paso 4: Auditoría de tránsito. Leyendo los Received: desde abajo, vemos que el correo se originó en la IP 203.0.113.15 (posiblemente la máquina del atacante), pasó al servidor de inyección ruso, y de ahí se entregó a Google.

Diagnóstico: Vector de Falsificación de origen. El atacante forjó el From y manipuló la firma DKIM. El mensaje llegó al buzón del receptor porque la política DMARC de la víctima está configurada en p=NONE.

Qué hacer con los datos extraídos

El análisis forense de cabeceras es una acción táctica, no un fin en sí mismo. Una vez identificado el fallo, debes ejecutar correcciones técnicas precisas.

Si confirmas alteraciones de carga útil (body hash fails) en correos transaccionales legítimos, la intervención técnica requiere revisar la configuración de tu MTA interno. Frecuentemente, sistemas que adjuntan firmas legales corporativas al final de los correos operan después del módulo de firma DKIM, invalidando el proceso. Debes invertir el orden del flujo de correo.

Si identificas suplantaciones persistentes en las que el dominio es idéntico pero la IP de origen es hostil, la mitigación exige un ajuste perimetral inmediato: transicionar tu política DNS DMARC de monitorización a p=quarantine o p=reject para que los servidores de destino destruyan esa carga útil antes de la entrega.

Errores técnicos al interpretar los metadatos

El análisis de cabeceras requiere precisión metodológica. Evita estas conclusiones defectuosas durante la inspección de código:

En conclusión

La lectura forense de cabeceras SMTP desmitifica el proceso de entrega de correo. Al inspeccionar metadatos crudos, reemplazas las suposiciones sobre capacidad operativa por hechos irrefutables basados en direcciones IP de tránsito, firmas criptográficas y evaluaciones de alineación. El control sobre tu infraestructura depende de esta capacidad de análisis directo.

Si requieres aplicar este rigor técnico para estabilizar las tasas de entrega en tu organización, hemos estructurado los procedimientos de despliegue y análisis en una guía técnica detallada. Solicita el PDF completo aquí →

Este análisis de metadatos complementa directamente la monitorización global de dominios. Para contextualizar cómo un fallo individual detectado en una cabecera impacta la reputación de toda tu red, revisa el análisis sobre qué dice realmente un informe DMARC RUA.