10 fallos de los filtros email: las señales sutiles que tu pasarela pasa por alto

⚡TL;DR

• Las pasarelas email bloquean el spam obvio pero pasan por alto los ataques sofisticados que explotan fallos sutiles en las cabeceras
• 10 indicadores precisos en las cabeceras delatan los emails maliciosos: desfase de sobre, DKIM de terceros, Reply-To divergente, cadena Received anormal y otras seis señales técnicas
• Cada indicador se deconstruye desde la perspectiva del atacante (como lo explota) y del defensor (como detectarlo)
• El análisis de cabeceras después de la pasarela es la última línea de defensa para el 1% de emails que superan todos los filtros

Tu pasarela email muestra una tasa de bloqueo del 99,5%. El informe mensual es tranquilizador, los paneles están en verde y tu equipo de seguridad pasa al siguiente tema. El problema se esconde en el 0,5% restante. Sobre un volumen de 200 000 emails mensuales, eso representa 1 000 mensajes no filtrados. Entre ellos, basta un solo email de spear-phishing dirigido al empleado adecuado para comprometer una cuenta privilegiada, exfiltrar datos o desencadenar un ransomware. El coste medio de una brecha iniciada por phishing alcanza los 4,8 millones de dólares (IBM, Cost of a Data Breach 2025), y el tiempo medio para detectar un compromiso por phishing es de 207 días (IBM, 2025). Según el informe Verizon DBIR 2025, el tiempo mediano entre la recepción de un email de phishing y el primer clic es de 21 segundos. Tus usuarios no reflexionan: reaccionan.

Las pasarelas de seguridad email (Secure Email Gateways, SEG) como Proofpoint, Mimecast, Barracuda o Microsoft Defender for Office 365 analizan el contenido, la reputación IP, las firmas conocidas y las heurísticas comportamentales. Pero comparten un angulo muerto común: las señales sutiles en las cabeceras SMTP y MIME que los atacantes sofisticados manipulan para superar los filtros sin activar ninguna alerta. Las cifras son claras: las pasarelas fallan en el 30 al 50% de las amenazas avanzadas, y el volumen de emails maliciosos que eluden los SEG ha aumentado un 105% en un año, es decir, un email malicioso cada 19 segundos que supera los filtros (Cofense, Annual State of Email Security 2026). Sin sorpresa, el 91% de los responsables de seguridad se declaran frustrados con el rendimiento de su SEG (Egress, Email Security Risk Report 2024). No es un problema teórico. En 2025, el grupo Tycoon2FA exploto fallos de enrutamiento MX y autenticación email para generar 13 millones de emails maliciosos en un solo mes, eludiendo las pasarelas de miles de organizaciones. En total, el 78% de las organizaciones han sufrido al menos una brecha email en los últimos 12 meses (Barracuda, 2025).

Este artículo disecciona 10 indicadores precisos en las cabeceras email que la mayoría de las pasarelas ignoran o subestiman. Para cada indicador, se detalla la perspectiva del atacante (como lo explota) y la del defensor (como detectarlo), con ejemplos concretos de cabeceras. Si eres ingeniero de seguridad, analista SOC, administrador email o CISO, estas 10 señales deberían formar parte de tu cuadricula de análisis post-pasarela.

Por que los filtros email no son suficientes

Lo que las pasarelas verifican (y lo que ignoran)

Las pasarelas email modernas se basan en varias capas de filtrado. La reputación IP verifica si la dirección del servidor emisor figura en listas negras (Spamhaus, Barracuda, SpamCop). El análisis de contenido busca palabras clave sospechosas, URLs maliciosas y archivos adjuntos peligrosos. Las firmas anti-malware comparan los archivos con bases de definiciones conocidas. Las heurísticas comportamentales detectan patrones de envío masivo y anomalías estadísticas.

Esta arquitectura funciona contra el spam masivo y las campañas de phishing genéricas. Un servidor con una IP en lista negra, un email con "Haz clic aquí para recuperar tu premio" y un archivo adjunto .exe se bloquean antes de llegar a la bandeja de entrada. La tasa de bloqueo del 99% es real para este tipo de amenazas.

Pero los atacantes que apuntan a tu organización no hacen nada de eso. Envían desde IPs limpias (alquiladas en ESP legítimos), redactan mensajes creibles y manipulan las cabeceras SMTP para que el mensaje parezca un email legítimo. Dato notable: el 82,6% de los emails de phishing analizados usan ahora alguna forma de IA para la redacción (KnowBe4, Phishing Threat Trends 2025), y la tasa de clic en estos emails generados por IA alcanza el 54%, frente al 12% de los emails redactados manualmente (Brightside AI, 2025). Además, el 76,4% de los ataques de phishing contienen al menos un rasgo polimorfico, es decir, cada email enviado es ligeramente diferente para evadir las firmas estáticas (KnowBe4, 2025). La pasarela ve un email que "pasa" todos sus criterios estándar y lo deja entrar.

Lo que las pasarelas ignoran en gran medida son las señales de coherencia en las cabeceras. Un email legítimo presenta coherencia interna: el dominio del From coincide con el dominio del Return-Path y del Message-ID, la firma DKIM cubre el dominio correcto, la cadena Received es lógica y las cabeceras propietarias de la plataforma de alojamiento están presentes. Cuando un atacante falsifica un email, reproduce las cabeceras visibles (From, Subject, Date) pero deja incoherencias en las cabeceras técnicas que solo un examen profundo revela. Las pasarelas no realizan ese examen.

