ARC: mantenere la fiducia in un'email quando passa per intermediari

In sintesi: ARC (Authenticated Received Chain) è uno standard che permette ai relay (mailing list, gateway antispam, inoltri, ecc.) di preservare e sigillare i risultati di autenticazione (SPF, DKIM, DMARC) che hanno osservato. Il destinatario può così decidere in modo informato se fidarsi del messaggio anche quando SPF/DKIM falliscono legittimamente dopo una modifica o un inoltro.

Perché abbiamo bisogno di ARC?

Senza ARC, un messaggio legittimo può essere rifiutato dopo un inoltro:

• SPF fallisce perché l'IP mittente diventa quello del relay;
• la firma DKIM originale può invalidarsi se il relay modifica header o corpo (banner, footer, marcatura antispam);
• di conseguenza DMARC fallisce lato destinatario, anche se l'email era corretta all'origine.

ARC consente al relay di affermare: «Ho ricevuto un messaggio che ha superato SPF/DKIM/DMARC; ecco i miei risultati e li sto firmando.»
Il server finale esamina la catena di sigilli per decidere se l'email resta affidabile.

Come funziona ARC (panoramica)

A ogni relay vengono aggiunti tre header ARC con un indice i=1, i=2, …:

1. ARC-Authentication-Results (AAR) — copia i risultati SPF/DKIM/DMARC come osservati dal relay.
2. ARC-Message-Signature (AMS) — firma crittografica del messaggio visto dal relay (analoga a DKIM).
3. ARC-Seal (AS) — un sigillo che firma l'insieme (AAR + AMS + sigilli precedenti) per incatenare la fiducia.

Esempio di header ARC (semplificato)

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=: posizione nella catena (1 al primo relay, poi +1 per ogni hop).
• d= / s=: dominio e selector (come in DKIM) usati per pubblicare la chiave pubblica DNS.
• cv= (in ARC-Seal): Chain Validation dichiarata dal relay per la catena che vede; valori comuni: none, pass, fail.
• h=, bh=, b=: campi standard della firma (elenco di header firmati, hash del corpo, firma).

«Vedo header ARC senza inoltri, è normale?»

Sì. Molti grandi provider (webmail, suite collaborative, gateway di sicurezza) firmano sistematicamente con ARC il traffico in ingresso.
Obiettivi: fissare un punto di verità interno, tracciare il passaggio nella loro infrastruttura e facilitare eventuali inoltri successivi senza perdere fiducia.

Come valuta il destinatario la catena ARC?

1. Verificare tutte le firme ARC-Message-Signature e ARC-Seal, partendo dall'i più alto.
2. Controllare la continuità: nessun i mancante; ogni sigillo deve coprire i precedenti.
3. Osservare cv= nell'ultimo ARC-Seal (la dichiarazione del firmatario sulla catena).
4. Incrociare con DMARC: se gli SPF/DKIM attuali falliscono, valutare se dare credito ai risultati registrati in ARC-Authentication-Results affidabili.

Importante: ARC non obbliga ad accettare un messaggio; fornisce contesto verificabile per una decisione più precisa lato destinatario.

Buone pratiche (lato operatore)

• Firmare e verificare ARC sui propri relay (liste, alias, gateway di sicurezza).
• Conservare gli header ARC esistenti; non rimuovere sigilli validi.
• Gestire le chiavi (rotazione, TTL DNS, monitoraggio degli errori di verifica).
• Limitare le modifiche al messaggio dopo il sigillo (banner, riscritture) oppure sigillare di nuovo dopo la modifica.
• Registrare le decisioni DMARC influenzate da ARC per misurarne l'impatto.

Errori comuni

• Aggiungere un ARC-Authentication-Results senza ARC-Message-Signature e ARC-Seal.
• Spezzare la catena (indice i duplicato/mancante, sigillo che non copre il precedente).
• Fidarsi ciecamente di qualunque dominio d= sconosciuto. La reputazione del firmatario conta.

Domande frequenti

ARC sostituisce DKIM/DMARC?
No. ARC completa SPF/DKIM/DMARC preservando i risultati osservati dai relay.

Chi può aggiungere ARC?
Qualsiasi intermediario di trasporto (MTA, gateway, servizio email) che gestisce il messaggio.

Cosa significa esattamente cv=?
È la dichiarazione del firmatario sullo stato della catena che vede: none (nessuna catena precedente), pass (catena coerente e verificabile), fail (catena non valida). Il destinatario esegue comunque la propria validazione.

Perché lo stesso messaggio ha più i=?
Ogni relay incrementa i e aggiunge il proprio trittico AAR/AMS/AS.

Per approfondire

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

---

Promemoria rapido

• Obiettivo: preservare e sigillare i risultati SPF/DKIM/DMARC lungo i relay.
• 3 header: ARC-Authentication-Results (risultati) + ARC-Message-Signature (firma del messaggio) + ARC-Seal (sigillo della catena).
• Decisione del destinatario: firme valide + reputazione del firmatario + policy DMARC interna.