Herramientas populares

Tema

Analizador de cabeceras de correo electrónico

Use este analizador de cabeceras de correo para analizar el encabezado de un correo electrónico: pegue las cabeceras y vea la ruta que siguió el mensaje, cuánto tardó cada salto y qué dijeron las comprobaciones SPF, DKIM y DMARC de su proveedor.

Se lee en su navegador · solo se consultan las IP públicas de los servidores y, si usted lo pide, el dominio del remitente · no se guarda nada

Sus cabeceras nunca salen de su dispositivo. Solo se consultan las direcciones IP y los dominios que aparecen debajo del resultado.

Lo que verá

  • Quién lo envió realmente, juzgado solo por las comprobaciones de su propio proveedor
  • Cada servidor del camino, el retraso en cada uno y si usó TLS
  • SPF, DKIM, DMARC y ARC, y si coinciden con la dirección de From
  • Dominios parecidos, resultados falsificados y otras señales, cada una con su evidencia
  • Cabeceras antispam de Microsoft 365, Gmail y SpamAssassin, decodificadas
  • Reglas de Gmail y Yahoo para remitentes masivos, incluida la cancelación de suscripción con un clic

¿Qué es la cabecera de un correo electrónico?

La cabecera de un correo electrónico es el bloque de líneas que hay sobre el texto del mensaje: quién lo envió y a quién, cuándo, y un registro de cada servidor que lo manejó. Las aplicaciones de correo ocultan casi todo; “Mostrar versión original” o “Ver código fuente” lo muestra todo.

Cada línea es un nombre, dos puntos y un valor; un valor largo continúa en líneas que empiezan con un espacio (RFC 5322). Las cabeceras terminan en la primera línea en blanco. Todo lo que sigue es el cuerpo, que esta herramienta nunca lee.

Las escriben tres tipos de autores: la app del remitente (From, To, Subject, Date), cada servidor del camino (una línea Received por cada uno) y su proveedor (Authentication-Results, veredictos de spam). Solo estas últimas las comprueba alguien en quien usted confía.

La muestra del boletín30 campos · 4,6 KB

Añadido por su proveedor (Google)11 campos

  1. 1Delivered-To: reader@example.com
  2. 2Received: by 2002:a05:6214:5a0b:… with SMTP id kq11csp1342871qvb; Wed, 21 Oct 2026 07:02:48 -0700
  3. 3–7 X-Google-Smtp-Source, X-Received, ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results
  4. 8Return-Path: <bounces+48213-9f1c-reader=example.com@sendgrid.net>
  5. 9Received: from o1.ptr1234.example.org ([167.89.118.37]) by mx.google.com with ESMTPS id …; Wed, 21 Oct 2026 07:02:47 -0700
  6. 10Received-SPF: pass (google.com: domain of …@sendgrid.net designates 167.89.118.37 as permitted sender) client-ip=167.89.118.37;
  7. 11Authentication-Results: mx.google.com; dkim=pass …; dkim=pass …; spf=pass …; dmarc=pass …

Añadido por servidores intermedios (SendGrid y example.org)5 campos

  1. 12DKIM-Signature: v=1; a=rsa-sha256; d=example.org; s=s1; h=content-type:from:…
  2. 13DKIM-Signature: v=1; a=rsa-sha256; d=sendgrid.info; s=smtpapi; h=content-type:from:…
  3. 14Received: by filterdrecv-7d9c8b5f6-2kqzr with SMTP id … 2026-10-21 14:02:13.517 +0000 UTC
  4. 15Received: from app-01.example.org ([198.51.100.24]) by geopod-ismtpd-3 (SG) with ESMTPSA id …; Wed, 21 Oct 2026 14:02:12.902 +0000
  5. 16Received: from localhost ([127.0.0.1]) by app-01.example.org (Postfix) with ESMTP id 4Xc9Fq2Lb1z9vKs; Wed, 21 Oct 2026 14:02:10 +0000

