ARC: la cadena de recepción autenticada (Authenticated Received Chain)

Las tres cabeceras de ARC

Cada participante ARC añade tres campos de cabecera al mensaje, numerados por «instancia» (i=1 para el primer intermediario, i=2 para el siguiente, etc.):

• ARC-Authentication-Results (AAR): la instantánea de los resultados de autenticación (SPF, DKIM, DMARC) que el intermediario constató a la llegada, antes de cualquier modificación. Es el testimonio propiamente dicho.
• ARC-Message-Signature (AMS): una firma, muy próxima a una firma DKIM, calculada sobre el mensaje (cabeceras y cuerpo) tal como el intermediario lo retransmite. Captura el estado del mensaje en ese eslabón preciso.
• ARC-Seal (AS): una firma que cubre el conjunto de las cabeceras ARC de las instancias anteriores más el AAR y el AMS actuales. Es el sello que bloquea la cadena: protege su integridad y su orden, de modo que un eslabón no pueda retirarse ni reordenarse sin que se note.

Cada ARC-Seal lleva una etiqueta de validación de cadena, cv= (chain validation), que vale none, pass o fail. Indica si la cadena, hasta ese eslabón, se mantenía en pie. El sello más reciente resume el estado global: una cadena en cv=pass está intacta de extremo a extremo.

Cómo la utiliza un destinatario

Cuando un mensaje llega con una cadena ARC, el destinatario final procede en dos tiempos. Primero, valida la cadena: ¿los sellos son criptográficamente correctos, en el orden correcto, sin alterar? Si es así, la cadena está en cv=pass.

Después —y ahí es donde se juega todo— decide si confía en los intermediarios que sellaron la cadena. Si es así, puede aplicar un override de política local: en lugar de rechazar el mensaje porque falla a DMARC aquí y ahora, consulta el AAR más antiguo, constata que el mensaje pasaba la autenticación en el origen, y lo entrega a pesar de todo. El correo legítimo de la lista de distribución se salva.

Esta decisión sigue enteramente en manos del destinatario. ARC no fuerza nada: proporciona una prueba explotable, y es el destinatario quien elige servirse de ella. Los grandes proveedores de correo —Google, Microsoft y otros— aplican y honran ARC a gran escala, lo que hace el mecanismo realmente útil en la práctica, aunque siga siendo formalmente experimental.

Un ejemplo concreto

Imaginemos un empleado que escribe a una lista de distribución profesional. Su mensaje sale del servidor de la empresa, perfectamente autenticado: SPF y DKIM alineados para el dominio. La lista lo recibe, añade [Grupo-Sector] al asunto y un pie de página legal, y luego lo reexpide a los trescientos suscriptores. Por el camino, el SPF ya no vale nada (el envío viene ahora de la lista) y la firma DKIM está rota (el asunto y el cuerpo han cambiado). En casa de un suscriptor cuyo dominio está en p=reject, ese mensaje debería acabar rechazado.

Pero la lista participa en ARC. En el momento en que recibió el mensaje, selló un eslabón que atestigua «a la llegada, este mensaje pasaba la autenticación para este dominio». El suscriptor está en un gran proveedor que honra ARC: valida la cadena, la encuentra intacta (cv=pass), confía en la lista, y entrega el mensaje a pesar del fallo DMARC aparente. Sin ARC, esa intervención en la lista acababa en la papelera; con él, llega. Es exactamente ese escenario, repetido miles de veces al día, el que hace el paso a reject menos aterrador de lo que parece, a condición, vamos a verlo, de no convertirlo en una confianza ciega.

ARC no reemplaza a DMARC, y no es automático

Hay que ser honesto sobre los límites, si no, nos contamos historias.

Primero, ARC se apoya enteramente en la confianza. Nada impide técnicamente a un intermediario malicioso sellar una cadena que afirme que un mensaje fraudulento «pasaba la autenticación en el origen». Un sello ARC válido solo prueba que la cadena no se ha alterado a posteriori, no que su contenido es honesto. Por eso el destinatario solo concede un override a los intermediarios que conoce y considera dignos de confianza. ARC desplaza el problema hacia una cuestión de reputación, no lo borra.