La paradoja de la adaptación

Cuanto más estricto es un filtro, más se adapta el atacante. Los grupos de amenazas avanzadas (APT, operaciones de spear-phishing dirigido) prueban sistemáticamente sus emails contra las pasarelas del mercado antes de lanzar una campaña. Servicios clandestinos ofrecen "SEG testing": el atacante envía su email y recibe un informe indicando que pasarelas lo bloquean y cuales lo dejan pasar. Es un proceso iterativo. El atacante ajusta las cabeceras, el contenido y la infraestructura de envío hasta obtener una tasa de paso satisfactoria.

El resultado: los emails que llegan a la bandeja de entrada tras la pasarela no son intentos fallidos. Son los intentos más logrados, los que han sido optimizados para eludir tus defensas específicas. Es un sesgo cognitivo frecuente en los equipos de seguridad: considerar que lo que supera la pasarela es "probablemente legítimo". En realidad, es exactamente lo contrario. Lo que supera la pasarela tras un filtrado estricto es potencialmente más peligroso que el spam promedio, porque ha sido diseñado para pasar.

Este fenomeno explica por que los usuarios formados para reconocer los signos visuales del phishing siguen cayendo. Los emails que superan la pasarela ya no contienen errores ortograficos, maquetaciones aproximadas o URLs evidentes. Se parecen a emails legítimos porque han sido optimizados para ello. La única diferencia reside en las cabeceras técnicas, invisibles para el usuario final.

La última línea de defensa: el análisis post-pasarela

Por eso el análisis de cabeceras después del filtrado es crítico. Los 10 indicadores detallados en este artículo no sustituyen la pasarela: complementan la detección examinando señales que los filtros automatizados no verifican o verifican mal. Este análisis puede ser manual (para incidentes individuales), semiautomatizado (reglas de transporte Exchange/Gmail) o integrado en un SIEM para la detección a gran escala.

Los 10 indicadores que tu pasarela pasa por alto

1. Desfase Return-Path / From (desfase de sobre)

Como lo explota el atacante. El protocolo SMTP separa dos identidades distintas: el remitente de sobre (MAIL FROM, visible en la cabecera Return-Path) y el remitente mostrado (cabecera From). El atacante configura su servidor para enviar con un Return-Path que controla (bounce@atacante-infra.net) mientras muestra un From creible (direction@captaindns.com). La mayoría de los clientes email solo muestran el From. El destinatario ve un email que parece provenir de la dirección, sin sospechar que el sobre apunta a otro sitio.

Por que los filtros lo pasan por alto. Las pasarelas verifican SPF sobre el Return-Path y DKIM sobre el From, pero pocas comparan activamente ambos y alertan sobre un desfase. Un SPF pass sobre el Return-Path y un DKIM pass sobre un dominio de terceros suelen ser suficientes para dejar pasar el mensaje.

Lo que el defensor debe verificar. Comparar el dominio en Return-Path con el dominio en From. Si difieren sin razón legítima (lista de correo, ESP configurado), es una señal fuerte.

Ejemplo de cabecera:

Return-Path: <bounce-7842@atacante-infra.net>
From: "Dirección General" <direction@captaindns.com>

El desfase es visible inmediatamente: el sobre viene de atacante-infra.net, el From muestra captaindns.com. Un email legítimo enviado a través de un ESP tendria un Return-Path conteniendo el dominio del ESP configurado en el SPF del dominio remitente, no un dominio de terceros desconocido.

Cuando el desfase es legítimo. Es normal que el Return-Path difiera del From en ciertos casos: los ESP (SendGrid, Mailgun, Amazon SES) usan su propio dominio para el Return-Path con el fin de gestionar los rebotes. Las listas de difusión reescriben el Return-Path. La clave es verificar si el dominio del Return-Path es el de un servicio conocido y configurado en el SPF del dominio del From. Un Return-Path hacia un dominio desconocido (atacante-infra.net) asociado a un From empresarial (captaindns.com) sin vínculo SPF es una señal fuerte.

2. DKIM firmado por un dominio de terceros (firma delegada)

Como lo explota el atacante. El atacante crea una cuenta en un ESP legítimo (SendGrid, Mailgun, Amazon SES) y configura DKIM para su propio dominio. Luego envía un email con un From suplantado (compta@captaindns.com). El mensaje lleva una firma DKIM válida, pero firmada por el dominio del atacante (d=atacante-marketing.com), no por captaindns.com. La pasarela ve "dkim=pass" y considera el mensaje como autenticado.

Por que los filtros lo pasan por alto. Las pasarelas verifican que la firma DKIM es técnicamente válida (la clave pública coincide, el hash del cuerpo es correcto). Pero la mayoría no verifica si el dominio firmante (d=) corresponde al dominio del From. Eso es el papel del alineamiento DMARC, y muchas organizaciones aún no han desplegado DMARC en modo estricto.

Lo que el defensor debe verificar. En la cabecera DKIM-Signature, comparar el campo d= con el dominio del From. Si no corresponden, el email está firmado por un tercero que no tiene autoridad sobre el dominio mostrado.

Ejemplo de cabecera:

DKIM-Signature: v=1; a=rsa-sha256; d=atacante-marketing.com;
    s=sel2026; c=relaxed/relaxed;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