Escrito por la app del remitente14 campos

  1. 17Content-Type: multipart/alternative; boundary=8a1f4c2e9b7d3a6c5e0f
  2. 18Date: Wed, 21 Oct 2026 14:02:04 +0000 (UTC)
  3. 19From: Example Weekly <news@example.org>
  4. 20Mime-Version: 1.0
  5. 21Message-ID: <3qX0b1wZTcO2pN9sKd4ZfA@geopod-ismtpd-3>
  6. 22Subject: This week at Example: five things worth reading
  7. 23List-Unsubscribe: <https://u48213.ct.sendgrid.net/lu/unsubscribe?…>, <mailto:unsubscribe@example.org?…>
  8. 24List-Unsubscribe-Post: List-Unsubscribe=One-Click
  9. 25–29 List-Id, Feedback-ID, X-SG-EID, X-SG-ID, X-Entity-ID
  10. 30To: reader@example.com

línea en blanco: aquí empieza el cuerpo, que esta herramienta nunca lee

Abreviado: una línea por campo, numerada como en las cabeceras. Colores como en el resultado: su proveedor, servidores intermedios, el remitente.
Analizador de cabeceras de correo: un mensaje parecido a PayPal con veredicto, hallazgos y un intervalo de 41 minutosAnalizador de cabeceras de correo: un mensaje parecido a PayPal con veredicto, hallazgos y un intervalo de 41 minutosEl veredictoQuién lo envió, juzgado solo por el Authentication-Results que escribió su proveedor, con el servidor que lo comprobó.Lo que destacaCada hallazgo con su gravedad, el motivo y la línea exacta de la cabecera de la que proviene.La ruta de entregaCada servidor desde la cabecera Date hasta la bandeja de entrada, los intervalos a escala y el límite de confianza que los cruza.Los datosCuánto tardó la entrega, cuántos saltos hubo, si cada salto externo usó TLS y qué carpeta eligió Microsoft.
La muestra sospechosa: las comprobaciones de Microsoft 365 no confirman al remitente, los hallazgos señalan la evidencia y la ruta muestra dónde esperó el mensaje. Seleccione un número para ver qué muestra cada parte.

Cómo analizar el encabezado de un correo electrónico, de abajo hacia arriba

Para analizar las cabeceras de un correo, lea las líneas Received de abajo hacia arriba. Cada servidor añade su línea encima de las que ya hay, así que la más baja es el primer salto y la de arriba es su proveedor entregando el mensaje al buzón (RFC 5321 §4.4).

Una línea indica quién lo recibió (by), desde qué servidor y dirección (from, la dirección vista en la conexión), cómo (with: ESMTPS significa STARTTLS, ESMTPSA significa STARTTLS más un inicio de sesión) y cuándo. Los servidores marcan su propia hora local, así que convierta cada una a UTC antes de restar: 07:02:47 -0700 son las 14:02:47 UTC.

Solo las líneas que escribió su proveedor son seguras. Todo lo que está debajo de su primera línea proviene de servidores que usted no puede comprobar, y un remitente puede añadir líneas propias.

En la cabecera · arriba es lo más reciente

El recorrido · primero el salto 1

#2 by 2002:a05:6214:5a0b:…with SMTP id kq11csp…07:02:48 -0700
5Google (interno)14:02:48 UTC+1 s
#9 from o1.ptr1234.example.org [167.89.118.37]by mx.google.com with ESMTPS07:02:47 -0700
4mx.google.com14:02:47 UTC+33 s

Límite de confianza

#14 by filterdrecv-7d9c8b5f6-2kqzrwith SMTP id filterd…2026-10-21 14:02:13.517 +0000 UTC
3SendGrid (filtro)14:02:13 UTC+0,6 s
#15 from app-01.example.org [198.51.100.24]by geopod-ismtpd-3 (SG) with ESMTPSA14:02:12.902 +0000
2SendGrid14:02:12 UTC+2,9 s
#16 from localhost [127.0.0.1]by app-01.example.org (Postfix) with ESMTP14:02:10 +0000
1app-01.example.org14:02:10 UTCprimero

Léala hacia arriba: cada servidor añade su línea encima

Las cinco líneas Received del boletín. El salto 1 es la app del boletín; los 33 s entre SendGrid y Google son el mayor intervalo.

SPF, DKIM y DMARC en las cabeceras de un correo

