Cómo leer las cabeceras de un correo

Authentication-Results: el veredicto y su trampa

Es la cabecera decisiva, normalizada por el RFC 8601. El servidor que acepta el mensaje consigna en ella el resultado de las comprobaciones que acaba de realizar:

Authentication-Results: mx.ejemplo.es;
       dkim=pass header.d=ejemplo.es header.s=s2026;
       spf=pass smtp.mailfrom=bounces.enrutador.example;
       dmarc=pass header.from=ejemplo.es

Tres métodos, tres resultados y propiedades asociadas a cada uno. header.d= nombra el dominio que ha firmado con DKIM; header.s= da el selector que apunta a la clave pública; smtp.mailfrom= da el dominio del sobre validado por SPF.

Y aquí está la trampa que la mayoría de las lecturas pasa por alto: esta cabecera se escribe libremente. Nada impide a un atacante insertar, en el mensaje que envía, una línea Authentication-Results que proclame dkim=pass para el banco que imita. Solo tiene valor la cabecera que añade el servidor de recepción del destinatario; el resto es texto aportado por el remitente.

Dos referencias permiten decidir. Primero el segmento inicial, el authserv-id: nombra al servidor que dice haber hecho la comprobación, y debe corresponder al dominio de recepción real. Después el orden: cada relé antepone la suya, así que la más alta del mensaje es la más reciente, la de la frontera final. Un mensaje con tres Authentication-Results ha cruzado tres fronteras —o transporta dos escritas en otra parte—.

La alineación, el paso que el veredicto no muestra

Un spf=pass aislado no dice casi nada. SPF valida el dominio del sobre, no el que ve el destinatario. Cuando un boletín sale por un enrutador externo, el sobre pertenece a ese enrutador y SPF pasa legítimamente, sin cubrir el dominio mostrado en From:. DMARC exige más: que el método que pasa esté alineado con el dominio del From:.

La lectura consiste, pues, en comparar dos cadenas. ¿Cubre el dominio de header.d= el de From:? ¿Lo cubre el de smtp.mailfrom=? Basta con que uno de los dos responda que sí para que DMARC quede satisfecho. En el ejemplo anterior SPF pasa sin alinearse, DKIM pasa alineándose, y el mensaje resulta conforme. Ese caso —un SPF válido que aun así deja fallar a DMARC— es el malentendido más frecuente del protocolo, y en las cabeceras se ve en tres segundos.

DKIM-Signature: qué cubre la firma

La cabecera de firma viaja en el mensaje original, con independencia de cualquier veredicto:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=ejemplo.es; s=s2026; h=from:to:subject:date;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Xk9dQ2mF...

d= y s= designan la clave pública que hay que consultar en DNS. h= enumera los campos que la firma cubre —y esa lista merece atención, porque lo que no figura en ella puede modificarse sin invalidar la firma—. bh= es la huella del cuerpo, b= la firma propiamente dicha.

De ahí se sigue un punto práctico: la presencia de un DKIM-Signature no prueba nada por sí sola. Verificar una firma exige recalcular esas huellas, lo que requiere el cuerpo completo del mensaje y una consulta DNS. Ese es el trabajo del servidor de recepción, y el procedimiento para comprobar una firma DKIM a mano lo detalla. Una lectura de cabeceras se limita a constatar que la firma existe, qué dominio reivindica y qué concluyó el servidor.

Received:: el trayecto, leído al revés

Cada servidor que se hace cargo del mensaje antepone un campo Received: a la pila. La consecuencia es contraintuitiva: el primer Received: del mensaje es el último salto cronológico, y el trayecto se lee de abajo arriba.

Received: from rele.ejemplo.es (rele.ejemplo.es [198.51.100.24])
        by mx.destinatario.example with ESMTPS id 4Wx1Yz;
        Wed, 5 Aug 2026 09:14:50 -0700 (PDT)

Cada línea da el host anunciado (from), el host que recibe (by), el protocolo (with), casi siempre la dirección IP entre corchetes y la marca de tiempo. De ahí salen tres lecturas.

La primera es el origen real: la dirección IP del salto más antiguo, la del servidor que envió de verdad. Resiste cualquier falsificación del From:, y es la que debe citar una denuncia de abuso ante un alojador.

