ARC: conservar la confianza de un correo cuando pasa por intermediarios

En pocas palabras: ARC (Authenticated Received Chain) es un estándar que permite a los relays (listas de distribución, pasarelas antispam, redirecciones, etc.) preservar y sellar los resultados de autenticación (SPF, DKIM, DMARC) que observaron. Así, el destinatario puede decidir con criterio si confía en el mensaje aunque SPF/DKIM fallen legítimamente tras una modificación o redirección.

¿Por qué necesitamos ARC?

Sin ARC, un mensaje legítimo puede ser rechazado después de reenviarse:

• SPF falla porque la IP emisora pasa a ser la del relay;
• la firma DKIM original puede invalidarse si el relay modifica encabezados o cuerpo (banner, footer, marcado antispam);
• como consecuencia, DMARC falla en el destinatario aun cuando el correo era correcto en origen.

ARC permite que el relay declare: «Recibí un mensaje que aprobó SPF/DKIM/DMARC; aquí están mis resultados y los estoy firmando.»
El servidor final revisa la cadena de sellos para decidir si el correo sigue siendo confiable.

¿Cómo funciona ARC? (visión general)

En cada relay se añaden tres encabezados ARC con un índice i=1, i=2, …:

1. ARC-Authentication-Results (AAR) — copia los resultados SPF/DKIM/DMARC tal como los vio el relay.
2. ARC-Message-Signature (AMS) — firma criptográfica del mensaje según lo observó el relay (análogo a DKIM).
3. ARC-Seal (AS) — un sello que firma el conjunto (AAR + AMS + sellos previos) para encadenar la confianza.

Ejemplo de encabezados ARC (simplificado)

ARC-Seal: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; cv=none; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; d=relay.example.net; s=arc1; h=from:to:subject:date:message-id; bh=...; b=...
ARC-Authentication-Results: i=1; relay.example.net; spf=pass smtp.mailfrom=example.org; dkim=pass header.d=example.org; dmarc=pass header.from=example.org

• i=: posición en la cadena (1 en el primer relay, luego +1 por salto).
• d= / s=: dominio y selector (como en DKIM) usados para publicar la clave pública en DNS.
• cv= (en ARC-Seal): Chain Validation declarada por el relay para la cadena que ve; valores comunes: none, pass, fail.
• h=, bh=, b=: campos típicos de la firma (lista de encabezados firmados, hash del cuerpo, firma).

«Veo encabezados ARC sin redirección, ¿es normal?»

Sí. Muchos proveedores grandes (webmail, suites colaborativas, pasarelas de seguridad) firman de forma sistemática el tráfico entrante con ARC.
Objetivos: fijar un punto de verdad interno, rastrear el paso por su infraestructura y facilitar reenvíos posteriores sin perder confianza.

¿Cómo evalúa el destinatario la cadena ARC?

1. Verificar todas las firmas ARC-Message-Signature y ARC-Seal, empezando por el i más alto.
2. Comprobar la continuidad: que no falte ningún i y que cada sello cubra a los anteriores.
3. Revisar cv= en el último ARC-Seal (lo que el firmante declara sobre la cadena).
4. Cruzar con DMARC: si los SPF/DKIM actuales fallan, decidir si se da crédito a los resultados registrados en ARC-Authentication-Results de confianza.

Importante: ARC no obliga a aceptar un mensaje; ofrece contexto verificable para que el destinatario tome una decisión más afinada.

Buenas prácticas (lado operador)

• Firmar y validar ARC en tus relays (listas, alias, pasarelas de seguridad).
• Conservar los encabezados ARC existentes; no elimines sellos válidos.
• Gestionar tus claves (rotación, TTL de DNS, supervisión de fallos de verificación).
• Limitar los cambios del mensaje una vez sellado (banners, reescrituras) o volver a sellar tras modificarlo.
• Registrar las decisiones DMARC influenciadas por ARC para medir su impacto.

Errores frecuentes

• Añadir un ARC-Authentication-Results sin ARC-Message-Signature y ARC-Seal.
• Romper la cadena (índices i duplicados/omitidos, sello que no cubre al anterior).
• Confiar a ciegas en cualquier dominio d= desconocido. La reputación del firmante importa.

Preguntas frecuentes

¿ARC reemplaza DKIM/DMARC?
No. Complementa SPF/DKIM/DMARC preservando los resultados observados por los relays.

¿Quién puede añadir ARC?
Cualquier intermediario de transporte (MTA, pasarela, servicio de correo) que maneje el mensaje.

¿Qué significa exactamente cv=?
Es la declaración del firmante sobre el estado de la cadena que ve: none (sin cadena previa), pass (cadena coherente y verificable), fail (cadena inválida). El destinatario realiza su propia validación.

¿Por qué el mismo mensaje tiene varios i=?
Cada relay incrementa i y añade su propio triplete AAR/AMS/AS.

Para profundizar

• IETF - RFC 8617: Authenticated Received Chain (ARC) : https://datatracker.ietf.org/doc/html/rfc8617
• RFC 8601 - Authentication-Results Header Field (contexto para AAR): https://datatracker.ietf.org/doc/html/rfc8601

---

Hoja rápida

• Objetivo: preservar y sellar los resultados SPF/DKIM/DMARC a través de los relays.
• 3 encabezados: ARC-Authentication-Results (resultados) + ARC-Message-Signature (firma del mensaje) + ARC-Seal (sello de cadena).
• Decisión del destinatario: firmas válidas + reputación del firmante + política DMARC interna.