SPF pregunta si el servidor remitente puede enviar en nombre del dominio del sobre (el Return-Path). DKIM pregunta si un dominio firmó el mensaje y la firma sigue coincidiendo. DMARC pregunta si un dominio con SPF o DKIM aprobado coincide con la dirección de From que usted ve.

Su proveedor escribe las respuestas en Authentication-Results. Confíe en el bloque que escribió su proveedor junto a su propia línea Received. Las demás copias, las copias ARC y las que están entre las líneas del remitente pueden haberlas añadido cualquiera (RFC 8601).

Un pass demuestra el dominio, no sus intenciones: examp1e.com puede aprobar los tres por sí mismo.

Authentication-Results, desglosadoel boletín · luego la muestra sospechosa
Authentication-Results: mx.google.com;1

Quién comprobóel authserv-id: el servidor propio de su proveedor

dkim=pass header.i=@example.org header.s=s1 header.b=Xk3Pq9aZ;2

DKIM: lo firmó example.orgsu clave está en s1._domainkey.example.org

dkim=pass header.i=@sendgrid.info header.s=smtpapi …;3

Una segunda firmala propia del servicio de envío; no puede alinearse con example.org

spf=pass (google.com: … designates 167.89.118.37 as permitted sender) smtp.mailfrom=…@sendgrid.net;4

SPF: autorizado a enviar para sendgrid.netel dominio del sobre (Return-Path), no el de From

dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.org5

DMARC: el dominio de From coincide con ②p=quarantine es lo que example.org pide a los receptores que hagan con los fallos

#3 Authentication-Results: spf=softfail (sender IP is 198.51.100.77) … dkim=none … dmarc=none action=none … compauth=fail reason=001CuentaLo escribió Microsoft 365, encima de la primera línea Received que añadió.

Límite de confianza

#7 Authentication-Results: protection.outlook.com; spf=pass … dkim=pass … dmarc=pass action=none … compauth=pass reason=100Se ignoraNombra a Microsoft pero está debajo de todas las líneas Received: vino dentro del mensaje. Un receptor nunca escribe ahí.
Debajo de la línea: los dos Authentication-Results de la muestra sospechosa. La posición decide cuál cuenta.

¿Este correo es real o está suplantado?

Las cabeceras no pueden decirle si una oferta es honesta, pero muestran si el dominio de From realmente lo envió y si imita a otro. Empiece por el veredicto que escribió su proveedor y luego busque estas señales.

Ninguna prueba un phishing por sí sola, y varias diferencias habituales son normales. Microsoft señala que un dominio parecido puede aprobar SPF, DKIM y DMARC si su propietario los configuró (Microsoft).

  • Un dominio de From parecidoGrave

    paypa1-billing.examplefrente apaypal.com

    Un dígito o una letra similar cambiados. Puede aprobar SPF, DKIM y DMARC por sí mismo.

  • Letras de otro alfabetoGrave

    xn--pypal-4ve.examplese muestra comopаypal.example

    La а es cirílica. Las cabeceras conservan la forma xn-- (punycode), que lo delata.

  • Su proveedor dice failGrave

    compauth=fail reason=001 · spf=softfail

    El receptor no pudo vincular el dominio de From con el servidor que lo envió.

  • Un nombre que contiene otra direcciónMedia

    "accounts@example.com" <notice@mailer.example>

    Las aplicaciones muestran el nombre, no la dirección. El remitente real está entre los corchetes angulares.

  • El veredicto propio del filtroMedia

    CAT:PHSH · dest:J · SFTY:9.25

    Microsoft lo clasificó como phishing y lo envió a No deseado; 9.25 es el consejo de primer contacto.

  • Resultados pass debajo de la líneaMedia

    #7 Authentication-Results: protection.outlook.com; spf=pass dmarc=pass

    Escritos debajo de todas las líneas Received, así que los escribió el remitente. Solo cuentan los de su proveedor.