Después, ARC no sustituye a DMARC ni al trabajo de alineación. Solo recupera el correo indirecto legítimo que se rompió en tránsito. No hace nada por un mensaje que no era auténtico al principio, y no dispensa en absoluto de publicar SPF, DKIM y DMARC correctamente. En caso de duda sobre los papeles de cada uno, SPF, DKIM y DMARC explicados juntos los repasa: ARC es un parche en los bordes, no el cimiento.

Por último, no todos los destinatarios honran ARC, y no todos los intermediarios lo sellan. Es una capa de mejora, desplegada de forma desigual, no una garantía universal.

ARC y el paso a p=reject

Para un responsable que quiere endurecer su política, ARC cambia discretamente el cálculo del riesgo. El gran temor de reject —ver desaparecer el correo legítimo que transita por listas y reenvíos— es precisamente el caso que ARC está hecho para recuperar, en casa de los destinatarios que lo honran. En la práctica, una parte importante del correo indirecto de los usuarios atraviesa Google o Microsoft, que saben explotar la cadena. Esto no quiere decir que el tema pueda ignorarse, sino que el riesgo es más bajo de lo que a menudo se cree.

El buen método no cambia: la política sube bajo la observación de los informes, sin suponer que ARC cubre en todas partes. La trayectoria prudente está detallada en alcanzar p=reject sin romper el correo legítimo. ARC es una red adicional tendida por los destinatarios, no una autorización para endurecer con los ojos cerrados.

Dónde se ve en los informes

ARC deja un rastro observable. En los retornos diarios de los proveedores de correo, una fuente que falla a la alineación pero que aun así se ha entregado aparece a menudo con una disposición evaluada en none acompañada de una razón del tipo «política local», la firma de un override, frecuentemente ligado a una cadena ARC válida. Localizar esas líneas evita un error clásico: creer que una fuente «fallida» es un problema que corregir, cuando se trata de correo indirecto legítimo recuperado por el destinatario. Saber leer ese matiz marca la diferencia entre entrar en pánico por un falso problema y comprender realmente la postura del dominio.

¿Hay que «configurar ARC»?

Para la gran mayoría de los propietarios de dominios, la respuesta es no, y es una buena noticia. Al contrario que SPF, DKIM o DMARC, ARC no se publica en el dominio emisor en forma de un registro DNS bajo su control. Son los intermediarios (listas, pasarelas, servicios de redirección) y los destinatarios quienes lo implementan. Del lado del remitente, no hay nada que activar: el beneficio de ARC es pasivo, cuando los mensajes transitan por intermediarios que sellan y llegan a casa de destinatarios que honran.

El único caso en que ARC se convierte en un asunto propio es el de una organización que opera una infraestructura que recibe y luego reexpide correo en nombre de otros —una pasarela de seguridad, un servicio de redirección, una plataforma que retransmite. Ahí, aplicar correctamente las cabeceras ARC se convierte en una responsabilidad, para no romper la autenticación de los mensajes transmitidos. Ese trabajo se une a la familia de los estándares avanzados que son MTA-STS y TLS-RPT: útiles, específicos, y pertinentes sobre todo para quien opera infraestructura de mensajería.

En resumen

ARC es la cadena de testimonios que permite a un destinatario salvar el correo legítimo roto por un intermediario, apoyándose en la autenticación de origen en lugar del resultado dañado que él observa. Tres cabeceras (AAR, AMS, AS), una validación de cadena, un override dejado a la discreción —y fundado en la confianza— del destinatario. Es una red valiosa contra los falsos positivos del correo indirecto, honrada por los grandes proveedores, pero ni un sustituto de DMARC, ni una garantía universal, ni algo que se configure en el dominio emisor.

La mejor forma de ver todo esto concretamente sigue siendo mirar los flujos reales. Un paso del dominio por el analizador DMARC gratuito muestra las fuentes tal como son, alineadas o no, y ayuda a distinguir el problema real del correo indirecto que los destinatarios ya saben recuperar.