Qué hace
Email Header Analyzer analiza las cabeceras en bruto de un mensaje de correo (RFC 5322) y las convierte en un informe forense legible: un banner de veredicto que resume todos los hallazgos en un diagnóstico de un vistazo (indicadores de suplantación encontrados / señales sospechosas / limpio), una línea de tiempo de entrega salto a salto de cada servidor Received por el que pasó el mensaje con el retardo entre saltos, los veredictos de autenticación SPF / DKIM / DMARC, y la lista completa de anomalías — señales de suplantación como una dirección From que no coincide con Return-Path, un Reply-To que apunta a un sitio inesperado, cadenas de mailer sospechosas o marcas de tiempo que van hacia atrás.
El diseño está dividido: entrada de cabeceras en bruto a la izquierda, el informe de análisis en vivo en un panel fijo a la derecha que permanece a la vista mientras te desplazas por los hallazgos. Es la herramienta a la que acudes cuando un mensaje parece phishing y quieres evidencia en lugar de una corazonada.
Cómo usarlo
- Consigue las cabeceras en bruto: en Gmail, abre el mensaje → ⋮ → Show original, y copia todo lo que está por encima del cuerpo del mensaje. Outlook: File → Properties → Internet headers.
- Pégalas en Cabeceras en bruto del correo (o pulsa Ejemplo para cargar un mensaje de demostración integrado).
- Pulsa Analizar cabeceras. El informe aparece a la derecha, bajo el banner de veredicto.
- Lee primero el banner de veredicto: rojo (peligro) = al menos un indicador crítico de suplantación, ámbar = solo advertencias, verde = sin anomalías. Los contadores de gravedad están a la derecha del banner (
critical × 1,warnings × 2,notices × 1). - Recorre las secciones: Ruta de entrega (el salto más antiguo primero, insignias de retardo codificadas por color), Autenticación (filas SPF/DKIM/DMARC), Anomalías (cada hallazgo con su evidencia) y Todas las cabeceras (la tabla completa de cabeceras desplegadas).
- Pulsa Copiar enlace para compartir para obtener una URL que transporta tu entrada exacta — quien la abra verá el mismo análisis.
Cómo leer las filas de autenticación. Cada fila muestra el nombre del mecanismo, su palabra de resultado y la cláusula de la que proviene:
- SPF — ¿obtuvo la IP del servidor emisor autorización del dominio del sobre (
smtp.mailfrom)?pass= autorizado;softfail= no autorizado, pero el dominio solo pide a los receptores que lo traten como sospechoso;fail= explícitamente no autorizado, suplantación probable;neutral= el dominio no afirma nada;none= ninguna política publicada;temperror= fallo transitorio de DNS;permerror= registro roto o mal formado. El texto adicional de la fila muestra la dirección del sobre que se comprobó. - DKIM — ¿estaba el mensaje firmado criptográficamente y se verifica la firma?
pass= firma válida (la fila muestra elselectorfirmante y, cuando está publicado, el dominio firmante deheader.d);fail= firma presente pero rota — las cabeceras o el cuerpo se modificaron en tránsito;none= sin firmar;temperror/permerror= no se pudo recuperar la clave pública. La línea de detalle muestra la cláusula en bruto, p. ej.dkim=pass header.s=sel2026 header.b=AbCdEf. - DMARC — ¿la política del dominio visible en
From:aceptó este mensaje?pass= alineación satisfecha y comprobaciones subyacentes superadas (la fila muestra el dominioheader.fromevaluado y la políticap=del dominio:none,quarantineoreject);fail= el mensaje reclama una identidad cuya propia política no lo acepta;none= el dominio From no publica ningún registro DMARC.
Una advertencia crucial que el ejemplo demuestra: los tres pueden pasar y el mensaje puede seguir siendo un señuelo de phishing. SPF/DKIM/DMARC verifican que el dominio emisor realmente envió este mensaje — no que el remitente sea de confianza, ni que Reply-To vaya adonde crees. Por eso la lista de anomalías importa incluso con un panel de autenticación totalmente “verde”.
Cómo leer la cadena de Received. Los servidores de correo anteponen cada cabecera Received, así que la herramienta las analiza de abajo hacia arriba: el salto 1 es el servidor de origen, el último salto es tu buzón. Entre saltos consecutivos muestra una insignia de retardo — el tiempo transcurrido calculado a partir de las marcas de tiempo de ambos saltos:
- verde, menos de 1 segundo (mostrado en milisegundos): relé normal.
- ámbar, 1-60 s: algo de cola o greylisting — normalmente sin problema.
- naranja, más de 60 s: relé lento, limitación del proveedor de correo o un mensaje que permaneció en una cola.
- gris “unknown delay”: el salto no tiene una marca de tiempo interpretable, así que este tramo no se puede medir (también se eleva como anomalía informativa).
Las marcas de tiempo que van hacia atrás (el salto N fechado antes que el salto N−1) reciben su propia advertencia: o los relojes de dos servidores discrepan, o alguien falsificó una cabecera Received.
Ejemplos
Carga el Ejemplo integrado y pulsa Analizar cabeceras para ver todas las funciones a la vez. Salida verificada del ejemplo:
- Ruta de entrega — 3 saltos, el más antiguo primero:
sender.evil.example → mail.relay.example(ESMTP), luegomail-sor-f41.google.com → mx.google.com(ESMTPS, +7.0 s), luegomx.google.com(SMTP, +3.0 s). - Autenticación — todo pasa: SPF
passparabilling@legit-shop.com, DKIMpasscon selectorsel2026, DMARCpasscon políticaquarantineparalegit-shop.com. - Banner de veredicto — rojo:
critical × 1,warnings × 2, porque las anomalías son:
From: "Legit Shop Support" <support@legit-shop.com>
Reply-To: billing@evil.example
Return-Path: bounce@evil.example
X-Mailer: SuperBulk Mass Mailer 4.2→ Crítico: Return-Path (bounce@evil.example) no coincide con From (support@legit-shop.com) — el remitente del sobre difiere del remitente mostrado. Más advertencias por el Reply-To desviado y el X-Mailer de envío masivo. La autenticación pasó porque legit-shop.com lo envió de verdad — el mensaje aún está construido para parecer lo que no es.
Un mensaje limpio (sobre coincidente con From, firmado, autenticado):
Received: from mail.example.com by mx.google.com with ESMTPS; Tue, 12 Aug 2026 10:15:42 -0700
Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=billing@legit-shop.com; dkim=pass header.s=sel2026; dmarc=pass (p=quarantine) header.from=legit-shop.com
From: Billing <billing@legit-shop.com>
Return-Path: <billing@legit-shop.com>→ Veredicto verde, “No spoofing indicators found”, cero anomalías.
Un panel fallido — los tres mecanismos se muestran en rojo:
Authentication-Results: mx.example.com; spf=softfail smtp.mailfrom=spoof@wrong.example; dkim=fail header.s=sel1; dmarc=fail (p=reject) header.from=bank.example→ SPF softfail para spoof@wrong.example, DKIM fail (selector sel1), DMARC fail con política reject — un mensaje que un receptor estricto debería haber rechazado.
Un salto falsificado — marcas de tiempo que van hacia atrás:
Received: by mx.example.com; Tue, 12 Aug 2026 10:15:40 -0700
Received: from a.example by b.example; Tue, 12 Aug 2026 10:15:50 -0700→ Advertencia: El salto 2 está fechado 10.0 s ANTES que el salto 1 — desviación de reloj entre servidores o una cabecera Received falsificada.
Buen saber
Todas las señales que comprueba el analizador (gravedad entre paréntesis):
- Return-Path distinto de From (crítica) — el remitente del sobre (
Return-Path, adonde van los rebotes) usa una dirección distinta de la mostrada enFrom. Suplantación clásica; también común en el relé legítimo de listas de correo. - Reply-To difiere de From (advertencia) — las respuestas se desviarían a una tercera dirección. Legítimo en mesas de soporte, condenatorio cuando el From es tu banco.
- Cadena de mailer sospechosa (advertencia) —
X-MaileroUser-Agentcontiene un token asociado con herramientas de envío masivo: bulk, mass mail, massmail, storm, flood, bomber, grabber, harvest, spambot, stealth, anonymous, dark, crack (coincidencias por subcadena, sin distinguir mayúsculas). - Salto sin marca de tiempo interpretable (informativa) — el retardo de ese tramo no puede calcularse; se muestra como insignia de “unknown delay”.
- Tiempo que va hacia atrás (advertencia) — un salto fechado antes que el salto anterior: desviación de reloj o una cabecera
Receivedfalsificada. - Sin cabecera Authentication-Results (informativa) — el estado SPF/DKIM/DMARC no puede verificarse en absoluto a partir de este mensaje.
Detalles del analizador que conviene conocer:
- Privado: todo el análisis es 100% en el cliente — tus cabeceras nunca salen del navegador.
- Las cabeceras se despliegan según RFC 5322 (las líneas de continuación empiezan con espacio en blanco); el análisis se detiene en la primera línea vacía (el separador del cuerpo); las líneas basura que no son cabeceras se omiten.
- Cuando un mensaje lleva varias cabeceras
Authentication-Results, el primer veredicto de cada mecanismo gana; el resto se ignora. - Las marcas de tiempo de los saltos se leen tras el último
;de cada líneaReceived(con un respaldo en el primer token que parece fecha), y los comentarios de zona al final como(PDT)se ignoran. - Una pieza que falta se informa, nunca se adivina: retardos desconocidos, autenticación no verificable y huecos en la cadena afloran como hallazgos explícitos en lugar de quedar en blanco en silencio.
- Herramientas relacionadas: PII Redactor, Defang / Refang,
Base64Base64An encoding representing binary data as 64 safe ASCII characters, so it survives transport through text-only channels. It encodes — it does not encrypt.
.