Normales, no son señales de alarma por sí solas

  • Return-Path difiere de From

    sendgrid.netfrente aexample.org

    Los servicios de correo envían por usted; DKIM aporta la coincidencia.

  • Reply-To difiere de From

    Reply-To: support@example.org

    Las respuestas van a un servicio de atención. Merece una mirada solo si ese dominio imita a otro.

  • Una hora que va hacia atrás

    09:47:12 → 09:47:11 (−1 s)

    Cada servidor marca su propio reloj, y los relojes pueden diferir en un segundo o más.

  • Un servidor en otro país

    CTRY:US · 209.85.208.54

    Ahí está el servidor, no la persona. Los grandes proveedores envían desde todas partes.

Señales de la muestra sospechosa y de variantes inventadas. Ninguna prueba un phishing por sí sola.

¿Por qué se retrasó mi correo?

Reste cada hora de Received a la de la línea superior, en UTC. El mayor intervalo muestra dónde esperó el mensaje. Un intervalo de 30 minutos o más es coherente con un reintento (RFC 5321 sugiere esperar al menos 30 minutos).

La cabecera Date proviene del dispositivo del remitente, así que el tiempo entre Date y el primer servidor incluye un reloj atrasado o un borrador escrito mucho antes de enviarse. Las horas también pueden retroceder un segundo cuando los relojes de dos servidores difieren.

Ningún estándar dice cuánto es demasiado.

La muestra sospechosahoras en UTC
Cabecera Date09:05:44 UTC
+7 s
mail.paypa1-billing.example09:05:51 · primer servidor
41 min 21 s≥ 30 min: un reintento

Microsoft 365

  • 09:47:12entrada, primera línea
  • 09:47:11interno · −1 s
  • 09:47:13servidor de buzones
  1. 09:05:44Cabecera Dateel reloj del remitente
  2. +7 s
  3. 09:05:51mail.paypa1-billing.exampleprimer servidor
  4. 41 min 21 s≥ 30 min: coherente con un reintento
  5. 09:47:12Microsoft 365 (servidor de entrada)primera línea que escribió Microsoft
  6. −1 slos relojes difieren
  7. 09:47:11Microsoft (interno)
  8. +2 s
  9. 09:47:13Microsoft (servidor de buzones)
desde la cabecera Date
41 min 29 s
desde el primer servidor
41 min 22 s
La muestra del boletín · 44 sadónde fue el tiempo
  • Date → primer servidor 6 s
  • hacia SendGrid 2,9 s
  • filtro de SendGrid 0,6 s
  • SendGrid → Google, el mayor intervalo 33 s
  • dentro de Google 1 s

Cabeceras de spam de Microsoft 365 y Gmail, decodificadas

Microsoft 365 escribe el veredicto de su filtro en X-Forefront-Antispam-Report: CAT es el veredicto, SFV cómo resolvió el filtrado de spam, y X-Microsoft-Antispam-Mailbox-Delivery indica a qué carpeta fue.

SCL se sigue escribiendo, pero Microsoft dice que ya no decide nada en Microsoft 365: lea CAT en su lugar (Microsoft). BCL califica el correo masivo por las quejas, de 0 a 9, y el umbral de su política (7 por defecto) decide.

Gmail no escribe ningún veredicto de spam documentado. Los servidores con SpamAssassin añaden X-Spam-Status con la puntuación, el umbral y las reglas que se activaron.

X-Forefront-Antispam-Reportla muestra sospechosa
CIP:198.51.100.77CTRY:LANG:en3SCL:5SRV:5IPV:NLI2SFV:SPMH:mail.paypa1-billing.examplePTR:mail.paypa1-billing.example1CAT:PHSH4SFTY:9.25SFS:(13230040)(376014)(1800799024)(8096899003)6DIR:INB
  1. 1CAT:PHSH el veredicto: phishing (SPM spam, SPOOF, BULK, HPHSH…)
  2. 2SFV:SPM el filtrado de spam lo marcó como spam (NSPM: no es spam)
  3. 3SCL:5 un dato de entrada del filtrado, no la decisión en Microsoft 365
  4. 4SFTY:9.25 se mostró el consejo de seguridad de primer contacto
  5. 5IPV:NLI la IP no está en ninguna lista de reputación
  6. 6DIR:INB entrante; SFS y ARA son diagnósticos internos de Microsoft

Nivel de quejas de correo masivoBCL:0

