RFC 8601 — Campo de encabezado de resultados de autenticación

Proposed Standard Email Authentication Obsoletes RFC 7601 Published March 2026

ELI5: Cuando una carta llega a la sala de correo de una empresa, el guardia de seguridad verifica la identificación del conductor de entrega, confirma la dirección de remitente e inspecciona el sello contra manipulaciones. Luego adjunta una nota adhesiva a la carta resumiendo sus hallazgos: "Identificación del conductor verificada, dirección de remitente confirmada, sello intacto." El encabezado Authentication-Results es esa nota adhesiva — es una forma estandarizada para que el servidor de correo receptor registre los resultados de todas las verificaciones de autenticación para que los filtros posteriores, motores de spam y clientes de correo puedan usar la información sin volver a ejecutar las verificaciones.

Por qué existe esta RFC

La autenticación de correo electrónico implica múltiples mecanismos independientes: SPF, DKIM, DMARC, ARC y otros. Cada uno produce su propio resultado. Sin una forma estándar de registrar estos resultados, cada componente en la cadena de entrega de correo — filtros de contenido, clasificadores de spam, clientes orientados al usuario — tendría que reevaluar independientemente cada mecanismo de autenticación.

RFC 8601 define el campo de encabezado Authentication-Results, una forma estructurada para que el MTA fronterizo (el primer servidor en tu infraestructura que recibe el mensaje de internet) registre el resultado de todas las verificaciones de autenticación en un único encabezado. Este resultado puede ser consumido por todos los componentes posteriores.

RFC 8601 obsoletó RFC 7601, que a su vez obsoletó RFC 5451. Las actualizaciones refinaron la sintaxis, registraron palabras clave de método adicionales y aclararon el manejo de límites de confianza.

Cómo funciona

Estructura del encabezado

El encabezado Authentication-Results tiene una gramática definida:

Authentication-Results: <authserv-id>; <method>=<result> [reason=<text>] [<property>.<type>=<value>] [; ...]

Ejemplo del mundo real

Authentication-Results: mx.receiver.com;
dkim=pass header.d=example.com header.s=mtg20240101 header.b=LjIEJLN;
spf=pass (sender IP is 198.51.100.25) smtp.mailfrom=example.com;
dmarc=pass (p=reject dis=none) header.from=example.com;
arc=pass (i=1 spf=pass dkim=pass dmarc=pass)

Cómo se genera

El MTA fronterizo recibe un mensaje de internet a través de SMTP.
Ejecuta verificaciones SPF contra el remitente de sobre y la IP de conexión.
Valida las firmas DKIM consultando DNS para obtener claves públicas.
Evalúa la política de DMARC y alineación.
Valida cualquier cadena ARC presente en el mensaje.
Antepone un encabezado Authentication-Results resumiendo todos los resultados, identificado por su propio nombre de host (el authserv-id).
Los filtros de contenido posteriores, motores de spam y lógica de entrega leen este encabezado en lugar de volver a ejecutar las verificaciones.

Detalles técnicos clave

El authserv-id

El primer token después de Authentication-Results: es el authserv-id, típicamente el nombre de host del servidor que realizó las verificaciones. Esto es crítico para la confianza: un sistema receptor solo debe confiar en encabezados Authentication-Results cuyo authserv-id coincida con un servidor dentro de su propio dominio administrativo. Los encabezados de servidores externos deben ser eliminados o ignorados.

Palabras clave de método

IANA mantiene un registro de palabras clave de método de autenticación. Las más comúnmente utilizadas son:

Método	Qué verifica	Definido en
`spf`	Evaluación de SPF del remitente de sobre	RFC 7208
`dkim`	Verificación de firma DKIM	RFC 6376
`dmarc`	Evaluación de alineación y política DMARC	RFC 7489
`arc`	Validación de cadena ARC	RFC 8617
`auth`	Credenciales de SMTP AUTH (RFC 4954)	RFC 4954
`iprev`	Validación de DNS inverso de IP de conexión	RFC 8601

Valores de resultado

Cada método produce uno de estos valores de resultado:

