Leer las cabeceras: ¿de dónde venía este correo?

Módulo 1: Cómo funciona el correo electrónico · Tiempo de lectura: 11 minutos

Objetivo de aprendizaje: Después de esta lección podrá abrir las cabeceras de un correo, leer las líneas Received en el orden correcto y deducir de Authentication-Results si SPF, DKIM y DMARC fueron correctos.

Conceptos clave: cabeceras (headers), RFC 5322, Received, Return-Path, From, Reply-To, Message-ID, DKIM-Signature (d=, s=), Authentication-Results, ARC, cabeceras X, origen o mensaje original

Lo que normalmente no ve

Su programa de correo le muestra de un mensaje solo unas pocas líneas: remitente, asunto, fecha, destinatarios. En realidad, cada correo tiene decenas de cabeceras (headers) en la parte superior, antes del texto. Las añade el programa del remitente y cada servidor que toca el correo durante su trayecto. Juntas forman el relato del viaje del correo.

Quien sabe leer las cabeceras puede responder muchas preguntas por su cuenta: ¿es este correo realmente de mi banco? ¿Por qué llegó dos horas tarde? ¿Por qué acabó en spam? ¿Es correcto mi propio DKIM? Muchos ejercicios de este curso le pedirán examinar cabeceras. En esta lección aprenderá cómo hacerlo.

Abrir las cabeceras

Cada programa tiene su propio botón para ello:

En un teléfono normalmente no es posible. En ese caso, reenvíese el correo a usted mismo como archivo adjunto, o ábralo en el webmail.

Un ejemplo

Juan recibe un correo de Ana. Así se ven las cabeceras más importantes (abreviadas):

Return-Path: <anna@example.com>
Delivered-To: jan@example.net
Received: from mx1.mailprovider.example (localhost [127.0.0.1])
        by mailbox3.mailprovider.example with LMTP; Sun, 08 Nov 2026 10:15:09 +0100
Received: from out.hosting.example (out.hosting.example [192.0.2.25])
        by mx1.mailprovider.example with ESMTPS id 4F2A1B
        for <jan@example.net>; Sun, 08 Nov 2026 10:15:07 +0100
Received: from [198.51.100.77] (helo=[10.0.0.12])
        by out.hosting.example with ESMTPSA (TLS1.3)
        (authenticated as anna@example.com); Sun, 08 Nov 2026 10:15:04 +0100
Authentication-Results: mx1.mailprovider.example;
        spf=pass smtp.mailfrom=example.com;
        dkim=pass header.d=example.com header.s=x;
        dmarc=pass header.from=example.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=x;
        h=From:To:Subject:Date:Message-ID; bh=...; b=...
From: Anna <anna@example.com>
To: Jan <jan@example.net>
Subject: Offerte
Date: Sun, 8 Nov 2026 10:15:00 +0100
Message-ID: <a1b2c3@example.com>

Líneas Received: de abajo hacia arriba

Cada servidor que transmite el correo añade una línea Received: arriba del todo. La más antigua queda, por tanto, abajo, y la más reciente arriba. Léalas de abajo hacia arriba para seguir el recorrido:

1. Línea inferior: el portátil de Ana (IP 198.51.100.77, su conexión de casa) entrega el correo a out.hosting.example, con ESMTPSA (la A significa authenticated: ella inició sesión) y TLS 1.3. A las 10:15:04.
2. Línea del medio: out.hosting.example (192.0.2.25) entrega el correo a mx1.mailprovider.example, el MX de example.net. A las 10:15:07.
3. Línea superior: el servidor de correo coloca el mensaje internamente en el buzón de Juan (LMTP). A las 10:15:09.

Una línea Received siempre tiene la forma from <quien lo ofreció> by <quien lo recibió> with <protocolo>; <hora>. Entre paréntesis después de from figura lo que el servidor receptor vio por sí mismo: el nombre real (PTR) y la dirección IP real. Esa parte es fiable en la medida en que confíe en ese servidor receptor. Lo que el propio remitente declaró (helo=) no se puede verificar.

Dos trucos prácticos:

• Buscar retrasos: compare las horas. Si hay dos horas entre dos líneas, el correo ha estado ese tiempo en una cola. Preste atención a las zonas horarias (+0100, +0000).
• Encontrar el servidor remitente real: busque la línea Received más alta que haya sido escrita por un servidor del propio destinatario, y vea qué aparece ahí tras from. Todo lo que esté por debajo lo ha escrito la parte emisora y, en teoría, podría estar inventado. En el ejemplo, 192.0.2.25 es el servidor que entregó el correo al destinatario; es sobre ese servidor donde se evalúan el SPF y la reputación.