01–3 pocas4–7 variadas8–9 muchas

Umbrales: 5 estricto, 6 estándar, 7 predeterminado: en ese valor o por encima, es masivo.

Adónde fuedest:J

Correo no deseadoX-Microsoft-Antispam-Mailbox-Delivery

dest:I es la bandeja de entrada. ucf, jmr y ENG son internos.

Gmail y SpamAssassin

Gmail no escribe ningún veredicto de spam documentado: X-Received, X-Google-Smtp-Source y X-Gm-* son internos.

X-Spam-Status: No, score=2.307 required=6.31

SpamAssassin: spam solo en la puntuación requerida o por encima.

Cada valor de la muestra sospechosa, leído con las tablas de cabeceras antispam de Microsoft.

Cómo ver la cabecera de un correo en Outlook, Gmail, Apple Mail y otras aplicaciones

Copie las cabeceras completas, o el mensaje original entero, desde una computadora o un navegador web. Luego péguelas arriba, o guarde el mensaje como archivo .eml y súbalo.

Cada aplicación las esconde en un menú distinto. Elija la suya: los pasos siguen la propia página de ayuda de cada proveedor.

  1. 1Abra el mensaje
  2. 2Más acciones ···
  3. 3Ver
  4. 4View message details

Fuente: support.microsoft.com · Ver encabezados de mensajes de Internet

¿Desde un teléfono? Las aplicaciones de Gmail, Outlook y Apple Mail no muestran las cabeceras completas. Abra el mensaje en un navegador (Gmail, Outlook en la web) o en una aplicación de escritorio, o reenvíelo como adjunto y suba aquí el .eml.

Cómo rastrear un correo, y qué puede y qué no puede decirle una IP

Para rastrear un correo, tome la dirección from de la primera línea Received que escribió su proveedor: el servidor que le entregó el mensaje. Consulte quién es su propietario y sabrá de quién era ese servidor, que puede ser un reenviador y no el remitente original.

Las cabeceras muestran servidores de correo, y solo a veces la propia red del remitente, en X-Originating-IP.

Incluso esa dirección apunta a una red y a un país aproximado, nunca a una persona ni a una calle.

La muestra de Gmail → Outlookconsultado desde su navegador
El equipo de Anano está en las cabeceras
209.85.208.54mail-ed1-f54.google.com
Microsoft 365primera línea Received que escribió

Lo que le dice 209.85.208.54

Propietario
Google LLC · 209.85.128.0/17 (ARIN)
País
Estados Unidos, donde está el servidor
Función
un servidor de envío de Gmail, el que comprobó SPF

Lo que no le puede decir

Quién
Ana, o cualquier otra persona de example.net
Dónde
su ciudad o su calle
Dispositivo
su computadora o su teléfono
El analizador consulta solo las direcciones públicas de los servidores, en su registro, y muestra exactamente qué preguntó.

Cabeceras de correo: preguntas y respuestas

¿Cómo analizar el encabezado de un correo electrónico?

Copie las cabeceras completas desde su aplicación de correo, péguelas arriba y seleccione Analizar cabeceras. El análisis las lee de abajo hacia arriba: el veredicto que escribió su proveedor, la ruta servidor por servidor con el retraso en cada uno, y los hallazgos con su evidencia.

¿Es seguro pegar aquí las cabeceras de un correo?

Las cabeceras se leen en su navegador y nunca se nos envían. Solo se consultan las IP públicas de los servidores: su propietario en los registros (RDAP, consultado por su navegador) y su país en archivos de DB-IP obtenidos de nuestro propio sitio, así que nuestro servidor ve qué rango de direcciones se pidió. El dominio del remitente se consulta en dns.google solo si usted lo pide. Las cabeceras sí contienen direcciones y nombres de servidores, así que compártalas con cuidado.

¿Se pueden falsificar las cabeceras de un correo?

Sí: todo lo que se escribió antes de que su proveedor tomara el mensaje. Cada servidor añade su línea encima, así que un remitente puede poner líneas Received falsas debajo e incluso un Authentication-Results falso que diga pass. Las líneas de su propio proveedor, arriba, y los resultados que escribió junto a ellas son la parte en la que puede confiar; el analizador muestra el resto como afirmaciones.