Resultado	Significado
`pass`	La autenticación fue exitosa.
`fail`	La autenticación falló definitivamente.
`softfail`	La autenticación falló, pero la política del remitente sugiere tratarla como sospechosa en lugar de rechazarla (específico de SPF).
`neutral`	El remitente no hace ninguna aserción (SPF `?all`).
`none`	No se encontró registro de autenticación (sin registro SPF, sin firma DKIM, sin política DMARC).
`temperror`	Fallo temporal (tiempo de espera DNS, etc.). Intenta de nuevo más tarde.
`permerror`	Error permanente (registro malformado, demasiadas búsquedas DNS, etc.).
`policy`	El mensaje pasó autenticación pero falló una verificación de política local.

Tipos de propiedad

Cada resultado puede incluir pares propiedad/valor proporcionando detalle:

Propiedad	Descripción
`header.d`	El dominio de firma DKIM (`d=` etiqueta)
`header.s`	El selector DKIM (`s=` etiqueta)
`header.b`	Hash de firma DKIM truncado (primeros 8 caracteres)
`header.from`	El dominio en el encabezado `From:` del mensaje
`smtp.mailfrom`	El dominio del remitente de sobre (MAIL FROM)
`smtp.helo`	El nombre de host EHLO/HELO utilizado por el remitente

Múltiples resultados

Un único encabezado Authentication-Results puede contener resultados de múltiples métodos, separados por puntos y comas. Alternativamente, múltiples encabezados Authentication-Results pueden estar presentes (por ejemplo, uno por método). Ambos enfoques son válidos.

Límites de confianza

La consideración de seguridad más crítica: nunca confíes en encabezados Authentication-Results de fuentes externas. Un atacante puede incluir un encabezado Authentication-Results falsificado afirmando dkim=pass y dmarc=pass. El MTA fronterizo debe eliminar todos los encabezados Authentication-Results existentes que coincidan con su propio authserv-id, o solo confiar en encabezados que pueda verificar que fueron agregados dentro de su propio dominio administrativo.

Errores comunes

Confiar en encabezados A-R externos: El error más peligroso. Si tu sistema de correo no elimina o ignora encabezados Authentication-Results desde fuera de tu límite de confianza, un atacante puede inyectar resultados falsos. Siempre elimina encabezados A-R entrantes que usen tu authserv-id.
No registrar resultados en la frontera: Si las verificaciones de autenticación ocurren en el MTA fronterizo pero los resultados no se registran en un encabezado, los sistemas de filtrado internos no tienen datos de autenticación para trabajar y deben volver a ejecutar todas las verificaciones (lo que puede producir resultados diferentes debido a la posición de red cambiada).
authserv-id ambiguo: Usar un nombre de host genérico (como "localhost") como authserv-id hace imposible distinguir entre encabezados A-R de tu sistema y los de otros sistemas. Usa tu nombre de host MX completo.
Malinterpretar resultados DKIM: Un resultado dkim=pass solo no significa que el mensaje sea seguro. Verifica el valor de header.d para ver qué dominio lo firmó. Un aprobado para d=attacker.com es sin sentido para mensajes que afirman ser de example.com. Por eso importa la alineación de DMARC.
Ignorar resultados none: Un resultado de none significa que no se encontró ningún registro. Para SPF o DMARC, esto significa que el dominio no ha publicado política de autenticación. Esta ausencia debe ser tratada diferentemente de un fail explícito.

Impacto en la entregabilidad

Mina de oro diagnóstica: Al solucionar problemas de entregabilidad, el encabezado Authentication-Results es el primer lugar a mirar. Te dice exactamente lo que vio el servidor receptor: qué verificaciones pasaron, cuáles fallaron y por qué.
Impulsa decisiones de filtrado: Los proveedores de correo electrónico principales (Gmail, Microsoft, Yahoo) utilizan resultados de autenticación como entradas primarias para su filtrado de spam. Un mensaje con spf=pass, dkim=pass y dmarc=pass tiene una probabilidad significativamente mejor de llegar a la bandeja de entrada.
Integración ARC: El encabezado ARC-Authentication-Results en ARC sigue el mismo formato que el encabezado Authentication-Results estándar, asegurando informes consistentes a través de saltos de reenvío.
Transparencia: Al exponer resultados de autenticación en encabezados de mensaje, RFC 8601 hace que la autenticación de correo sea observable y depurable. Los remitentes pueden solicitar a los destinatarios que reenvíen encabezados sin procesar para diagnosticar fallos de autenticación.
Legible por máquina: El formato estructurado hace que sea fácil para sistemas automatizados analizar y actuar sobre resultados de autenticación, permitiendo monitoreo de entregabilidad programático.