← RFC Reference

ARC — Cadena de Recepción Autenticada

Por Qué Existe Este RFC

El reenvío de correo electrónico es el talón de Aquiles de SPF y DKIM. Cuando un mensaje se reenvía a través de una lista de correo, un alias o una regla .forward:

• SPF se rompe porque la dirección IP del servidor de reenvío no está autorizada por el registro SPF del remitente original.
• DKIM se rompe si el intermediario modifica el mensaje (añadiendo pies de lista, reescribiendo encabezados, cambiando codificación).

Cuando tanto SPF como DKIM fallan en el destino final, DMARC también falla, y el mensaje puede ser rechazado o puesto en cuarentena, aunque haya sido enviado legítimamente y reenviado a través de infraestructura de confianza.

ARC (Cadena de Recepción Autenticada), definida en RFC 8617, resuelve esto haciendo que cada intermediario registre una captura de los resultados de autenticación que observó, y luego firme esa captura. El receptor final puede examinar la cadena para determinar que el mensaje fue autenticado en el punto de origen, incluso si las verificaciones directas de SPF y DKIM ahora fallan.

Cómo Funciona

Los Tres Conjuntos de Encabezados ARC

Cada intermediario que procesa un mensaje añade un conjunto de tres encabezados, numerados con un contador de instancia (i=) que se incrementa en cada salto:

Ejemplo de Cadena de Custodia

Detalles Técnicos Clave

La Validación de Cadena (cv)

El encabezado ARC-Seal incluye una etiqueta cv= (validación de cadena) con uno de tres valores:

• cv=none — Este es el primer conjunto ARC en la cadena (i=1). No hay cadena anterior que validar.
• cv=pass — Todos los conjuntos ARC anteriores en la cadena han sido validados y sus sellos son intactos.
• cv=fail — La cadena está rota. Un conjunto ARC anterior falló en la validación. Una vez que la cadena está marcada fail, no puede ser reparada.

ARC y Anulación de DMARC

ARC no reemplaza DMARC. En su lugar, proporciona información adicional que un receptor puede usar al tomar decisiones de anulación de DMARC. La lógica del receptor podría ser:

1. Verificar DMARC directamente. Si pasa, entregar normalmente.
2. Si DMARC falla, verificar la cadena ARC. Si la cadena es válida (cv=pass) y el receptor confía en los intermediarios en la cadena, anular el fallo de DMARC.
3. Si la cadena ARC es inválida o los intermediarios no son de confianza, aplicar la política de DMARC como de costumbre.

La decisión de confiar en un intermediario es política local. Gmail, por ejemplo, mantiene una lista de firmantes ARC de confianza (proveedores principales de listas de correo, sistemas de correo universitarios, etc.).

Requisitos de Firma

Las firmas ARC usan el mismo formato criptográfico que DKIM (RSA-SHA256 o Ed25519). El dominio de firma publica su clave pública ARC en DNS en un selector bajo _domainkey, idéntico a la publicación de clave DKIM:

Numeración de Instancias

Los conjuntos ARC se numeran secuencialmente comenzando desde i=1. Cada intermediario añade un conjunto con el siguiente número. El receptor final valida la cadena verificando todos los sellos en orden. Si algún sello falla o falta alguna instancia, toda la cadena es inválida.

Lo Que ARC No Hace

• ARC no autentica al remitente original directamente, registra y transmite resultados de autenticación de saltos anteriores.
• ARC no crea confianza en intermediarios, el receptor debe decidir independientemente qué firmantes ARC confiar.
• ARC no previene modificación de mensajes, registra cuál era el estado de autenticación antes de que ocurriera la modificación.

Errores Comunes

• Asumir que ARC es universalmente honrado: ARC aún es Experimental (no Norma). Aunque Gmail, Microsoft y otros proveedores principales lo soportan, no todos los receptores lo hacen. No debe confiar en ARC solo para entregabilidad.
• Romper la cadena: Si un intermediario que no soporta ARC se encuentra entre dos que sí, la cadena tiene una brecha. El siguiente salto consciente de ARC verá números de instancia faltantes y marcará la cadena como fallida.
• No publicar claves DNS de ARC: Si opera una lista de correo o servicio de reenvío y añade encabezados ARC pero no publica la clave pública correspondiente en DNS, los verificadores no pueden validar su ARC-Seal, rompiendo la cadena.
• Confundir ARC con DKIM: Aunque ARC reutiliza el formato de firma de DKIM, sirven propósitos diferentes. DKIM autentica el dominio de firma como responsable del mensaje. ARC registra una cadena de custodia documentando el estado de autenticación en cada salto.
• Ignorar ARC como propietario de dominio: Aunque los propietarios de dominio no generan encabezados ARC, entender ARC ayuda a diagnosticar problemas de entregabilidad cuando los mensajes pasan a través de listas de correo o servicios de reenvío.

Impacto en Entregabilidad

• Rescata correo reenviado: El valor principal de ARC es prevenir que correo legítimo sea rechazado después del reenvío. Listas de correo, alias universitarios y reglas de reenvío corporativas se benefician de ARC.
• Confianza de ARC de Gmail: Gmail usa ARC para tomar decisiones de anulación de DMARC. Si un mensaje falla DMARC pero tiene una cadena ARC válida de un intermediario de confianza, Gmail puede entregar el mensaje a la bandeja de entrada en lugar de rechazarlo.
• Soporte de Microsoft: Microsoft 365 también evalúa cadenas ARC y las usa en su lógica de anulación de DMARC, particularmente para mensajes de listas de correo de confianza.
• Habilita políticas DMARC más estrictas: Sin ARC, pasar de p=none a p=reject arriesga bloquear correo reenviado legítimo. ARC mitiga este riesgo, haciendo más seguro para los propietarios de dominio adoptar políticas DMARC fuertes.
• A prueba del futuro: A medida que más intermediarios adopten ARC, el ecosistema de correo electrónico se vuelve más resiliente. Soportar ARC posiciona su infraestructura para beneficiarse de una cadena de reenvío cada vez más confiable.

Related RFCs