From: "Servicio Contabilidad" <compta@captaindns.com>

El d=atacante-marketing.com no corresponde al From captaindns.com. La firma es técnicamente válida pero el alineamiento está roto.

3. SPF pass pero alineamiento DMARC fallido

Como lo explota el atacante. El atacante envía desde un servidor cuya IP está autorizada por el SPF de un dominio que controla (su propio dominio o un dominio de ESP). El MAIL FROM (sobre) usa ese dominio autorizado, lo que da un SPF pass. Pero el From (cabecera) muestra el dominio del objetivo (rh@captaindns.com). SPF pasa, DKIM está ausente o firmado por otro dominio, y DMARC falla en alineamiento. Si el dominio objetivo tiene una política DMARC p=none, no se toma ninguna acción. Y está falla es masiva: el 84,2% de los ataques de phishing analizados pasan los controles DMARC (Egress, Email Security Risk Report 2024), en gran parte porque el 47% de los dominios email no tienen configuración DMARC (Barracuda, 2025), el 63% de los implementadores permanecen en p=none (Mailgun/Email on Acid, 2025) y solo el 4% de los dominios aplican p=reject (Valimail, 2025).

Por que los filtros lo pasan por alto. La pasarela ve spf=pass en los resultados de autenticación y atribuye una puntuación positiva. El hecho de que el alineamiento DMARC falle a menudo está infraponderado si la política es p=none. El resultado neto: el mensaje pasa el filtrado con una "puntuación de autenticación aceptable".

Lo que el defensor debe verificar. En la cabecera Authentication-Results, buscar la combinación spf=pass con dmarc=fail. Esta combinación indica que el SPF paso sobre un dominio diferente del From, señal clásica de suplantación.

Ejemplo de cabecera:

Authentication-Results: mx.captaindns.com;
    spf=pass (sender IP is 198.51.100.42)
        smtp.mailfrom=bounces.atacante-esp.com;
    dkim=none;
    dmarc=fail (p=none dis=none) header.from=captaindns.com

El spf=pass corresponde a atacante-esp.com (sobre), no a captaindns.com (From). DMARC falla porque ningún mecanismo (SPF o DKIM) está alineado con el dominio del From. La política p=none deja pasar.

4. Reply-To hacia un dominio diferente del From

Como lo explota el atacante. El atacante falsifica un From creible (support@captaindns.com) pero inserta un Reply-To hacia una dirección que controla (support-captaindns@protonmail.com o support@captaindns-helpdesk.com). Cuando el destinatario responde, su respuesta va hacia el atacante. Es una técnica terriblemente eficaz para el BEC (Business Email Compromise), que ha causado 55 500 millones de dólares de pérdidas acumuladas en diez años (FBI IC3, 2024). El primer email no contiene ni enlace ni archivo adjunto, lo que evita toda detección por análisis de contenido.

Por que los filtros lo pasan por alto. El Reply-To es una cabecera informativa, no un mecanismo de autenticación. Las pasarelas generalmente no comparan el dominio del Reply-To con el del From. Un email sin URL sospechosa ni archivo adjunto, con un SPF pass y un contenido textual limpio, supera los filtros sin dificultad.

Lo que el defensor debe verificar. Comparar el dominio de la cabecera Reply-To con el del From. Un desfase hacia un dominio gratuito (Gmail, ProtonMail, Outlook.com) o un dominio similar (typosquatting) es una señal fuerte de BEC.

Ejemplo de cabecera:

From: "Jean Dupont - DAF" <jean.dupont@captaindns.com>
Reply-To: jean.dupont.captaindns@protonmail.com
Subject: Transferencia urgente - factura proveedor

El From muestra una dirección interna creible. El Reply-To redirige hacia una cuenta ProtonMail que el atacante controla. Si el destinatario responde sin verificar, la conversación continua con el atacante.

Variantes avanzadas. Los atacantes más sofisticados no usan un dominio gratuito evidente. Registran un dominio de typosquatting cercano al dominio objetivo: captaindns-support.com, captaindns.net, captaindnss.com. Estos dominios son más difíciles de detectar en una lectura rápida del Reply-To. Otra variante consiste en usar un subdominio engañoso: captaindns.service-desk.com (el dominio real es service-desk.com, no captaindns). Para la detección automatizada, mantén una lista blanca de dominios Reply-To autorizados y marca todo lo que no figure en ella.

5. Cadena Received anormalmente corta o larga

Como lo explota el atacante. Cada servidor que procesa un email añade una cabecera Received en la parte superior de la pila. Un email legítimo atraviesa generalmente de 3 a 5 saltos (servidor del remitente, pasarela saliente, MX del destinatario, pasarela entrante, servidor de buzones). El atacante puede manipular está cadena de dos formas. Primera opción: enviar directamente desde un script hacia el MX del destinatario, produciendo una cadena con solo 1 o 2 saltos, señal de un envío no estándar. Segunda opción: inyectar cabeceras Received falsas para simular un tránsito por servidores legítimos, alargando artificialmente la cadena.

Por que los filtros lo pasan por alto. Las pasarelas no cuentan sistemáticamente el número de saltos ni verifican la coherencia temporal entre los Received. Un email con 8 saltos de los cuales 3 son falsificados pasa los controles estándar si las cabeceras forjadas están bien formateadas.

