Cómo leer cabeceras Received y seguir la ruta de entrega de un correo

Cada servidor de correo que acepta un mensaje suele añadir una línea Received en la parte superior. Por eso la cadena se lee normalmente de abajo hacia arriba: la línea inferior describe un salto anterior y la superior, la recepción más próxima al buzón.

Anatomía aproximada

Una línea puede contener from, by, with, un identificador, destinatario y fecha. La sintaxis varía entre proveedores. El servidor que escribe la línea controla la parte que describe lo que observó, pero algunos nombres anunciados por el cliente pueden ser falsos.

No interpretes cada texto from como una identidad verificada. Compara nombres, IP, TLS, autenticación y el siguiente salto.

Establece el punto de confianza

Empieza por las líneas añadidas por tu proveedor receptor. Esas cabeceras son las más confiables para describir lo que vio su infraestructura. Al avanzar hacia abajo puedes llegar a servidores del remitente o a texto previo que este controla.

Una cabecera pegada por alguien puede editarse. Sirve para diagnóstico, no como prueba forense independiente. Cuando administras el sistema, compara con registros del servidor y del proveedor.

Procedimiento de lectura

1. Copia la cabecera en una herramienta local y elimina datos no necesarios.
2. Numera las líneas Received desde la inferior a la superior.
3. Para cada salto, anota servidor que entrega, servidor que recibe, protocolo y hora.
4. Normaliza las horas a UTC antes de calcular diferencias.
5. Marca reenvíos, gateways de seguridad y proveedores conocidos.
6. Relaciona la ruta con Authentication-Results, Return-Path y firmas DKIM.

Los husos horarios pueden cambiar el día aparente. Una diferencia negativa suele indicar conversión incorrecta, reloj desajustado o una parte no confiable; no demuestra manipulación por sí sola.

Cómo localizar retrasos

Compara la hora de un salto con la del siguiente. Un intervalo grande señala dónde el mensaje permaneció en cola, aunque la causa requiera registros adicionales: límite temporal, DNS, filtro, reputación o indisponibilidad.

La fecha visible del mensaje (Date) la establece normalmente el cliente emisor y puede ser incorrecta. Para medir entrega utiliza los saltos confiables y la hora registrada al solicitar el envío.

Reenvío y servicios intermediarios

Un mensaje legítimo puede pasar por un proveedor transaccional, un gateway corporativo, una lista o un reenvío personal. Eso añade saltos y puede cambiar autenticación. SPF puede fallar tras reenvío mientras DKIM continúa válido; ARC puede conservar evaluaciones anteriores, pero tampoco certifica el contenido.

Qué no revela una IP

Una IP puede pertenecer a un centro de datos o servicio compartido, no al autor. La geolocalización es aproximada y no identifica una persona. No publiques ni utilices una IP aislada para acusar a alguien. La ruta explica infraestructura, no intención.

Compartir de forma segura

Antes de enviar una cabecera a soporte, oculta direcciones personales, identificadores de mensajes, tokens, IP internas y parámetros únicos salvo que sean imprescindibles. Conserva los dominios y horas relevantes. El analizador de cabeceras procesa la entrada localmente y ayuda a separar campos, pero no valida reputación en tiempo real.

Una conclusión prudente describe observaciones: «el receptor aceptó el mensaje del proveedor X a esta hora y hubo seis minutos entre estos saltos». Evita convertir la ruta en una afirmación de autoría o seguridad que los datos no sostienen.