Qué es en realidad el bloque de cabecera
Todo mensaje son dos cosas separadas por una línea en blanco: un bloque de líneas Nombre: valor, y el texto que lees. El RFC 5322 llama cabecera a la primera parte y campo a cada línea que contiene, y no pone límite a cuántas puede haber. Tu aplicación de correo te muestra cuatro o cinco. Un mensaje que ha cruzado tres servidores suele llevar entre treinta y sesenta.
Return-Path: <bounces+2841@mail.example.com>
Delivered-To: signup-2026@example.org
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
by mx.example.org (Postfix) with ESMTPS id 9a31b0
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Authentication-Results: mx.example.org;
spf=pass smtp.mailfrom=mail.example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.com
From: "Example Support" <support@example.com>
To: signup-2026@example.org
Subject: Confirm your email address
Date: Fri, 5 Sep 2026 09:14:19 +0000
Message-ID: <20260905091419.9a31b0@mail.example.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_4c8f21"Leído de arriba abajo parece ruido de máquina, y en su mayor parte lo es. Cuatro campos llevan casi toda la información, y son los cuatro de los que trata esta guía: Received, From, Return-Path y Authentication-Results.
Dónde se esconde la cabecera completa
Nada de lo que sigue necesita una herramienta, una extensión ni una cuenta. Todo cliente de correo guarda el mensaje en bruto detrás de un elemento de menú, y la palabra que hay que buscar es siempre alguna forma de fuente, original o sin formato.
| Dónde lees tu correo | Qué abrir | Qué obtienes |
|---|---|---|
| Gmail, en un navegador | El menú de tres puntos de un mensaje abierto → Mostrar original | El bloque completo, encima de un panel de resumen que ya te ha evaluado SPF, DKIM y DMARC |
| Outlook.com, en un navegador | El menú de tres puntos → Ver → Ver origen del mensaje | El mensaje completo tal como llegó, en texto plano |
| La aplicación de escritorio de Outlook | Abre el mensaje en su propia ventana → Archivo → Propiedades | Solo el bloque de cabecera, en el cuadro de la parte inferior del diálogo |
| Apple Mail, en un Mac | Visualización → Mensaje → Fuente sin formato | Cabecera y cuerpo juntos, en una ventana propia |
| Thunderbird, en cualquier sistema | Ver → Código fuente del mensaje | El mensaje completo, con el bloque de cabecera al principio |
| Proton Mail, en un navegador | El menú de tres puntos de un mensaje → View headers | El bloque de cabecera solo, sin el cuerpo |
| Yahoo Mail, en un navegador | Más → Ver mensaje sin formato | El mensaje completo, exactamente como se entregó |
| Un archivo que te envió alguien, o uno que exportaste tú | Abre el .eml en cualquier editor de texto | Todo, porque un .eml no es más que un bloque de cabecera y un cuerpo |
Esas rutas de menú son las que había el 5 de septiembre de 2026, y se mueven más o menos una vez al año, por lo que la frase de arriba importa más que la tabla: se llame como se llame el elemento esta temporada, tendrá fuente, original o sin formato en el nombre.
La cadena de Received, leída desde abajo
Cada servidor que acepta el mensaje escribe una línea Received: y la coloca arriba del todo del bloque, por encima de todo lo que ya había. Esa única costumbre produce el dato más útil que hay sobre las cabeceras: el último salto es la primera línea que ves, y el trayecto del mensaje queda escrito al revés.
Received: by mx.example.org (Postfix) with LMTP id 4c8f21
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:22 +0000 (UTC)
Received: from out-17.mail.example.com (out-17.mail.example.com [198.51.100.17])
by mx.example.org (Postfix) with ESMTPS id 9a31b0
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:14:21 +0000 (UTC)
Received: from app-3.internal (app-3.internal [192.0.2.53])
by out-17.mail.example.com (Postfix) with ESMTP id 771c4e
for <signup-2026@example.org>; Fri, 5 Sep 2026 09:11:58 +0000 (UTC)Cada línea está construida con el mismo puñado de palabras, y en cuanto sabes nombrarlas la cadena deja de ser papel pintado.
from- Cómo se llamó a sí misma la máquina que se conectó, seguido entre corchetes de lo que realmente era — el nombre de DNS inverso y la dirección IP que vio el servidor receptor en la conexión. El nombre antes de los corchetes es una afirmación. La dirección de dentro fue observada.
by- El servidor que escribió esta línea. Es la única parte de la línea de la que puedes responsabilizar a alguien.
with- Cómo se hizo el salto:
ESMTP,ESMTPScuando la conexión iba cifrada,LMTPpara la entrega final a un buzón. Un salto que diceESMTPsin laSllevó el mensaje sin cifrar. for- El destinatario del sobre en ese salto — a cuál de tus direcciones se envió realmente el mensaje, antes de que ninguna regla de reenvío reescribiera nada. En un dominio catch-all o con una etiqueta con signo más, este es el campo que nombra la dirección que se filtró.
- la marca de tiempo al final
- Cuándo terminó ese servidor de aceptar el mensaje. Resta la hora de una línea a la de la línea de encima y obtienes el retraso en ese salto, que es cómo averiguas dónde estuvo parado en realidad un mensaje lento, en lugar de adivinarlo.
En el ejemplo de arriba, el mensaje salió de la aplicación a las 09:11:58 y llegó al servidor de salida del proveedor remitente dos minutos y veintitrés segundos después; los dos saltos siguientes tardaron un segundo entre ambos. Un mensaje que llega con una hora de retraso casi siempre tiene una línea con una hora dentro, y casi nunca es la última.
Cuatro campos que afirman ser el remitente
«Quién envió esto» tiene cuatro respuestas en una cabecera, y se les permite no coincidir. La mayoría de las veces no coinciden por razones aburridas — una lista de correo, una plataforma de marketing, una regla de reenvío que configuraste tú mismo. Un desajuste no es prueba de nada. Saber cuál de los cuatro estás mirando, sí lo es.
From:- La dirección que el remitente quiere mostrar, más un nombre para mostrar que es texto libre. Nada verifica ninguno de los dos. Este es el campo que tu aplicación de correo pone en la lista de mensajes, y en un móvil la dirección suele quedar completamente oculta detrás del nombre.
Return-Path:- El remitente del sobre, escrito en la cabecera por el servidor que aceptó el mensaje, a partir de lo que realmente se dijo durante la conversación SMTP. Es adónde va un rebote, y es la dirección contra la que se comprueba SPF — que es exactamente por lo que un mensaje puede pasar SPF llevando un
From:que no tiene nada que ver con él. Reply-To:- Adónde se dirigirá tu respuesta, que no tiene por qué ser de donde vino el mensaje. Los remitentes normales lo usan para mesas de soporte y direcciones de no-respuesta. También es el truco más viejo del oficio, porque un lector cuidadoso comprueba el remitente, decide que está bien, y entonces pulsa Responder.
Delivered-To:yX-Original-To:- Cuál de tus direcciones se usó. En un dominio catch-all o con una etiqueta con signo más, este es el campo que nombra la dirección que realmente entregaste — la que identifica quién la dejó escapar.
From: "Example Support <support@example.com>" <billing@example.net>
^-- the display name, which is free text and is all a phone shows
^-- the address, which is notEl nombre para mostrar es texto arbitrario, así que puede contener una dirección completa que pertenezca a otra persona. Todo cliente de correo del mundo mostrará la parte entre comillas y ocultará la parte entre corchetes angulares, y ese es el ataque entero: no cuesta nada escribirlo y funciona sobre el único campo que un lector tiene garantizado mirar.
SPF, DKIM y DMARC, en una sola línea
Un campo es distinto de todos los demás campos del bloque. Authentication-Results: lo escribe el servidor que aceptó el mensaje — el tuyo — y cualquier cosa que llegue con el mismo nombre se elimina o se renombra antes de que la veas. Es la única línea de una cabecera que un impostor no puede escribir.
Authentication-Results: mx.example.org;
spf=pass (sender IP is 198.51.100.17) smtp.mailfrom=mail.example.com;
dkim=pass header.d=example.com header.s=s1 header.b=Qk3vR2mA;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comEn esa línea hay tres comprobaciones, y responden a tres preguntas distintas. La cuarta columna es la que merece leerse dos veces.
| Comprobación | Qué significa un pass | Qué suele significar un fail | Qué no prueba ninguno de los dos |
|---|---|---|---|
spf= | La máquina que entregó el mensaje está en la lista que el dominio del remitente del sobre publica en el DNS. | O un impostor, o un reenvío normal y corriente: SPF se rompe siempre que un tercero retransmite un mensaje, lo cual no es un fallo y pasa constantemente. | Nada sobre la dirección en From:. SPF nunca la mira. |
dkim= | Una firma criptográfica sobre el mensaje coincide con una clave pública publicada por el dominio firmante. | O el mensaje se alteró en tránsito — basta con que una lista de correo le añada un pie — o no lo firmó el dominio que dice. | Que el dominio firmante sea el dominio de From:. Cualquiera puede firmar perfectamente su propio correo. |
dmarc= | SPF o DKIM se validó y el dominio para el que se validó coincide con el dominio de From:. | El dominio de From: no autorizó este mensaje — lo más cerca que llega nunca una cabecera a decir que el remitente no es quien dice ser. | Que el mensaje sea seguro, honesto o deseado. Un dominio registrado esta mañana puede publicar un DMARC impecable antes de comer. |
Esa última columna es lo que importa de verdad, y es donde más se equivoca la mayoría al leer cabeceras. dmarc=pass prueba que el dominio impreso en From: autorizó el mensaje. No dice absolutamente nada sobre si ese dominio merece algo de ti — y publicar tú mismo los registros lleva unos diez minutos, para cualquiera.
Cinco cosas que una cabecera no puede decirte
- Dónde está el remitente. La dirección de la máquina en la que alguien redactó el mensaje normalmente no está en el bloque en absoluto. Los grandes proveedores de correo web dejaron de publicarla hace años, y lo que queda es su propio servidor de salida, que vive en un centro de datos y te dice el nombre de una empresa de hosting.
- Quién es el remitente. Un dominio no es una persona. Un
dmarc=passde un dominio comprado hace cuarenta minutos es un pass completamente genuino. - Si algo de eso es verdad. La autenticación trata sobre el sobre, nunca sobre la afirmación que hay dentro. Una factura puede estar correctamente firmada, correctamente alineada, y ser enteramente inventada.
- Si alguien lo leyó. Nada en una cabecera registra eso. Lo que lo intenta es un píxel de seguimiento en el cuerpo, que es un mecanismo distinto con defensas distintas.
- Cuándo se escribió.
Date:viene de la propia máquina del remitente y del propio reloj del remitente. Un mensaje fechado tres horas en el futuro es un ordenador mal configurado muchísimo más a menudo que otra cosa interesante; las marcas de tiempo de las que puedes fiarte están en las líneasReceivedque escribió tu proveedor.
Y toda una familia de campos no prueba nada, por construcción. Cualquier cosa que empiece por X- es una extensión privada inventada por quien la escribió, y un remitente puede escribir lo que le plazca: X-Spam-Status: No en un mensaje significa que el mensaje dice que no es spam.
Cuando el mensaje llegó a una dirección temporal
Conviene tener claro qué devuelve este servicio y qué no. Un mensaje leído aquí llega analizado y no en bruto: el remitente, el asunto, la fecha, el texto, el HTML y la lista de adjuntos — los campos a los que venía un script — y no el bloque de cabecera. La lectura de arriba es algo que haces en el buzón que guarda tu correo de verdad.
{
"id": "m_7Kq2fV3xTn",
"from": "support@example.com",
"from_name": "Example Support",
"to": "signup-2026@grabmail.io",
"subject": "Confirm your email address",
"date": "2026-09-05T09:14:22+00:00",
"expires_at": "2026-09-10T09:14:22+00:00",
"text": "Confirm your address: <https://example.com/confirm/9a31b0>",
"text_derived": true,
"html": "<!doctype html><html>…",
"attachments": []
}Lo que te da una dirección temporal en su lugar es una señal que ningún campo de cabecera puede igualar, y funciona antes de que leas una sola línea: le diste esa dirección exactamente a una sola parte. Un mensaje que llega a ella afirmando venir de otra persona, o bien lo reenvió la parte a la que se la diste, o lo envió quien sea a quien ella se la pasó. No hay una tercera explicación, y no hay nada que verificar.
Es el mismo argumento que hace una etiqueta con signo más, menos la parte en la que la etiqueta se puede cortar en una línea de código — aquí la dirección en sí es distinta, así que no hay nada que recortar. También es por lo que un catch-all en un dominio propio es la versión más fuerte de esto: una dirección por registro, conservada mientras conserves el dominio, y Delivered-To: en tu propio buzón nombra la que se filtró.
La comprobación que aún puedes hacer
Mira adónde va el enlace, no lo que dice. El campo text es o bien la parte de texto plano del propio remitente, o una conversión del HTML — text_derived dice cuál de las dos — y la conversión conserva todos los destinos de enlace entre corchetes angulares. Así que la dirección adonde te habría llevado un botón está ahí, en la respuesta, a la vista de todos, sin cargar la página, ni las imágenes, ni el píxel.
Confirm your address: <https://example.com/confirm/9a31b0>
Not you? Ignore this message. <https://example.com/help>La versión de sesenta segundos
- Abre la fuente. Mostrar original, Ver origen del mensaje o Fuente sin formato, según el cliente en el que estés.
- Busca primero
Authentication-Results. Una línea, escrita por tu propio proveedor, y la única que nadie más podría haber falsificado. Condmarc=pass, el dominio deFrom:sí autorizó el mensaje; condmarc=fail, no lo hizo. - Compara
From:conReturn-Path:yReply-To:. No coinciden por razones aburridas todo el día. También dejan de coincidir por la razón interesante. - Lee las líneas
Receivedde abajo hacia arriba, y deja de creértelas en la primera máquina que no sea la de tu proveedor. - Después mira adónde apuntan los enlaces, que es la parte que decide qué te pasa a ti en realidad.
Todo lo anterior responde a una pregunta estrecha: ¿autorizó este mensaje el dominio de From:? Es una pregunta más pequeña que «¿esto es seguro?», y aun así merece la pena responderla — es la única que una cabecera puede responder.
Preguntas
¿Cómo veo la cabecera completa en Gmail?
Abre el mensaje, luego el menú de tres puntos de su esquina superior derecha, y luego Mostrar original. Gmail abre una pestaña nueva con el mensaje en bruto y, encima, un pequeño panel que ya ha evaluado SPF, DKIM y DMARC — que es el veredicto más rápido que existe en ningún sitio, y es gratis.
¿Se puede falsificar una cabecera de correo?
Casi toda, sí. From:, Reply-To:, Date:, el asunto y cualquier número de líneas Received: inventadas los escribe todos el remitente. Lo que no se puede falsificar es lo que escribió tu propio proveedor cuando llegó el mensaje: la línea Received superior y Authentication-Results. Lee esas dos y trata el resto como testimonio.
¿Puedo encontrar la dirección IP del remitente en una cabecera?
Normalmente no la que buscas. El correo enviado a través de cualquier gran servicio de webmail lleva la dirección del servidor de salida de ese servicio, no la de la máquina en la que se redactó; los proveedores dejaron de publicar esta última hace años, por la razón obvia. El correo enviado por una aplicación o un servidor pequeño a menudo sí la sigue mostrando, entre corchetes, en la línea Received inferior — y esa línea es también la más fácil de falsificar de todo el bloque.
¿Cuál es la diferencia entre <code>From:</code> y <code>Return-Path:</code>?
From: es lo que el remitente quiere que se muestre, y nada lo comprueba. Return-Path: es el remitente del sobre que usaron realmente los servidores, escrito en la cabecera por la máquina que aceptó el mensaje, y es adónde van los rebotes. SPF se comprueba contra Return-Path:, nunca contra From:, que es por lo que spf=pass por sí solo dice menos de lo que parece. Hacer que los dos coincidan es todo el trabajo de DMARC.
La cabecera dice <code>dmarc=fail</code>. ¿Es el mensaje una falsificación?
No necesariamente. El reenvío rompe SPF por diseño, y una lista de correo que añade un pie rompe DKIM también, así que el correo retransmitido a través de una lista, una universidad o una regla de «envíalo todo a mi otra dirección» falla habitualmente sin dejar de ser completamente genuino. Lo que sí significa el fail es que nada en el mensaje prueba que el dominio de From: respalde su contenido, así que cualquier cosa que el mensaje te pida hacer merece una segunda vía de comprobación.
¿Para qué sirve <code>Message-ID</code>?
Es el nombre del mensaje — único, asignado por el servidor remitente, y la cadena a la que apuntan In-Reply-To y References para construir un hilo. Su utilidad práctica es que las mesas de soporte y los postmasters pueden buscarlo en sus registros: citar el Message-ID es la diferencia entre «ayer no me llegó un correo» y una pregunta que alguien puede responder de verdad.
¿Puedo leer las cabeceras del correo enviado aquí a una dirección temporal?
No — un mensaje leído aquí vuelve analizado, como remitente, asunto, fecha, texto, HTML y lista de adjuntos, y el bloque de cabecera en bruto no está entre esos campos. La compensación es que una dirección de un solo uso es su propia prueba: fue entregada a una sola parte, así que el correo que llega de cualquier otra persona señala a la parte que la dejó escapar, sin ninguna firma que verificar. Los mensajes se eliminan pasados 5 días de todas formas.