La segunda es el retraso. Comparar las marcas de tiempo de dos saltos consecutivos da el tiempo pasado en cada etapa. Unos segundos son normales. Varios minutos apuntan a una cola de espera, a greylisting o a un filtrado intermedio, y explican a menudo que un mensaje «llegara tarde» sin que nadie lo bloqueara. Esta pista es de las primeras que conviene seguir cuando mensajes legítimos acaban en no deseados.

La tercera es el número de fronteras cruzadas. Un mensaje directo hace dos o tres saltos. Una decena delata una cadena de redirecciones y, por tanto, un contexto en el que SPF tiene muchas papeletas de estar roto.

ARC, listas de distribución y reenvíos

Cuando un intermediario modifica un mensaje —una lista que añade un pie, un sistema que reescribe el asunto—, la firma DKIM original deja de verificar y el reenvío rompe la autorización SPF. El mensaje legítimo se vuelve indistinguible de una suplantación.

ARC responde a ese problema haciendo que el intermediario testifique. Aparecen entonces tres cabeceras, numeradas por instancia: ARC-Authentication-Results conserva la instantánea de los veredictos constatados antes de la modificación, ARC-Message-Signature firma el mensaje tal como se retransmite, y ARC-Seal sella el conjunto. La etiqueta cv= del sello de instancia más alta da el estado de la cadena: pass para una cadena intacta, none para un primer eslabón, fail para una rota. El funcionamiento detallado de la cadena ARC merece un artículo propio; para una lectura de cabeceras, su sola presencia basta para explicar una autenticación que se desmorona sin fraude alguno.

Los campos List-Id y List-Unsubscribe cuentan lo mismo de forma más simple: el mensaje viene de una lista, y una lista reescribe el remitente de buena gana.

Lo que las cabeceras nunca dirán

Un mensaje es un caso. Prueba lo que le ocurrió a ese mensaje, y nada más. Las cabeceras no dicen cuántos otros mensajes se enviaron bajo el mismo dominio aquel día, ni cuántos fallaron, ni desde qué direcciones IP. Un dominio puede exhibir un mensaje impecablemente autenticado y dejar pasar, en otra parte, un flujo entero de suplantación.

Ese es el límite estructural del ejercicio, y la razón de que existan los informes agregados. Donde la cabecera muestra un caso, la lectura de los informes agregados DMARC muestra la totalidad de los emisores de un dominio, día tras día, y permite detectar una suplantación en los informes que nadie habría señalado. Ambas lecturas se complementan: una responde a «por qué este mensaje», la otra a «qué ocurre en este dominio».

Para ahorrar el desmenuzado manual, un analizador de cabeceras gratuito devuelve las mismas constataciones de una vez: veredictos por método, alineación recalculada, cadena ARC y trayecto reconstruido. Y para la vista de conjunto de un dominio, el analizador DMARC gratuito parte del otro extremo: la configuración publicada en lugar de un mensaje recibido.

Preguntas frecuentes

¿Puede falsificarse una cabecera por completo? Todo lo que escribe el remitente, sí: From:, Reply-To:, Date:, e incluso falsos Received: o falsos Authentication-Results insertados antes del envío. Lo que no puede falsificarse son los campos añadidos después del envío por los servidores atravesados: se apilan encima. De ahí la regla: la confianza decrece al bajar por la pila.

¿Por qué difiere el Return-Path: del From:? Porque son dos identidades distintas del protocolo. El sobre sirve al enrutado y a los rebotes; la dirección mostrada sirve a la persona. Un enrutador externo usa casi siempre su propio sobre, y el desfase no tiene nada de anormal en sí: solo es un problema si ninguna firma DKIM alineada lo compensa.

¿Contienen las cabeceras datos personales? Sí: direcciones de correo, direcciones IP, a veces nombres de servidores internos. Un bloque de cabeceras pegado en un ticket público o enviado a un servicio ajeno expone todo eso. La precaución merece tomarse antes de compartir un mensaje en claro.

En resumen

Las cabeceras son la única parte de un correo que guarda rastro de su pasado. Bastan tres bloques: las identidades, para saber quién dice ser el mensaje; Authentication-Results, para saber qué concluyó el servidor de recepción —comprobando siempre qué servidor habla—; y la pila Received:, para reconstruir de dónde viene y cuánto tardó. Lo demás es ruido técnico. Y el día en que la pregunta pasa de «este mensaje» a «este dominio», la respuesta está en los informes agregados.