Cómo leer las cabeceras de un correo para cazar phishing

El nombre que ves en el campo De: es texto libre que escribe quien envía el correo. No lo verifica nadie. El remitente real —qué servidor lo entregó, desde qué IP, qué dominio firmó el mensaje— vive en las cabeceras, la parte del correo que tu cliente esconde por defecto. Aprender a leerlas es la diferencia entre creerte un "Banco Nacional" escrito a mano y ver que el mensaje salió de un servidor doméstico en otro continente. Puedes analizar las cabeceras de un correo con la herramienta local de Docuboxer, que las interpreta en tu navegador sin subir nada.

El campo "De:" es una etiqueta, no una identidad

El correo electrónico funciona como el correo postal: hay un sobre y hay una carta. El sobre lo maneja el protocolo SMTP y lleva su propio remitente (lo que acabará apareciendo como Return-Path). La carta es el mensaje, y el From: que lees es una línea escrita dentro de la carta. Nada obliga a que coincidan. Un atacante controla las dos, y el estándar no exige que un servidor rechace la incoherencia.

A esto se suma un detalle de diseño de los clientes de correo: casi todos muestran solo el display name y esconden la dirección, sobre todo en móvil. Por eso funciona tan bien el truco más barato del phishing, poner como nombre visible Soporte Banco Nacional con una dirección detrás de un dominio gratuito cualquiera. En pantalla pequeña, la dirección ni aparece.

Cómo sacar las cabeceras completas

• Gmail (web): menú de tres puntos del mensaje → Mostrar original. Ahí ves todo y puedes descargar el mensaje original.
• Outlook escritorio: abre el mensaje → Archivo → Propiedades → cuadro Encabezados de Internet. En la versión web, el menú de tres puntos ofrece ver el origen del mensaje.
• Apple Mail: Visualización → Mensaje → Todas las cabeceras.
• Thunderbird: Ctrl+U muestra el código fuente completo.

Un aviso práctico que ahorra frustraciones: no reenvíes el correo para analizarlo. Al reenviar, tu propio servidor genera un mensaje nuevo con cabeceras nuevas y el original queda reducido a texto citado. Se pierde exactamente lo que necesitas. Usa "Mostrar original", guarda el .eml o adjunta el mensaje como archivo.

La cadena Received se lee de abajo hacia arriba

Cada servidor por el que pasa el mensaje añade una línea Received: arriba del todo. El resultado es una pila invertida: la de arriba la puso tu proveedor al entregarte el correo, y la de más abajo corresponde al primer salto, el origen. Leerla al revés, de abajo hacia arriba, reconstruye el viaje.

Lo que buscas en el tramo inferior es la IP y el nombre del servidor de origen, y si encajan con la infraestructura del dominio que dice enviar. Un correo supuestamente de una entidad financiera que arranca en una IP residencial, en un servidor virtual barato o en un país sin relación con la marca es una señal fuerte. Las marcas de tiempo también hablan: saltos de horas entre saltos consecutivos o zonas horarias que no cuadran con la ruta.

Y aquí la parte honesta: un atacante puede inventarse líneas Received y meterlas en el mensaje antes de enviarlo. Solo son fiables las que añadieron los servidores por los que pasó de verdad, es decir, las de arriba. Si lees de arriba hacia abajo y llega un punto donde la cadena deja de encajar, ese punto suele marcar la frontera entre lo real y lo inventado.

Authentication-Results: la línea que de verdad importa

Tu proveedor de correo comprueba la autenticación al recibir el mensaje y escribe el veredicto en una cabecera Authentication-Results. Es la línea más valiosa del conjunto porque no la escribió el remitente, sino quien te lo entregó. Suele verse algo así como spf=pass smtp.mailfrom=ejemplo.com; dkim=pass header.d=ejemplo.com; dmarc=pass header.from=ejemplo.com. En corto:

• SPF comprueba que la IP que envió está autorizada por el dominio del sobre (el Return-Path), no por el que tú lees.
• DKIM verifica una firma criptográfica; el dominio que firma aparece como header.d=.
• DMARC exige que el dominio del From: visible coincida con el de SPF o el de DKIM. Es la única de las tres que ata el resultado al remitente que ve el usuario.

