Cómo se usa
- Abra el mensaje en su programa de correo, busque sus cabeceras originales o completas, y cópielas desde la primera línea hasta la línea en blanco.
- Péguelas en Cabeceras originales. La página las lee en su navegador.
- Lea Saltos en orden desde el primer salto hasta el último, y la columna Retraso para el tiempo de cada salto.
- Lea Resultado de SPF, Resultado de DKIM y Resultado de DMARC. Un resultado de superación aparece en verde; cualquier otro resultado, en rojo.
Cómo registra el correo su ruta
Cada servidor que maneja un mensaje añade una línea Received arriba de las cabeceras (RFC 5321, sección 4.4). La línea nombra el host del que recibió el correo (from), el host al que lo pasó (by), el protocolo (with) y una fecha después del punto y coma (RFC 5322, sección 3.6.7). Leídas desde abajo, las líneas dan la ruta en orden.
- El retraso de un salto es su hora menos la hora del salto anterior, leído de abajo arriba.
- El reloj de un servidor puede estar mal, así que un retraso negativo o largo dice tanto del reloj como de la red.
Direcciones y alineación
From es la dirección del autor. Return-Path es adónde van los rebotes, y es la dirección que comprueba SPF (RFC 5322, secciones 3.6.2 y 3.6.7). DMARC compara el dominio de From con el dominio que comprobó SPF o DKIM. Con la alineación relajada, la opción por defecto, basta con que los dos compartan un dominio organizativo; con la estricta, deben ser el mismo nombre (RFC 7489, secciones 3.1 y 3.1.1). Reply-To es adónde van las respuestas cuando está indicada (RFC 5322, sección 3.6.2).
Resultados de autenticación
Un servidor receptor anota sus comprobaciones en una cabecera Authentication-Results. Su primera palabra es el authserv-id de ese servidor, y cada resultado es un método con un valor, como spf=pass, dkim=pass o dmarc=pass (RFC 8601, secciones 2.2 y 2.7). Received-SPF es la cabecera antigua que anota una comprobación SPF (RFC 7208, sección 9.1).
Ejemplo: un mensaje que pasa por tres servidores
Las cabeceras por defecto muestran un mensaje desde client.example.net que pasó por relay.example.net y mx.example.org antes de llegar a mail.example.net. Leídas desde abajo, las tres líneas Received tienen hora 09:59:21, 10:00:03 y 10:02:14, así que el segundo salto tardó 42 segundos y el tercero 2 min 11 s.
La cabecera Authentication-Results anota spf=pass, dkim=pass y dmarc=pass para example.net. Las respuestas van a [email protected], otro dominio, que la página marca porque una respuesta que sale del dominio del remitente merece revisarse.
| Medida | Valor |
|---|---|
| Líneas Received | 3 |
| Tiempo del primer al último salto | 2 min 53 s |
| SPF | pass (example.net) |
| Reply-To | Las respuestas van a example.org, no a example.net. Compruebe que es lo previsto (RFC 5322, sección 3.6.2). |
Preguntas frecuentes
¿Por qué los saltos aparecen en orden inverso a las líneas Received?
Cada servidor pone su línea Received arriba, así que el salto más reciente va primero en las cabeceras (RFC 5321, sección 4.4). La página las invierte, de modo que la primera fila es el servidor desde el que salió el correo.
¿Puedo fiarme de las líneas Received?
Cada servidor escribe su propia línea, pero los nombres y las direcciones que contiene son los que informó ese servidor, y el remitente puede añadir líneas propias. Las líneas de arriba se añadieron más recientemente, por los servidores más cercanos a usted, y merecen la mayor atención.
¿Qué significa un retraso negativo?
Un salto con una hora anterior a la del salto previo indica que los relojes de dos servidores no coinciden, o que se leyó mal una zona horaria. Es señal de un error de reloj, no de una red más rápida.
¿Qué es Authentication-Results?
Es una cabecera que añade un servidor receptor para indicar lo que comprobó, como SPF, DKIM y DMARC, y el resultado de cada comprobación (RFC 8601). Su primera palabra nombra a ese servidor, y solo debe confiarse en la cabecera de su propio servidor receptor (sección 2.5).
¿Por qué importa el dominio de Reply-To?
Las respuestas van a Reply-To cuando está indicada, y si no a From (RFC 5322, sección 3.6.2). Si nombra otro dominio, las respuestas salen del dominio del que vino el mensaje. Eso no es un error en sí mismo, pero merece revisarse.
¿Esta herramienta envía mis cabeceras a algún sitio?
No. Las cabeceras se leen en su navegador. No se envía ni se guarda nada.
Fuentes
- RFC 5322: Internet Message Format (en inglés)
- RFC 5321: Simple Mail Transfer Protocol, información de traza (en inglés)
- RFC 8601: Message Header Field for Indicating Message Authentication Status (en inglés)
- RFC 7208: Sender Policy Framework (SPF) (en inglés)
- RFC 7489: DMARC (en inglés)
Cifras y texto revisados por última vez el martes, 10 de noviembre de 2026.