Lo que el defensor debe verificar. Contar las cabeceras Received y verificar dos cosas. Primero, la coherencia temporal: las marcas de tiempo deben progresar de abajo (primer salto) hacia arriba (último salto). Un salto en el tiempo (un salto fechado antes del anterior) indica una cabecera forjada. Segundo, el número de saltos: menos de 2 o más de 7 es anormal para un email profesional estándar.

Ejemplo de cabecera (cadena sospechosa, demasiado corta):

Received: from mail-gw.captaindns.com (10.0.1.5) by mailbox.captaindns.com;
    Thu, 27 Mar 2026 09:15:22 +0100
Received: from unknown (HELO send-node-14.atacante.net) (45.77.200.18)
    by mail-gw.captaindns.com; Thu, 27 Mar 2026 09:15:20 +0100

Solo 2 saltos. Sin servidor saliente, sin pasarela del remitente. El mensaje fue enviado directamente desde un nodo de envío hacia el MX de captaindns.com, señal de un envío por script, no de un servidor de mensajería empresarial.

La técnica de las cabeceras Received forjadas. Un atacante más sofisticado inserta cabeceras Received falsas para simular un tránsito por servidores legítimos. Añade por ejemplo un salto Received: from mail-out.captaindns.com (10.0.1.2) by gateway.captaindns.com al fondo de la pila. La trampa: los servidores de recepción añaden las cabeceras Received en la parte superior de la pila, no en la inferior. Las cabeceras del fondo son las más antiguas y las primeras en haber sido añadidas. Una cabecera Received que afirma provenir de un servidor interno pero que se encuentra al fondo de la pila (antes del primer salto legítimo) es una cabecera forjada por el emisor. Verifica siempre la coherencia de la cadena comenzando por el fondo.

6. Ausencia de TLS en el primer salto (STARTTLS ausente)

Como lo explota el atacante. El atacante usa un servidor configurado sin soporte TLS o desactiva voluntariamente STARTTLS. El objetivo no es el cifrado en si, sino lo que revela su ausencia. Un servidor de mensajería legítimo en 2026 soporta STARTTLS. Un servidor que envía en texto plano es probablemente un script, una herramienta de ataque o un servidor comprometido. La ausencia de TLS también puede indicar un ataque de degradación SMTP, donde un atacante intercepta la negociación TLS para forzar la transmisión en texto plano.

Por que los filtros lo pasan por alto. Las pasarelas no bloquean los emails recibidos sin TLS. El protocolo SMTP está diseñado para funcionar en texto plano con TLS como extensión opcional. Muchas pasarelas aceptan conexiones sin cifrar para no perder correo legítimo proveniente de servidores antiguos. El hecho de que el primer salto sea en texto plano no es un criterio de filtrado estándar.

Lo que el defensor debe verificar. En la primera cabecera Received (la más baja en la pila), buscar la mención with ESMTPS (conexión TLS) frente a with SMTP o with ESMTP (conexión en texto plano). Un email profesional en 2026 debería siempre transitar con TLS activado en el primer salto.

Ejemplo de cabecera:

Received: from send-node.atacante.net (45.77.200.18)
    by mail-gw.captaindns.com with SMTP;
    Thu, 27 Mar 2026 09:15:20 +0100

La mención with SMTP (sin la S de ESMTPS) indica una conexión en texto plano. Un servidor de mensajería empresarial legítimo tendria with ESMTPS o with TLS. Esta ausencia de cifrado es una señal débil pero significativa cuando se combina con otros indicadores.

7. X-Mailer o User-Agent sospechoso

Como lo explota el atacante. Los clientes de correo y los servidores insertan una cabecera X-Mailer o User-Agent que identifica el software utilizado. Los atacantes usan scripts Python (biblioteca smtplib o aiosmtplib), herramientas de envío masivo (GoPhish, King Phisher, Social Engineering Toolkit) o frameworks propios. Algunos atacantes omiten está cabecera (lo que ya es una señal), otros la falsifican para imitar un cliente legítimo (Outlook, Thunderbird). Las falsificaciones suelen ser imperfectas: una versión inexistente, un formato de cadena incoherente o un X-Mailer que no coincide con las demás cabeceras presentes.

Por que los filtros lo pasan por alto. El X-Mailer no es una cabecera estandarizada por las RFC. Las pasarelas no lo consideran un criterio de seguridad y no mantienen una base de firmas de clientes maliciosos. Un email enviado desde GoPhish con un X-Mailer falsificado Microsoft Outlook 16.0 pasa los filtros si el contenido y la reputación IP son limpios.

Lo que el defensor debe verificar. Buscar la cabecera X-Mailer o User-Agent. Un User-Agent Python (Python/3.11 aiosmtplib/2.0) es una señal fuerte. La ausencia total de X-Mailer en un email supuestamente procedente de Outlook es sospechosa. Una versión de Outlook que no existe (por ejemplo Microsoft Outlook 17.5 cuando la última versión es 16.x) delata una falsificación.

Ejemplo de cabecera:

X-Mailer: Python/3.11 aiosmtplib/2.0.1
From: "Servicio IT" <it-support@captaindns.com>
Subject: Actualización obligatoria de tu contraseña

Un email de "actualización de contraseña" enviado desde un script Python. Ningún servicio IT legítimo envía emails críticos a través de un script Python con aiosmtplib. Esta cabecera delata una herramienta de ataque o un test de phishing interno.