Las direcciones

Un truco conocido de los estafadores: un From que se parece al de su banco, con un Reply-To hacia una dirección completamente distinta. Si tiene dudas, mire siempre el dominio en From y en Return-Path, y en Authentication-Results.

Authentication-Results: el veredicto del receptor

El servidor receptor coloca en Authentication-Results (RFC 8601) el resultado de sus comprobaciones:

• spf=pass smtp.mailfrom=example.com: la IP del servidor que hizo la entrega figura en el registro SPF del dominio de Return-Path.
• dkim=pass header.d=example.com header.s=x: la firma DKIM del dominio example.com, con la clave (selector) x, es correcta.
• dmarc=pass header.from=example.com: el dominio de From está alineado con un SPF o DKIM correcto, por lo que DMARC es correcto.

Otros resultados que puede ver: fail (incorrecto), softfail (SPF termina en ~all y la IP no figura en el registro), neutral, none (sin registro), temperror (error temporal de DNS) y permerror (registro roto, por ejemplo dos registros SPF). Qué significan exactamente y cómo solucionarlos se explica en el módulo 4.

Tenga en cuenta: confíe únicamente en el Authentication-Results del propio servidor receptor (el nombre al principio, aquí mx1.mailprovider.example). Un correo falsificado puede incluir su propio Authentication-Results inventado. Los buenos servidores lo eliminan, pero no todos lo hacen.

DKIM-Signature: la firma

La cabecera DKIM-Signature es la firma en sí. Suele necesitar dos campos:

• d= el dominio que firma (aquí example.com);
• s= el selector, el nombre de la clave (aquí x).

Con esto encuentra la clave pública en el DNS: x._domainkey.example.com. En los ejercicios y al resolver problemas, a menudo tendrá que buscar exactamente estos dos valores. Un correo puede tener varias firmas DKIM, por ejemplo una de su propio dominio y otra del servicio de envío. En la lección 4.3 profundizaremos en esto.

A veces también verá ARC-Seal, ARC-Message-Signature y ARC-Authentication-Results. ARC (RFC 8617) es un mecanismo con el que las estaciones intermedias, como una lista de distribución o un servidor de reenvío, dejan constancia de cuáles fueron las comprobaciones antes de modificar el correo. Por ahora no necesita saber leerlas.

Cabeceras X

Las cabeceras que empiezan por X- no están estandarizadas. Los filtros antispam colocan ahí su puntuación, como X-Spam-Status: No, score=1.2 o X-Spam-Flag: YES. Esto ayuda a entender por qué algo acabó en spam. Varían según el proveedor.

Resumen

• Las cabeceras son el relato del viaje de un correo. Ábralas con "mostrar original", "código fuente del mensaje" o algo similar.
• Lea las líneas Received de abajo hacia arriba. La línea escrita por el servidor del receptor indica qué IP hizo la entrega.
• Return-Path es el remitente del sobre (SPF), From es el remitente visible (DMARC), Reply-To indica adónde van las respuestas.
• Authentication-Results da el veredicto sobre SPF, DKIM y DMARC; confíe solo en el del servidor receptor.
• En DKIM-Signature figuran d= (dominio) y s= (selector); juntos indican la ubicación de la clave: s._domainkey.d.

Cuestionario

Ejercicio

Ejercicio Z1.5: Encontrar el primer servidor de correo. Envíese un correo desde otra dirección (por ejemplo, de su dirección del trabajo a su dirección personal, o al revés), abra las cabeceras y péguelas en el formulario. Si no dispone de una segunda dirección, use el archivo de ejemplo kopregels-1.txt que acompaña al ejercicio. A continuación, complete usted mismo: la dirección IP del servidor que hizo la entrega al destinatario, el dominio en Return-Path, el dominio y el selector de la firma DKIM, y el resultado de SPF, DKIM y DMARC. El programa analiza las mismas cabeceras, busca la clave DKIM en tiempo real y compara su resultado con el suyo. Sus cabeceras no se conservan.

Para seguir leyendo

Los pasos de estos artículos son válidos para los paneles de WebOké; en otros proveedores el funcionamiento es similar.

• Comprobar si un correo ha llegado con el seguimiento de correo de DirectAdmin
• Manual de DirectAdmin 9.3: Seguimiento de E-Mail: ¿dónde ha ido a parar mi correo?
• ¿Es realmente este correo de WebOké? Cómo reconocer el phishing y utilizar el código de promoción
• Curso gratuito de DNS 4.4: DKIM: la firma de su correo
• RFC 5322 (estructura de un correo), RFC 8601 (Authentication-Results), RFC 6376 (DKIM), RFC 8617 (ARC)