Guías · Correo y dominios

Cómo leer las cabeceras de un correo y detectar el phishing

Escrito por Aldo · threat hunter en un blue team
Última actualización: 9 de noviembre de 2026 · 5 min de lectura

Un correo dice venir de tu banco, de tu jefa o de un proveedor. La línea From visible es solo texto que escribió el remitente. Las cabeceras de debajo registran lo que vieron de verdad los servidores de correo, y son mucho más difíciles de falsificar.

Abre las cabeceras completas

Todos los programas de correo las ocultan por defecto. Aquí están (los nombres de los menús cambian entre versiones, pero estos llevan tiempo estables):

• Gmail (web): abre el correo, haz clic en los tres puntos junto a Responder y luego en Mostrar original.
• Outlook en la web y el nuevo Outlook: abre el correo, selecciona los tres puntos y luego Ver → Ver detalles del mensaje.
• Outlook clásico para Windows: abre el correo en su propia ventana y luego Archivo → Propiedades; las cabeceras están en Encabezados de Internet.
• Mail de Apple en Mac: Visualización → Mensaje → Todas las cabeceras.
• Thunderbird: Ver → Código fuente del mensaje (Ctrl+U).
• Las apps de correo de iPhone y Android normalmente no muestran las cabeceras completas. Abre el mismo buzón en un ordenador.

Copia todo desde arriba hasta la primera línea en blanco. Ese bloque es la cabecera.

Un ejemplo real: la factura vencida

Este es el ejemplo del analizador de cabeceras de iplover. Los dominios son de documentación (example.com, .org, .net) y la dirección de envío es un nodo de salida de Tor público, así que no hay ninguna empresa ni persona real implicada, pero cada línea es de las que te encontrarás en un phishing real:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.org header.s=s1 header.b=Xy12;
       spf=pass (google.com: domain of bounce@mailer.example.org designates 198.51.100.25 as permitted sender) smtp.mailfrom=bounce@mailer.example.org;
       dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=example.com
Return-Path: <bounce@mailer.example.org>
Received: from relay.mailer.example.org (relay.mailer.example.org. [198.51.100.25])
        by mx.google.com with ESMTPS id 5a1b2c3d4e
        for <you@example.net>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 03 Nov 2026 10:14:04 -0800 (PST)
Received: from webmail.example.org (unknown [185.220.101.7])
        by relay.mailer.example.org (Postfix) with ESMTPSA id 7C1A2B3;
        Tue,  3 Nov 2026 16:11:58 +0000 (UTC)
Received: from [10.0.0.12] (localhost [127.0.0.1])
        by webmail.example.org with ESMTP;
        Tue,  3 Nov 2026 16:11:55 +0000 (UTC)
From: "Example Billing" <billing@example.com>
Reply-To: payments-desk@example.net
Subject: Invoice 4471 is overdue
Message-ID: <20261103161152.4471@mailer.example.org>
X-Originating-IP: [185.220.101.7]

(Acortado; el ejemplo completo incluye también cabeceras ARC, que registran los controles hechos por los servidores del camino.) El veredicto del analizador:

Cómo leerla, línea a línea

1. Authentication-Results: el veredicto del servidor que recibe

El servidor que recibió el mensaje (aquí el de Google) lo comprobó y anotó los resultados. Lee la línea Authentication-Results de más arriba: es la que añadió tu propio proveedor de correo. Cualquier línea más abajo podría haberla escrito cualquiera, incluido el remitente.

El truco de este ejemplo es que SPF y DKIM pasaron los dos, pero no para el dominio correcto. SPF pasó para mailer.example.org y DKIM para example.org, pero la dirección From dice example.com. DMARC es el control que ata el resultado al dominio del From, y falló. El dueño de example.com incluso había publicado una política pidiendo rechazar estos correos. Este patrón, todo correcto menos DMARC, es la cara típica del correo falsificado.

2. From, Reply-To y Return-Path: quién dice ser, y adónde van las respuestas

La línea From muestra «Example Billing» en example.com. Reply-To, en cambio, manda tu respuesta a example.net. Los servicios de atención y las listas de correo lo hacen legítimamente, pero en una factura inesperada significa: quien la escribió quiere tu respuesta en un sitio que la empresa real no controla. Return-Path es adonde van los rebotes; ahí lo normal es el dominio de un servicio de envíos.

3. Received: el recorrido de entrega, leído de abajo arriba

Cada servidor que maneja un mensaje añade una línea Received arriba del todo, así que la más antigua está abajo. Lee hacia arriba: un dispositivo en una red privada (10.0.0.12) pasó el correo al webmail, que lo recibió de 185.220.101.7, un nodo de salida de Tor, antes de pasarlo al relé y luego a Google. Esa primera dirección pública es lo más cerca del remitente que vas a llegar, y aquí es anónima a propósito. X-Originating-IP, que añaden algunos servicios de webmail, dice lo mismo.

Las horas también cuentan algo: dos horas entre el relé y Google. Los retrasos ocurren por motivos inocentes, pero merece la pena fijarse.

Si ves esto, haz esto

Lo que las cabeceras no pueden decirte

Las cabeceras demuestran de dónde vino un mensaje, no lo que quiere. Un mensaje desde una cuenta real pero hackeada pasa todos los controles. Un dominio imitador pasa DMARC para sí mismo. Y las cabeceras no dicen nada del enlace ni del adjunto, que es donde suele estar el daño. Así que son una prueba entre varias: una petición inesperada de dinero, contraseñas o decisiones rápidas merece sospecha digan lo que digan las cabeceras.

El analizador de iplover lee los resultados que anotó tu proveedor; no vuelve a verificar las firmas DKIM ni descarga los registros SPF de cada salto. Lo dice al final de cada informe, y conviene tenerlo presente con cualquier herramienta.