8. Message-ID con dominio incoherente

Como lo explota el atacante. La cabecera Message-ID es un identificador único generado por el servidor de envío. Contiene típicamente un hash o un identificador aleatorio seguido del dominio del servidor que lo generó. El atacante que suplanta el From @captaindns.com pero envía desde su propio servidor genera un Message-ID con su propio dominio o un identificador genérico. Este desfase entre el dominio del From y el dominio en el Message-ID revela la infraestructura real del atacante.

Por que los filtros lo pasan por alto. El Message-ID se usa para el seguimiento de hilos de conversación y la deduplicación, no para la seguridad. Las pasarelas no comparan el dominio del Message-ID con el dominio del From. Es una cabecera técnica que pocos sistemas de filtrado analizan desde el angulo de la coherencia.

Lo que el defensor debe verificar. Extraer el dominio después del @ en el Message-ID y compararlo con el dominio del From. Un desfase indica que el mensaje fue generado por un servidor que no pertenece al dominio mostrado.

Ejemplo de cabecera:

Message-ID: <a3f8e2c1-9b47-4d6e-b5a2-1c7d3e9f0482@vps-node-14.atacante.net>
From: "Recursos Humanos" <rh@captaindns.com>

El Message-ID revela el servidor real: vps-node-14.atacante.net. Un email legítimo de captaindns.com tendria un Message-ID conteniendo captaindns.com o el dominio del ESP utilizado (por ejemplo amazonses.com si la organización usa Amazon SES).

9. Cabeceras X-MS-Exchange o X-Google ausentes

Como lo explota el atacante. Las grandes plataformas de mensajería insertan cabeceras propietarias específicas. Microsoft 365 añade X-MS-Exchange-Organization-AuthSource, X-MS-Exchange-Organization-AuthAs, X-MS-Has-Attach, X-MS-TNEF-Correlator y otras. Gmail añade X-Gm-Message-State, X-Google-DKIM-Signature, X-Google-Smtp-Source. Cuando un email afirma venir de un dominio alojado en Microsoft 365 pero no contiene ninguna de estas cabeceras, no ha transitado por la plataforma Microsoft. El atacante que falsifica el From @captaindns.com (dominio alojado en M365) pero envía desde su propio servidor no puede reproducir estas cabeceras propietarias de manera creible.

Por que los filtros lo pasan por alto. Las pasarelas de terceros (no Microsoft, no Google) no conocen la lista de cabeceras propietarias esperadas para cada plataforma. Incluso las pasarelas integradas (Defender, Gmail) no verifican sistemáticamente la coherencia entre el dominio From y la presencia de las cabeceras esperadas de la plataforma de alojamiento.

Lo que el defensor debe verificar. Identificar la plataforma de alojamiento del dominio del From (M365, Google Workspace, otra). Verificar que las cabeceras propietarias correspondientes están presentes. Un email @captaindns.com (alojado en M365) sin ninguna cabecera X-MS-Exchange-* no ha transitado por Microsoft 365.

Ejemplo de cabecera (email sospechoso, From M365 pero sin cabeceras Exchange):

From: "Dirección Financiera" <daf@captaindns.com>
To: contabilidad@captaindns.com
Subject: Validación urgente - transferencia internacional
Date: Thu, 27 Mar 2026 09:15:00 +0100
Message-ID: <random-id@send-node.atacante.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Ninguna cabecera X-MS-Exchange-*, ningún X-MS-Has-Attach, ningún X-OriginatorOrg. Si captaindns.com está alojado en Microsoft 365, este email no ha transitado por la plataforma. Es una falsificación enviada desde un servidor externo.

10. Content-Type multipart con archivo adjunto .html encapsulado

Como lo explota el atacante. El atacante encapsula una página HTML de robo de credenciales (credential harvesting) en el cuerpo MIME del mensaje. A diferencia de un archivo adjunto clásico (.exe, .zip) que activa las alertas, un archivo .html a menudo se considera inofensivo por las pasarelas. Cuando el usuario abre el archivo adjunto HTML, su navegador carga una página de inicio de sesión falsa que imita Microsoft 365, Google Workspace u otro servicio. Las credenciales introducidas se envían al servidor del atacante. La página HTML puede funcionar completamente offline (sin descarga de recursos externos), lo que dificulta la detección por los sandboxes.

Por que los filtros lo pasan por alto. Los archivos HTML no son ejecutables y no contienen código malicioso en el sentido tradicional (sin shellcode, sin macro). Las pasarelas que analizan archivos adjuntos se concentran en formatos de riesgo (.exe, .docm, .xlsm, .js, .vbs). Un archivo HTML es contenido web estático, y muchos filtros lo dejan pasar. Algunas pasarelas analizan las URLs en el HTML, pero si la página funciona offline con JavaScript embebido, no hay URL que bloquear en el momento de la entrega.

Lo que el defensor debe verificar. En las cabeceras MIME, buscar una parte con Content-Type: text/html y Content-Disposition: attachment. La combinación HTML + attachment es una señal fuerte. Analizar el contenido del archivo HTML: la presencia de etiquetas <form>, <input type="password"> o de JavaScript ofuscado en un archivo adjunto HTML es casi con certeza maliciosa.

Ejemplo de cabecera:

Content-Type: multipart/mixed;
    boundary="----=_NextPart_001_0042_01D8F3A2.B5C7E890"

