pulsa ⌘K para cambiar de herramienta
EMAIL AUTH

Analizador de Encabezados de Correo

Analiza encabezados de correo y rastrea rutas de entrega.

local
message-header
§01 ACERCA DE ESTA HERRAMIENTA

Descripción general

Cada servidor de correo que maneja un mensaje antepone una cabecera Received. Leídas en orden, esas cabeceras son la ruta de entrega: qué host entregó el mensaje a qué otro, y cuándo. Leídas junto a los resultados de autenticación, te dicen si el mensaje viene realmente de donde dice venir.

Esta herramienta despliega las cabeceras, reconstruye la ruta como una lista numerada de saltos con el retardo de cada uno y saca aparte las cabeceras de autenticación, para que no tengas que buscarlas entre el ruido.

Cómo se usa

  1. En tu cliente de correo, abre el original o el código fuente del mensaje. En Gmail es Mostrar original; en Outlook, Propiedades → Encabezados de Internet; en Apple Mail, Ver → Mensaje → Fuente sin procesar.
  2. Pega todo desde el principio del mensaje hasta la primera línea en blanco. El cuerpo no hace falta.
  3. Lee la lista de saltos de arriba abajo: el salto 1 es el origen.
  4. Lee los resultados de autenticación que hay debajo.

Cómo leer la lista de saltos

Cada fila muestra el host emisor (from), el host receptor (by) y el retardo desde el salto anterior. Una entrega normal son de dos a cinco saltos que se completan en unos pocos segundos.

La dirección importa. Los relés anteponen en lugar de añadir al final, así que las cabeceras crudas van de lo más nuevo a lo más antiguo; la lista de aquí está invertida para que se lea en la dirección en la que viajó el mensaje. Cuando la compares con el código fuente crudo, recuerda que una está del revés respecto a la otra.

Los retardos salen de la fecha de cada cabecera Received, y esas marcas de tiempo las escriben máquinas distintas con relojes puestos de forma independiente. Una discrepancia de uno o dos segundos, incluso negativa, es desfase y no prueba de nada. Un hueco de minutos u horas es real, y casi siempre significa que el servidor receptor puso el mensaje en cola; el greylisting, que retrasa a propósito a un remitente que escribe por primera vez, es la causa más habitual con diferencia.

Cómo leer los resultados de autenticación

Hay cuatro cabeceras que importan, y responden a preguntas distintas:

  • Received-SPF: ¿estaba autorizada la IP que conectó para enviar en nombre del dominio del remitente del sobre? SPF comprueba el sobre (MAIL FROM), que no es la cabecera From: que ve tu destinatario. Un mensaje puede pasar SPF y seguir mostrando un remitente falsificado.
  • DKIM-Signature: una firma criptográfica sobre unas cabeceras seleccionadas y el cuerpo, verificable contra una clave pública en el DNS del dominio firmante. d= es el dominio firmante y s= es el selector, que juntos localizan la clave en <selector>._domainkey.<domain>.
  • Authentication-Results: el veredicto propio del servidor receptor, combinando SPF, DKIM y DMARC. Es la línea que hay que leer primero, porque la escribe la única máquina de la cadena en la que tienes motivos para confiar.
  • ARC-Authentication-Results: el veredicto que registró un intermediario antes de modificar el mensaje. Las listas de correo reescriben cabeceras y rompen DKIM por diseño, y ARC existe para que el resultado original sobreviva a eso.

DMARC es el que determina qué hacen realmente los destinatarios. Exige que SPF o DKIM pasen y además estén alineados: el dominio que pasa tiene que coincidir con el dominio de la cabecera From: visible. La alineación es la razón por la que un mensaje puede mostrar spf=pass y dkim=pass y aun así fallar DMARC: los dos pasaron, pero para el dominio equivocado.

Ejemplos

  • «Nuestro correo va a spam». Lee Authentication-Results en un mensaje que te hayas enviado a ti mismo en otro proveedor. Si DKIM pasa pero DMARC falla, el problema es la alineación y no la firma.
  • Un mensaje de phishing convincente. Compara el from del salto 1 con el dominio de la cabecera From: visible. Falsificar el nombre que se muestra es trivial; falsificar un primer salto que coincida con la infraestructura real del dominio suplantado, no.
  • Una entrega que tarda veinte minutos. Localiza el salto con el retardo. Si es el primer servidor de entrada del destinatario, el greylisting es la respuesta probable y se resuelve solo en el reintento.
  • Correo que dejó de llegar después de un cambio en el DNS. Comprueba SPF en los resultados. Dos registros SPF en un mismo dominio, o un registro que supera el límite de diez consultas, producen los dos un fallo permanente con toda la pinta de un misterio.
  • Una lista de correo que rompe tu firma. Busca cabeceras ARC. Su presencia te dice que un intermediario modificó el mensaje y dejó registrado el veredicto anterior.

Notas

Las líneas de continuación se despliegan antes de analizar. Las cabeceras largas se parten en varias líneas con espacio en blanco al principio, y un analizador que lea línea a línea sin unirlas truncará exactamente las cabeceras que más importan.

Los valores from y by se leen solo del inicio de una cláusula. Una cabecera Received sin cláusula from a menudo contiene igualmente la cadena envelope-from dentro de un comentario, y tratar eso como el host que conectó mostraría una dirección suministrada por el atacante como origen del mensaje, justo el dato que has venido a comprobar.

Todo lo que hay aquí describe lo que dicen las cabeceras. Las cabeceras escritas antes de la primera máquina que controlas se pueden falsificar por completo, así que la cadena es evidencia sobre tu propia infraestructura y una afirmación sobre todo lo que hay más arriba.

Para inspeccionar un mensaje guardado en lugar de sus cabeceras, usa el visor de EML.

FAQ
¿Se suben a algún sitio las cabeceras que pego?
No. Las cabeceras se despliegan y se analizan dentro de la página; no hay ninguna petición de red. Aquí eso importa porque unas cabeceras completas contienen direcciones de destinatarios, nombres de host internos e identificadores de mensaje.
¿Por qué la lista de saltos está en el orden inverso a las cabeceras crudas?
Porque cada relé antepone su propia línea Received, así que el orden crudo va de lo más nuevo a lo más antiguo. La lista se invierte para que el salto 1 sea el remitente original y el último salto sea tu buzón: la dirección en la que el mensaje viajó de verdad.
¿Puedo confiar en los primeros saltos?
Solo desde el primer servidor que controlas tú, hacia dentro. Todo lo anterior lo escribieron máquinas que no operas y se puede falsificar por completo. Lee la cadena de abajo hacia arriba y deja de confiar en ella en la frontera de tu propia infraestructura.
Un salto muestra un guion en lugar de un host emisor. ¿Es un problema?
No. Los relés internos a menudo registran solo una cláusula `by` sin `from`, lo cual es normal en la entrega local, en el traspaso por LMTP y en el filtrado con sieve. Un guion significa que la cabecera de verdad no tenía cláusula from, no que el análisis haya fallado.
¿Qué significa un retardo largo en un salto?
Normalmente greylisting o una cola en el servidor receptor. Los retardos se calculan a partir de las marcas de tiempo de cabeceras Received consecutivas, y esos relojes pertenecen a máquinas distintas, así que un retardo cero o ligeramente negativo es desfase de reloj y no un viaje en el tiempo.