ARC (Authenticated Received Chain): autenticación a través de reenviadores y listas de correo

Qué es ARC (Authenticated Received Chain), por qué importa cuando un mensaje pasa por reenviadores o listas, cómo se firma y cómo verificarlo en cabeceras.

DMARC, DKIM y SPF funcionan razonablemente bien en envíos directos: tu servidor manda el mensaje al servidor del destinatario y este verifica las firmas. El problema aparece cuando hay un intermediario por medio: una lista de correo, un reenviador automático, un alias corporativo, un servicio antispam que reescribe cabeceras. Ese intermediario rompe SPF (porque la IP que entrega ya no es la tuya), a veces rompe DKIM (si modifica el cuerpo) y por tanto rompe DMARC. ARC nace para preservar el resultado de autenticación original a través de esos saltos.

Qué es ARC y qué problema resuelve

ARC, de Authenticated Received Chain, es una extensión que permite a un servidor intermedio “sellar” el resultado de autenticación que vio cuando recibió el mensaje, de forma que el siguiente salto pueda confiar en ese sello aunque las firmas originales se hayan invalidado.

El caso típico:

1. marketing.example.com envía un boletín a [email protected].
2. SPF, DKIM y DMARC pasan en listas.org.
3. listas.org reenvía el mensaje a los suscriptores, modificando el asunto ([Lista] ...) y añadiendo un footer.
4. Cuando llega a Gmail, DKIM falla (cuerpo modificado) y SPF falla (la IP es la de listas.org, no la de marketing.example.com).
5. DMARC con política reject haría que Gmail descarte el mensaje.

Sin ARC, el destinatario solo ve un fallo y no puede saber si el origen estaba bien autenticado. Con ARC, listas.org añade tres cabeceras que dicen: “yo recibí este mensaje y la autenticación original era correcta”. Gmail puede entonces aplicar política suave aunque DMARC final falle, basándose en la confianza que tiene en listas.org como reenviador.

Las tres cabeceras de ARC

ARC añade siempre estas tres cabeceras en cada salto:

• ARC-Authentication-Results: copia del Authentication-Results que el intermediario calculó al recibir el mensaje.
• ARC-Message-Signature: firma criptográfica del cuerpo y cabeceras tal y como las vio el intermediario, similar a DKIM.
• ARC-Seal: firma de toda la cadena ARC anterior, encadenando saltos.

Cada salto incrementa el contador i= (instance), de forma que el receptor final puede recorrer la cadena: i=1 es el primer intermediario, i=2 el segundo, etc. Si la cadena está rota (un salto firmó mal), el receptor ignora ARC y vuelve a la lógica de DMARC pura.

Ejemplo de cabeceras

Un mensaje que pasa por una lista típica termina con algo así:

ARC-Seal: i=1; a=rsa-sha256; cv=none; d=listas.org; s=arc20240101;
    b=Hf3kR2L9aB...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
    d=listas.org; s=arc20240101; h=from:to:subject:date:message-id;
    bh=8aBxK...; b=2dFG7p...
ARC-Authentication-Results: i=1; mx.listas.org;
    spf=pass smtp.mailfrom=marketing.example.com;
    dkim=pass header.d=marketing.example.com;
    dmarc=pass header.from=marketing.example.com

El receptor final lee la última cadena ARC válida y obtiene la información que listas.org certificó al recibir el mensaje original.

Quién implementa ARC y por qué

ARC es relevante para:

• Operadores de listas de correo: necesitan poder reenviar mensajes con DMARC reject sin que se descarten.
• Reenviadores automáticos: alias corporativos que apuntan a buzones externos.
• Servicios antispam en línea: gateways que reciben, filtran y reentregan.
• Plataformas de colaboración: Google Workspace, Microsoft 365, que actúan como intermediarios cuando hay reglas de reenvío.

Si solo envías directamente a destinatarios finales, ARC no es algo que implementes tú: es algo que tus destinatarios o intermediarios usan. Pero entender ARC te ayuda a diagnosticar por qué un mensaje legítimo se filtró tras pasar por una lista.