------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hola, por favor consulta el documento de seguridad adjunto.

------=_NextPart_001_0042_01D8F3A2.B5C7E890
Content-Type: text/html; name="security-update-captaindns.html"
Content-Disposition: attachment; filename="security-update-captaindns.html"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCjxoZWFkPjx0aXRsZT5DYXB0YWluRE5T...

El boundary MIME contiene un archivo adjunto security-update-captaindns.html. El cuerpo en base64 decodifica hacia una página HTML con un formulario de inicio de sesión. Un email legítimo de CaptainDNS nunca enviaria un archivo HTML como adjunto para una "actualización de seguridad".

Técnicas de evasion en el HTML embebido. Los atacantes usan varias técnicas para evadir los sandboxes que analizan archivos adjuntos HTML. El JavaScript puede estar ofuscado (codificación base64, concatenación de cadenas, ejecución dinámica de código). La página puede verificar si se ejecuta en un navegador real (detección de resolución de pantalla, de movimiento de raton, de plugins) y solo activar el formulario de phishing si se cumplen las condiciones. Algunas páginas HTML usan el protocolo data: o Blob URLs para construir dinámicamente el formulario, haciendo ineficaz el análisis estático. En 2025 y 2026, los archivos adjuntos .svg con JavaScript embebido se han convertido en una variante cada vez más común de está técnica, ya que los SVG son aún menos vigilados que los archivos HTML.

Combinar los indicadores: el poder del scoring multi-señal

Tomados individualmente, cada indicador puede tener una explicación legítima. Un Return-Path diferente del From es normal cuando un ESP envía en nombre de una organización. Un DKIM firmado por un dominio de terceros es estándar con SendGrid o Amazon SES. Una cadena Received corta puede provenir de un servidor on-premise que envía directamente.

El poder de estos 10 indicadores aparece cuando se combinan. Un email que presenta un solo indicador merece una verificación. Un email que presenta tres indicadores o más es casi con certeza malicioso. El principio es el scoring multi-señal: atribuir una puntuación a cada indicador detectado y escalar cuando la puntuación acumulada supera un umbral.

Ejemplo de scoring para un email sospechoso:

Indicador detectado	Puntuación
Return-Path ≠ From (dominio desconocido)	+2
DKIM firmado por dominio de terceros no ESP	+2
SPF pass + DMARC fail	+3
Reply-To hacia dominio gratuito	+3
Cadena Received < 3 saltos	+1
Ausencia de TLS en primer salto	+1
X-Mailer Python/script	+2
Message-ID dominio ≠ From	+2
Ausencia cabeceras X-MS-Exchange (dominio M365)	+3
Archivo adjunto HTML	+2

Un umbral de 5 puntos activa una señalización para revisión SOC. Un umbral de 8 puntos activa una cuarentena automática. Este scoring puede implementarse en las reglas de transporte Exchange/Gmail o en un SIEM.

En la práctica, los emails de spear-phishing sofisticados combinan generalmente de 3 a 5 indicadores. Los indicadores 1 (desfase Return-Path), 3 (SPF pass + DMARC fail) y 8 (Message-ID incoherente) aparecen juntos en la mayoría de los casos de suplantación de dominio. Los indicadores 4 (Reply-To divergente) y 9 (ausencia de cabeceras propietarias) caracterizan los ataques BEC (Business Email Compromise). La combinación 5 (cadena Received corta) + 6 (ausencia TLS) + 7 (X-Mailer script) delata un envío desde una herramienta de ataque.

La lección es clara: nunca juzgues un email por un solo indicador. Construye un scoring multi-señal adaptado a tu entorno y calibra los umbrales analizando tus emails legítimos y tus incidentes pasados.

Como detectar estas señales después de la pasarela

Análisis manual con una herramienta de inspección

Para los incidentes individuales (un usuario reporta un email sospechoso), el análisis manual de cabeceras sigue siendo el método más rápido. El usuario exporta las cabeceras brutas desde su cliente email (en Outlook: Archivo > Propiedades > Encabezados de Internet; en Gmail: los tres puntos > Mostrar original). El analista SOC pega las cabeceras en una herramienta de análisis que descompone cada cabecera y resalta las anomalías.

Los puntos a verificar en prioridad durante el análisis manual:

1. Return-Path vs From: ¿dominios idénticos o justificación legítima del desfase?
2. DKIM d= vs From: ¿la firma cubre el dominio correcto?
3. Authentication-Results: ¿combinación spf=pass + dmarc=fail?
4. Reply-To: ¿dominio coherente con el From?
5. Cadena Received: ¿número de saltos, coherencia temporal, presencia de TLS?
6. Message-ID: ¿dominio coherente con el From?
7. Cabeceras propietarias: ¿presentes si el dominio está alojado en M365/Gmail?
8. Partes MIME: ¿archivo adjunto HTML sospechoso?

Reglas de transporte Exchange/Gmail para el marcado automático

Para una detección sistemática, las reglas de transporte (mail flow rules) en Exchange Online o las reglas de enrutamiento en Google Workspace permiten marcar automáticamente los mensajes que presentan ciertos indicadores.

Ejemplo de regla Exchange Online para detectar el desfase Reply-To:

Condición: la cabecera Reply-To contiene un dominio diferente del dominio del From, Y el dominio del Reply-To no está en una lista blanca (dominios internos, ESP autorizados). Acción: añadir un banner de advertencia al mensaje ("Este mensaje tiene un Reply-To diferente del remitente mostrado") y marcarlo para revisión SOC.