Cuidado con un detalle: un mensaje puede traer varias cabeceras Authentication-Results, y el atacante puede incluir la suya con un pass inventado. Solo cuenta la que lleva el identificador de tu propio proveedor. Si quieres saber qué publica realmente un dominio, consúltalo con el verificador de SPF, DKIM y DMARC; y si te interesa el lado emisor, el tema está desarrollado en la guía sobre SPF, DKIM y DMARC y por qué tus correos acaban en spam.

Un "pass" no significa legítimo

Este es el punto que casi ninguna guía dice con claridad. Pasar SPF, DKIM y DMARC demuestra que el correo salió de verdad del dominio que dice, y nada más. Los atacantes registran sus propios dominios, publican sus registros SPF, firman con DKIM y configuran DMARC exactamente como manda el manual. Sus correos obtienen tres pass limpios. Autenticado no es sinónimo de honrado: certifica el emisor, no sus intenciones.

Al revés también pasa. Un correo perfectamente legítimo puede fallar SPF por el simple hecho de haber sido reenviado por una lista de distribución o una regla automática, porque el servidor que lo entrega ya no es el autorizado en origen. Un fail pide atención, no pánico.

Y el caso peor no lo detecta ninguna cabecera: una cuenta real comprometida. Si un atacante entra en el buzón de un proveedor tuyo y escribe desde ahí pidiendo un cambio de número de cuenta, la autenticación es genuina, la cadena Received es impecable y el fraude también. Las cabeceras describen el transporte, nunca la intención.

Las incoherencias que sí delatan

Lo que rara vez sobrevive a un correo fraudulento no es la autenticación: es la coherencia. El correo corporativo real es aburrido y consistente. Estas son las grietas típicas:

• Reply-To distinto del From, con un dominio sin relación. Tu respuesta va al atacante.
• Return-Path apuntando a un dominio que no tiene nada que ver con la marca del From:.
• DKIM firmado (header.d=) por un dominio ajeno al proveedor de correo que la empresa usa habitualmente.
• Display name con nombre de marca y dirección en un dominio genérico o recién registrado.
• Dominio casi idéntico: un guion de más, una letra cambiada, caracteres de otro alfabeto que se ven igual. Ese mismo análisis aplicado a los enlaces del cuerpo lo hace el inspector de enlaces.
• Received desde una geografía incompatible con la operación de la empresa.
• Cabeceras de envío masivo (X-Mailer, plataformas de campañas) en lo que se presenta como un mensaje personal escrito a mano.

Repaso de 60 segundos

1. Abre el original y mira la dirección completa del From:, no el nombre visible.
2. Busca el Authentication-Results de tu proveedor y lee los tres veredictos.
3. Compara los dominios de From, Reply-To, Return-Path y header.d=. ¿Cuentan la misma historia?
4. Baja al final de la cadena Received y mira de dónde arrancó.
5. Pasa los enlaces del cuerpo por un inspector antes de abrirlos.
6. Ante la duda, verifica por un canal que tú elijas: un teléfono que ya tenías, no el del correo.

Por qué conviene analizarlas en local

Unas cabeceras completas son metadatos jugosos: tu dirección, las IP por las que pasó, identificadores únicos de mensaje y, en entornos corporativos, nombres de servidores internos que revelan cómo está montada la red de tu empresa. Pegar todo eso en un analizador web cualquiera es entregar ese mapa a un tercero. El analizador de cabeceras de Docuboxer hace el parseo íntegramente en tu navegador: el texto no viaja a ningún sitio. Y si ya habías introducido tus credenciales en el sitio del correo antes de sospechar, comprueba cuanto antes si esa clave está expuesta con el verificador de contraseñas filtradas y cámbiala en todos los servicios donde la repitieras.

Preguntas frecuentes

Herramientas relacionadas

• Analizar cabeceras de un correo — Cadena Received, SPF/DKIM/DMARC y Reply-To, en local.
• Verificar SPF, DKIM y DMARC — Qué publica de verdad un dominio en su DNS.
• Analizar si un enlace es seguro — Revisa los enlaces del cuerpo sin abrirlos.
• Verificar si tu contraseña está filtrada — Por si llegaste a escribirla donde no debías.

También te puede interesar: códigos QR maliciosos y cómo reconocerlos, la variante del mismo engaño que llega impresa en papel.