Relación con DMARC

ARC no sustituye a DMARC: lo complementa cuando hay intermediarios. La política DMARC sigue siendo la que tú publicas en _dmarc.tudominio.com. Lo que cambia es que el receptor final, si encuentra una cadena ARC válida y confía en el último firmante, puede decidir aplicar la política original (la que se evaluó en el primer salto) en lugar de fallar por una rotura derivada del reenvío.

Por eso conviene tener:

• DMARC bien configurado en el origen.
• DKIM con claves modernas para que la firma sobreviva a transformaciones leves.
• SPF correcto para que el primer salto registre pass.

Si tu autenticación de origen falla, ARC no la inventa: solo preserva lo que había.

Verificar ARC en un mensaje recibido

Lo más rápido es abrir las cabeceras crudas del mensaje en tu cliente y buscar ARC-. Si hay tres cabeceras (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results) por cada salto, hay cadena ARC. Si no aparecen, el intermediario no implementa ARC.

En Gmail, el bloque Authentication-Results final suele incluir arc=pass cuando la cadena se valida correctamente:

Authentication-Results: mx.google.com;
    dkim=fail header.d=marketing.example.com;
    spf=fail smtp.mailfrom=listas.org;
    dmarc=fail header.from=marketing.example.com;
    arc=pass (i=1 spf=pass dkim=pass dmarc=pass)

Aquí Gmail dice: DMARC final falla, pero ARC certifica que en el origen pasó todo. Aplicará la política con margen.

Para análisis sistemático, la guía de análisis de cabeceras cubre cómo leer cada bloque.

Implementar ARC en un servidor propio

La mayoría de MTAs modernos soportan ARC vía módulos:

• Postfix: vía OpenARC (opendkim y openarc en pipeline de milter).
• Exim: soporte nativo desde 4.93.
• Rspamd: módulo arc que firma a la salida.

Configuración tipo en OpenARC:

Domain      listas.org
Selector    arc20260101
KeyFile     /etc/openarc/keys/arc20260101.private
Mode        sv

Necesitas publicar el selector como TXT en arc20260101._domainkey.listas.org, igual que DKIM:

arc20260101._domainkey.listas.org. IN TXT "v=DKIM1; k=rsa; p=MIIBIj..."

Y verificar con:

dig +short TXT arc20260101._domainkey.listas.org

A partir de ahí, el milter firma cada mensaje saliente con cadena ARC y propaga el Authentication-Results que vio al recibir.

Errores frecuentes

Confiar en ARC sin DMARC bien hecho en origen

Si el mensaje original no autentica, ARC solo certifica el fallo. No hay magia: ARC propaga, no construye autenticación de la nada.

No firmar SPF/DKIM/DMARC antes de operar listas

Si una lista que reenvía a Gmail no firma con DKIM ni publica SPF de su dominio, los receptores no tendrán nada que validar como sello ARC. Mínimo: DKIM en el dominio de la lista.

Cadena ARC rota por modificación posterior

Si tras firmar ARC, el mensaje se vuelve a transformar (por ejemplo, otro filtro reescribe cabeceras), la firma se invalida. Hay que firmar ARC al final de la cadena de transformaciones, no en medio.

Selector ARC sin publicar en DNS

Igual que DKIM, si el selector ARC no está publicado, los receptores no pueden validar la firma. Resultado: cadena ARC con cv=fail ignorada.

Asumir que ARC arregla problemas de reputación

ARC ayuda con autenticación, no con reputación de dominio ni con quejas. Un dominio con reputación Low seguirá filtrado a spam aunque ARC valide perfectamente.

Cuándo no usar ARC

Si tu plataforma no es un intermediario, no necesitas firmar ARC. Solo añade cabeceras inútiles. ARC es para:

• Operadores de listas de correo.
• Servicios de reenvío.
• Gateways antispam que reentregan.

Para envíos directos desde tu ESP, lo relevante sigue siendo SPF + DKIM + DMARC alineados, y el trabajo está en la consola de tu plataforma, no en ARC.

Recursos relacionados

Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.

¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de email marketing para ecommerce de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.