Ejemplo de regla para detectar la ausencia de cabeceras M365:

Condición: el dominio del From es un dominio interno alojado en M365, Y la cabecera X-MS-Exchange-Organization-AuthSource está ausente. Acción: poner en cuarentena para revisión manual.

Estas reglas no sustituyen la pasarela pero añaden una capa de detección post-filtrado dirigida a las señales que la pasarela ignora.

Integración SIEM para la detección a gran escala

Para las organizaciones con un volumen significativo de emails, la integración con un SIEM (Microsoft Sentinel, Splunk, Elastic Security) permite automatizar la detección y la correlación. Los logs de transporte Exchange o Gmail contienen los resultados de autenticación, las cabeceras clave y los metadatos de enrutamiento. Reglas de detección personalizadas buscan los siguientes patrones:

• Volumen anormal de emails con dmarc=fail action=none para un dominio interno
• Emails entrantes con Reply-To hacia dominios gratuitos cuando el From es un dominio interno
• Mensajes sin cabeceras X-MS-Exchange-* cuando el dominio From está alojado en M365
• Archivos adjuntos HTML en emails entrantes con un From interno

La correlación SIEM también permite cruzar un email sospechoso con las conexiones de red: si un usuario abre un archivo adjunto HTML a las 09:15 y una conexión sospechosa a M365 desde una IP extranjera aparece a las 09:18, el incidente se detecta en casi tiempo real.

El vínculo con la entregabilidad y el spam

Los 10 indicadores descritos en este artículo no conciernen únicamente a la seguridad. También afectan la entregabilidad de tus propios emails. Si tu dominio presenta las mismas señales que un email de phishing (Return-Path incoherente, DKIM no alineado, DMARC en p=none), las pasarelas de los destinatarios van a tratar tus mensajes con sospecha. Tus emails legítimos terminan en spam porque tu configuración DNS y tus cabeceras activan las mismas señales que los atacantes explotan.

Corregir tus propias cabeceras (alinear SPF y DKIM, pasar DMARC a p=reject, configurar Message-ID coherentes) tiene un doble beneficio: reforzar la seguridad de tu dominio contra la suplantación Y mejorar la entregabilidad de tus emails legítimos. Es la misma cuadricula de lectura aplicada a dos objetivos complementarios.

Plan de acción

1. Auditar tus 50 últimos emails sospechosos: recupera las cabeceras de los emails reportados por tus usuarios en el último mes y analiza cada uno con los 10 indicadores. Esta auditoría revela los tipos de ataques que superan tu pasarela.
2. Crear reglas de transporte para los indicadores 1, 4 y 5: el desfase Return-Path/From, el Reply-To divergente y la cadena Received anormal son las tres señales más fáciles de detectar automáticamente mediante reglas Exchange o Gmail.
3. Reforzar DMARC hacia p=quarantine o p=reject: mientras tu política DMARC sea p=none, los indicadores 1, 2 y 3 siguen siendo explotables sin consecuencia para el atacante. Recordemos que solo el 4% de los dominios aplican p=reject (Valimail, 2025): cada dominio que migra reduce la superficie de ataque para todo el ecosistema. Usa nuestra herramienta de verificación DMARC (enlace en el banner de arriba) para auditar tu política actual.
4. Formar a los equipos SOC en las señales de alerta de cabeceras: los empleados formados reportan cuatro veces más amenazas que los no formados, un 21% frente a un 5% (Verizon DBIR, 2025). Los 10 indicadores de este artículo deberían formar parte del procedimiento estándar de análisis de incidentes email. Crea una lista de control imprimible que los analistas consulten durante cada investigación.
5. Integrar el análisis de cabeceras en el proceso de respuesta a incidentes: las organizaciones que integran IA en su pipeline de seguridad reducen el ciclo de brecha en 80 días y ahorran en promedio 1,9 millones de dólares por incidente (IBM, Cost of a Data Breach 2025). Cada email sospechoso reportado debe pasar por un análisis post-pasarela sistemático antes de ser clasificado como falso positivo.
6. Re-testear mensualmente con emails de prueba: enviate emails que reproduzcan cada uno de los 10 indicadores. Si tu pasarela los deja pasar y tus reglas de transporte no los señalan, tus defensas tienen un angulo muerto.

FAQ

¿Por qué mi pasarela email no detecta estas señales?

Las pasarelas están optimizadas para el filtrado masivo: reputación IP, contenido sospechoso, firmas malware. Los 10 indicadores descritos aquí corresponden a la coherencia de las cabeceras, un ámbito que las pasarelas no analizan en profundidad. El desfase Return-Path/From o la ausencia de cabeceras propietarias no son criterios de filtrado estándar en la mayoría de los SEG del mercado.

¿Qué filtros email son los más vulnerables a estos eludimientos?

Las pasarelas que se concentran exclusivamente en la reputación IP y el análisis de contenido son las más vulnerables. Las soluciones que integran análisis comportamental y verificación de alineamiento DMARC están mejor posicionadas, pero ninguna pasarela del mercado verifica los 10 indicadores de manera exhaustiva. Por eso el análisis post-pasarela sigue siendo necesario.

¿Cómo crear una regla de transporte Exchange para detectar el desfase Reply-To?