¿Cómo saber si un correo es falso?

Empiece por el Authentication-Results de su proveedor: un DMARC fail, o un compauth fail en Microsoft 365, significa que el dominio de From no se confirmó. Luego lea el dominio en sí: uno parecido, como paypa1-billing.example, puede aprobar todas las comprobaciones por sí mismo. Por último, vea adónde van las respuestas y qué servidor entregó el mensaje; el analizador enumera cada hallazgo con su evidencia.

¿Puedo encontrar la dirección IP del remitente a partir de un correo?

Puede encontrar el servidor que entregó el mensaje a su proveedor: la dirección from de la primera línea Received de su proveedor, la que comprobó SPF. Normalmente es un servidor de correo, no la computadora de la persona. Algunos proveedores añaden también X-Originating-IP, normalmente el dispositivo o la red del remitente, e incluso eso apunta a una red y a un país aproximado, nunca a una persona.

¿Por qué Gmail no muestra la dirección IP del remitente?

Los mensajes enviados desde la web y las apps de Gmail suelen llevar solo servidores de Google: la primera línea Received no tiene parte from, así que la dirección del propio remitente no está en las cabeceras. La dirección que puede ver pertenece al servidor de Google que transmitió el mensaje, el que comprobó SPF, así que una consulta muestra a Google como propietario, no la red del remitente.

SPF se aprobó, ¿por qué falló DMARC?

SPF comprueba el dominio del sobre (Return-Path), que puede diferir del From que usted ve. DMARC necesita que SPF o DKIM se aprueben para un dominio que coincida con From, exactamente o dentro de la misma organización; si el dominio aprobado es de otra persona, como el dominio de rebotes de un servicio de correo, DMARC falla. Una firma DKIM del dominio de From aprueba DMARC por sí sola.

¿Qué significa un retraso negativo entre saltos?

Un servidor posterior marcó una hora anterior a la del servidor previo. Cada servidor escribe la hora de su propio reloj, y esos relojes pueden diferir, así que el analizador muestra una diferencia de reloj en lugar de un retraso. Las horas de las líneas inferiores a las que escribió su proveedor también pueden estar falsificadas; trate su orden y sus intervalos como afirmaciones.

¿Qué significan SCL y BCL?

Ambos son puntuaciones de Microsoft 365 en sus cabeceras antispam. BCL califica el correo masivo por su nivel de quejas, de 0 (no es de un remitente masivo) a 9. SCL se sigue escribiendo, pero en Microsoft 365 es un dato de entrada del filtrado, no la decisión: CAT lleva el veredicto, y SFV indica cómo trató el filtrado de spam el mensaje.

¿Las cabeceras de un correo muestran los destinatarios en BCC?

No. Las copias ocultas nunca se escriben en las cabeceras: el servidor de envío las entrega desde el sobre, y las líneas To y Cc solo muestran a los destinatarios visibles. Una cláusula for de una línea Received puede nombrar a un destinatario, por lo que se pide a los servidores usarla con cautela. Delivered-To también puede mostrar el buzón al que llegó el mensaje.

¿Es lo mismo que el Message Header Analyzer de Microsoft?

No. El Message Header Analyzer de Microsoft es un complemento de Outlook y una página web que decodifica las cabeceras de un mensaje. Este lee las mismas cabeceras de Microsoft y también las de Gmail, las de SpamAssassin y el rastro de cada salto, decide en qué resultados confiar según el lugar donde están y se ejecuta por completo en su navegador.

¿Por qué hay varias cabeceras Authentication-Results?

Cada servidor que comprueba un mensaje puede añadir una, y los remitentes pueden añadir falsas, así que un mensaje suele llevar varias. Solo cuenta la que escribió su proveedor: arriba, junto a su propia línea Received, con el nombre de su propio servidor. Los ARC-Authentication-Results son resultados sellados por un reenviador, para que el siguiente servidor vea qué se aprobó antes de que el reenvío modificara el mensaje.

¿Le falta algo?Sugiera una función o una herramienta nueva

Más herramientas de correo