En el Exchange Admin Center, crea una regla de flujo de correo con la condición "Un encabezado de mensaje incluye" sobre el encabezado Reply-To. Combina con la condición "El dominio del remitente es" para apuntar a los dominios internos. La acción recomendada es añadir una advertencia visible al destinatario y marcar el mensaje para revisión SOC. Prueba en modo auditoría durante dos semanas antes de activar el bloqueo.

¿El análisis de cabeceras puede automatizarse?

Si. Los resultados de autenticación y las cabeceras clave son accesibles en los logs de transporte Exchange Online y Gmail. Un SIEM (Sentinel, Splunk, Elastic) puede ingerir estos logs y aplicar reglas de detección sobre los 10 indicadores. Para las organizaciones sin SIEM, las reglas de transporte Exchange/Gmail ofrecen un primer nivel de automatización accesible.

¿Estas técnicas de eludimiento funcionan contra Gmail y Outlook nativos?

Gmail y Outlook disponen de sus propias capas de filtrado (Gmail usa modelos ML avanzados, Outlook integra Defender). Estos filtros son mejores que la media en el alineamiento DMARC y la detección de Reply-To sospechoso. Pero no son infalibles: los indicadores 5 (cadena Received anormal), 7 (X-Mailer sospechoso), 8 (Message-ID incoherente) y 10 (archivo adjunto HTML) siguen siendo angulos muertos incluso para estas plataformas.

¿Cómo formar a mi equipo SOC en el análisis de cabeceras?

Comienza con un taller práctico de 2 horas con emails reales (anonimizados) que presenten cada uno de los 10 indicadores. Crea una lista de control imprimible que los analistas consulten durante cada investigación. Integra el análisis de cabeceras en los ejercicios de simulación de mesa y las simulaciones de phishing internas. El objetivo es que cada analista SOC pueda identificar los 10 indicadores en menos de 5 minutos por email.

¿Hay que reemplazar mi pasarela email para protegerse?

No. Los 10 indicadores son complementos a la pasarela, no sustitutos. La pasarela sigue siendo indispensable para bloquear el spam masivo, los malwares conocidos y las campañas de phishing genéricas. El objetivo es añadir una capa de detección post-pasarela (reglas de transporte, análisis SOC, SIEM) dirigida a los ataques sofisticados que el filtrado estándar no capta.

¿Cómo probar si mi pasarela pasa por alto estas señales?

Enviate emails de prueba reproduciendo cada uno de los 10 indicadores desde un servidor externo. Para el desfase Return-Path: configura un MAIL FROM diferente del From. Para el DKIM de terceros: firma con un dominio diferente. Para el Reply-To: inserta un Reply-To hacia un dominio externo. Documenta que emails superan la pasarela y cuales son bloqueados. Esta prueba revela los angulos muertos específicos de tu configuración.

Glosario

• Return-Path: cabecera insertada por el servidor de recepción que contiene la dirección del sobre SMTP (MAIL FROM). Usada para las notificaciones de no entrega (rebotes). Verificada por SPF.
• DKIM-Signature: cabecera que contiene la firma criptográfica de un mensaje. El campo d= identifica el dominio firmante, s= el selector de la clave pública.
• Alineamiento DMARC: verificación de que el dominio del From corresponde al dominio verificado por SPF (alineamiento SPF) o al dominio firmante DKIM (alineamiento DKIM). El alineamiento puede ser estricto (correspondencia exacta) o relajado (correspondencia sobre el dominio organizacional).
• Reply-To: cabecera opcional que indica la dirección hacia la cual deben dirigirse las respuestas. Puede diferir del From.
• Cadena Received: serie de cabeceras añadidas por cada servidor (salto) que ha procesado el mensaje. Leidas de arriba a abajo, trazan el recorrido del mensaje desde el último salto (arriba) al primero (abajo).
• STARTTLS: extensión SMTP que permite iniciar una conexión cifrada TLS sobre una conexión SMTP existente. Visible en las cabeceras Received por la mención with ESMTPS.
• X-Mailer: cabecera opcional que identifica el software cliente usado para enviar el mensaje. No estandarizada por las RFC, pero ampliamente usada por los clientes de correo.
• Message-ID: identificador único asignado a cada mensaje por el servidor de envío. Formato: <identificador@dominio>. Usado para el encadenamiento de conversaciones y la deduplicación.
• MIME (Multipurpose Internet Mail Extensions): estándar de codificación de emails que permite los archivos adjuntos, el contenido HTML y los caracteres no ASCII. Definido por la cabecera Content-Type.
• Content-Disposition: cabecera MIME que indica si una parte del mensaje debe mostrarse en línea (inline) o proponerse para descarga (attachment).
• Remitente de sobre (envelope sender): dirección SMTP usada durante el comando MAIL FROM en la sesión SMTP. Distinta de la dirección en la cabecera From visible por el destinatario.

---

¿Tus cabeceras esconden señales sospechosas? Pega tus cabeceras brutas en nuestro analizador de cabeceras email para un diagnóstico automático que cubre la autenticación, el enrutamiento y las anomalías descritas en este artículo.

---

Fuentes

• RFC 5322 - Internet Message Format
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures
• RFC 7208 - Sender Policy Framework (SPF)
• Microsoft - Enhanced Filtering for Connectors in Exchange Online
• MITRE ATT&CK T1566 - Phishing