ARC passa allo stato « Historic » presso l'IETF: bisogna ancora preoccuparsene nel 2026?
Di CaptainDNS
Pubblicato il 8 giugno 2026
- L'IETF riclassifica ARC (RFC 8617) come stato « Historic » tramite il draft
draft-ietf-dmarc-arc-to-historicdepositato il 22 aprile 2026, dopo il rinnovo del mandato del gruppo DMARC il 16 aprile 2026. - No, non si tratta di « uno strumento che rimuove ARC »: la fonte è una decisione di standardizzazione dell'IETF, non un produttore di software.
- « Historic » scoraggia i nuovi deployment e la fiducia tra domini terzi. Non invalida RFC 8617 e non obbliga nessuno a smettere di verificare le catene esistenti.
- ARC resta richiesto nella pratica nel 2026: iCloud (grandi mittenti), forwarder Gmail (
arc=pass), Microsoft 365 (trusted sealer, reason code 130). - Se siete proprietari di un dominio, probabilmente non dovete fare nulla su ARC: rafforzate SPF, DKIM e DMARC, monitorate i vostri report, tenete d'occhio DKIM2.
Un titolo circola da fine aprile 2026: « ARC is dead ». Sui forum e in alcune newsletter si legge già che un certo strumento diagnostico « rimuove ARC », che il protocollo sarebbe abbandonato, che bisognerebbe riconfigurare tutto. La realtà è più tranquilla, e soprattutto più sfumata. ARC non scompare da un giorno all'altro, e la notizia non viene da alcun produttore di software.
La fonte esatta è un documento dell'IETF: il draft draft-ietf-dmarc-arc-to-historic, depositato il 22 aprile 2026 da J. Trent Adams (Proofpoint) e John Levine. Propone di riclassificare la RFC 8617, che specifica ARC, come stato « Historic ». È una decisione del processo di standardizzazione, presa all'interno del gruppo di lavoro DMARC appena rinnovato. Nulla a che vedere con un provider che disattiva una funzionalità.
Questa guida non rispiega in profondità la meccanica di ARC (gli header di sigillo, la catena di risultati). Per questo, leggete il nostro articolo di approfondimento Che cos'è ARC (Authenticated Received Chain)?. Qui l'obiettivo è decisionale: cosa cambia davvero « Historic », perché l'IETF ha deciso, e cosa dovete fare a seconda del vostro ruolo. Il più delle volte, la risposta sta in una parola: nulla, almeno nulla di specifico per ARC. Questo articolo si rivolge agli amministratori di posta, ai team DevOps e ai responsabili della deliverability che hanno letto un titolo allarmistico e vogliono una decisione chiara.
Verificate la vostra autenticazione email invece di aggiungere ARC
La notizia, spiegata correttamente: ARC verso « Historic » presso l'IETF
Cominciamo col fissare i fatti, perché la diceria ha già distorto l'essenziale. Nessuno strumento « rimuove » ARC. Quello che sta accadendo è un cambio di stato documentale presso l'IETF, l'ente che standardizza i protocolli di Internet.
Cosa dice il draft draft-ietf-dmarc-arc-to-historic?
Il draft draft-ietf-dmarc-arc-to-historic è un documento breve il cui unico scopo è chiedere la riclassificazione della RFC 8617 (la specifica di ARC, pubblicata nel 2019) dallo stato attuale verso lo stato « Historic ». È stato depositato il 22 aprile 2026 da J. Trent Adams, di Proofpoint, e John Levine, due contributori di lunga data degli standard di posta.
Un documento del genere non modifica il contenuto tecnico di ARC. Non riscrive il protocollo, non aggiunge né rimuove alcun header. È un « status-change document »: registra una constatazione della comunità sul posto che ARC deve occupare ormai nel panorama degli standard. La motivazione sta in una frase: l'adozione e la fiducia tra domini che ARC presupponeva non si sono mai materializzate alla scala attesa, e lo sforzo di standardizzazione si concentra ormai altrove.
Calendario: rinnovo del mandato del gruppo DMARC e scadenza
Questa iniziativa si inserisce in una riorganizzazione. Il gruppo di lavoro DMARC dell'IETF ha ricevuto un nuovo mandato il 16 aprile 2026, qualche giorno prima del deposito del draft. Un rinnovo del mandato ridefinisce il perimetro e le priorità di un gruppo; qui segnala che la comunità vuole chiudere certi cantieri e aprirne altri.
Il draft di riclassificazione segue poi il processo abituale: discussione nel gruppo, appello a un ultimo commento (« last call »), poi revisione da parte dell'IESG. La scadenza prevista per finalizzare lo status-change è intorno a novembre 2026. Finché il processo non è concluso, RFC 8617 conserva formalmente il suo stato attuale; ma la traiettoria è chiara e pubblica.
Cosa significa davvero « Historic » (e cosa non significa)
La parola « Historic » suona come un atto di morte. Nel vocabolario dell'IETF (definito dal processo della RFC 2026), ha un senso molto più preciso e molto meno drammatico.
« Historic » qualifica uno standard che non è più raccomandato, generalmente perché è stato sostituito, perché la sua adozione non ha tenuto il passo, o perché l'esperienza ne ha mostrato i limiti. Concretamente, lo stato Historic vuol dire questo:
- scoraggia i nuovi deployment del protocollo;
- segnala che la comunità non punta più su questo meccanismo per il futuro;
- invita a non costruire nuove dipendenze tra domini fondate su questo protocollo.
Al contrario, « Historic » non vuol dire questo:
- non è un'invalidazione: RFC 8617 resta un documento pubblicato e leggibile, i suoi header restano sintatticamente validi;
- non è un divieto: nessuno è obbligato a smettere di produrre o di verificare le catene ARC esistenti;
- non è un interruttore: nessun server smette di funzionare perché un draft viene depositato.
Questa distinzione è il cuore dell'articolo. Deprecato sulla carta non significa morto nella pratica. Il seguito lo dimostra.
Perché questo cambio di rotta? Le ragioni dell'IETF
ARC è stato concepito per risolvere un problema reale e persistente: l'inoltro della posta rompe l'autenticazione. L'idea era elegante. Perché allora la comunità lo colloca oggi tra gli standard storici? Tre ragioni si combinano.
Un'adozione limitata e una fiducia fragile
ARC si basa su un'ipotesi forte: che un destinatario si fidi del sigillo apposto da un intermediario che non controlla. Ma questa fiducia non si decreta. Nella pratica, solo alcuni grandissimi attori hanno pubblicato e mantenuto liste di « sealer di fiducia », e il coordinamento tra domini su larga scala non si è mai instaurato. Un meccanismo il cui valore dipende da una fiducia generalizzata perde interesse quando quella fiducia resta confinata a una manciata di operatori.
Una falla di fondo che ARC non chiude
ARC documenta una catena di risultati di autenticazione, ma non protegge dal replay (riutilizzo abusivo). Un messaggio legittimamente firmato può essere catturato e poi ritrasmesso in massa senza che la firma venga invalidata, perché né DKIM né ARC legano la firma alla busta né al percorso reale del messaggio. ARC aggiunge tracciabilità, non una garanzia di integrità end-to-end. La comunità ha finito per considerare che investire ulteriormente in ARC equivalesse a consolidare un cerotto invece di curare la ferita.
Uno sforzo che si concentra sul successore
L'IETF preferisce orientare il lavoro verso un meccanismo che affronta la causa, piuttosto che continuare a raffinare ARC. Questo successore è DKIM2, in corso di standardizzazione, che firma sia la sorgente sia la destinazione di ogni salto e chiude la falla del replay. Riclassificare ARC come Historic è anche un segnale di rotta: non spendete più energie per estendere ARC, guardate verso DKIM2. Ci torniamo a fine articolo.
Il paradosso: ARC resta richiesto nella pratica nel 2026
Ecco ciò che i titoli allarmistici dimenticano. Proprio mentre l'IETF colloca ARC tra gli standard storici, i tre maggiori provider di posta al mondo lo usano attivamente. Per una casella di posta, ARC è ben vivo.
Apple e iCloud: ARC per i grandi mittenti
Dal 25 febbraio 2025, Apple applica requisiti rafforzati per i mittenti ad alto volume verso iCloud. La sua documentazione descrive esplicitamente l'uso di ARC per preservare i risultati di autenticazione quando un messaggio transita per un intermediario prima di raggiungere una casella iCloud. In altre parole, un provider che ritrasmette posta verso iCloud e che sigilla correttamente la catena ARC vede il proprio traffico trattato meglio rispetto a chi non lo fa.
Google e Gmail: i forwarder firmano, Gmail legge arc=pass
Gmail è senza dubbio il maggiore utilizzatore di ARC al mondo. Quando un messaggio viene inoltrato (redirezione automatica, alias, mailing list che passa per l'infrastruttura Google), i forwarder di Google appongono header ARC. In ricezione, Gmail legge il risultato arc=pass per riconoscere che l'autenticazione di origine era valida prima dell'inoltro, ed evita così di far fallire DMARC su un messaggio legittimo solo perché è stato relayato. ARC è qui un ingranaggio quotidiano della deliverability, invisibile ma determinante.
Microsoft 365: trusted sealer e reason code 130
Microsoft 365 integra ARC nel suo verdetto di autenticazione composito. Quando un messaggio sarebbe fallito in DMARC a causa di un inoltro, ma un « trusted sealer » ARC ha preservato i risultati di origine, Exchange Online Protection può recuperare il messaggio e inserisce il reason code 130 nel suo header compauth. Questo codice segnala precisamente che un sigillo ARC di fiducia ha sostituito un fallimento DMARC. Il meccanismo dei trusted sealer, del reason code 130 e dell'indicatore oda=1 è dettagliato nella nostra guida Compauth=fail su Microsoft 365.
Deprecato sulla carta, non morto nella casella di posta
Il contrasto è netto. Presso l'IETF, ARC diventa « Historic ». Nelle infrastrutture di Apple, Google e Microsoft, ARC resta un segnale letto e sfruttato ogni giorno. Questi due fatti non si contraddicono. Lo stato Historic dice « non costruite più nuove dipendenze da ARC e non contateci per il futuro »; non dice « smettete immediatamente di trattare le catene ARC che i grandi operatori producono ancora ». Confondere i due significa leggere un draft di standardizzazione come un comunicato di interruzione del servizio.
Il problema di fondo non è scomparso: l'inoltro rompe SPF, DKIM e DMARC
Se ARC è giudicato insufficiente, il problema che mirava a risolvere resta intatto. Capire questo problema aiuta a decidere cosa dovete fare (o non fare).
Perché una redirezione o una mailing list rompe l'autenticazione?
L'inoltro della posta mette in difficoltà i tre pilastri dell'autenticazione, ciascuno a modo suo.
SPF fallisce perché verifica l'indirizzo IP mittente rispetto al dominio della busta. Quando un server di redirezione ritrasmette il messaggio, è il suo IP a presentarsi al destinatario, e questo IP non è quasi mai dichiarato nello SPF del dominio di origine. Risultato: SPF non si allinea più.
DKIM fallisce non appena l'intermediario modifica il messaggio. Una mailing list che aggiunge un piè di pagina, riscrive l'oggetto con un prefisso [Lista] o ritocca un header rompe l'hash firmato. La firma DKIM, che copre il corpo e alcuni header, diventa invalida.
DMARC, che si basa sull'allineamento di SPF o di DKIM con il dominio del From:, fallisce quindi a sua volta non appena entrambi si rompono simultaneamente. Un messaggio perfettamente legittimo si ritrova in dmarc=fail dopo un semplice inoltro. È a questo scenario, frequente, che ARC cercava di porre rimedio trasportando la prova che l'autenticazione era valida prima del relay.
ARC era un cerotto, non una cura
ARC non ha mai riparato SPF né DKIM. Ha aggiunto uno strato di testimonianza: « nel momento in cui ho ricevuto questo messaggio, ecco i risultati di autenticazione che ho constatato, e li sigillo ». Utile, ma condizionato alla fiducia che il destinatario accorda al sigillatore, e impotente di fronte al replay. È proprio per questo che la risposta duratura non consiste nell'accumulare ARC, ma nel rafforzare ciò che controllate davvero: la vostra stessa autenticazione. Il futuro standard DMARCbis, che dettagliamo nella guida DMARCbis, chiarisce d'altronde l'allineamento e la gestione delle policy, senza far dipendere la vostra conformità da un meccanismo terzo.
Chi deve fare cosa: proprietario di dominio o intermediario?
Questa è la sezione più importante per decidere. La confusione più diffusa consiste nel credere che tutti « implementino ARC ». Falso. ARC è un meccanismo da intermediario. La grande maggioranza dei lettori di questo articolo non ha mai avuto, e non avrà mai, bisogno di implementarlo.
Siete proprietari di un dominio: non implementate ARC
Se gestite l'invio di posta per la vostra organizzazione (un sito, un negozio, notifiche transazionali, un team commerciale), siete proprietari di un dominio, non un intermediario. Non sigillate catene ARC, e lo stato Historic non vi chiede alcuna azione su ARC. Ciò che dovete fare riguarda la vostra stessa autenticazione:
- Rafforzate SPF. Dichiarate tutte le vostre fonti di invio, monitorate il limite di 10 query DNS che provoca un
permerror, e fate evolvere il meccanismo finale da~alla-allquando padroneggiate le vostre fonti. - Consolidate DKIM. Firmate tutti i vostri flussi con una chiave allineata al vostro dominio, e organizzate una rotazione regolare delle chiavi.
- Fate progredire DMARC. Passate da
p=none(osservazione) a una policy di applicazione (p=quarantinepoip=reject) una volta che le vostre fonti sono sotto controllo. - Monitorate i vostri report DMARC. I report aggregati rivelano con precisione cosa si rompe all'inoltro e quali fonti falliscono. È la vostra dashboard.
- Non aggiungete ARC come cerotto. Non potete « attivare ARC » per riparare un inoltro subìto a valle: il sigillo spetterebbe all'intermediario, non a voi. Concentrate lo sforzo su ciò che controllate.
Per verificare lo stato reale della vostra autenticazione e il modo in cui i vostri messaggi vengono ricevuti, un test di deliverability vale più di una supposizione; la nostra guida al test di deliverability spiega come leggere i risultati.
Siete un intermediario: continuate a sigillare ARC
Se gestite un servizio che ritrasmette posta per conto altrui (un forwarder, una piattaforma di mailing list, un gateway di sicurezza, un provider di redirezione), siete interessati da ARC, e la vostra condotta da tenere è sfumata.
Anzitutto, non interrompete nulla bruscamente. Apple, Google e Microsoft leggono ancora le catene ARC per recuperare messaggi legittimi inoltrati. Smettere di sigillare da un giorno all'altro degraderebbe la deliverability della posta che relayate verso questi destinatari. Lo stato Historic non vi obbliga affatto a fermarvi.
Poi, leggete Historic come un'indicazione di rotta, non di arresto. Non costruite nuove dipendenze da ARC che presuppongano una fiducia tra domini generalizzata, non investite in estensioni ARC ambiziose, e preparate la transizione verso il successore. Monitorate l'evoluzione del processo IETF e gli annunci dei grandi destinatari: sono loro che, nella pratica, fisseranno il ritmo reale dell'uscita di scena di ARC.
E poi? DKIM2, il successore
Riclassificare ARC come Historic ha senso solo perché arriva uno strumento migliore. Questo successore è DKIM2.
Che cosa corregge DKIM2
DKIM2 cambia l'approccio. Là dove DKIM firma il contenuto e dove ARC aggiunge una testimonianza sigillata, DKIM2 fa firmare ogni salto SMTP legando la sorgente e la destinazione del messaggio. Ogni relay aggiunge la propria firma numerata, e la busta usata a ogni salto è coperta. Conseguenza diretta: il replay, quella falla che nessuno dei due meccanismi precedenti chiudeva, diventa rilevabile, perché un messaggio ritrasmesso fuori dal suo percorso firmato non corrisponde più alla catena attesa. DKIM2 affronta la causa là dove ARC trattava il sintomo.
Calendario e cosa cambia per voi
DKIM2 è ancora allo stadio degli Internet-Draft presso l'IETF. La sintassi esatta degli header e dei parametri può cambiare, e i primi deployment sono attesi solo a partire dalla fine del 2026. Per voi, proprietari di dominio, questo non richiede alcuna azione oggi: non c'è nulla da pubblicare né da configurare per DKIM2 al momento. La giusta postura è la vigilanza. Capire i principi, seguire i draft, e mantenere un'infrastruttura DKIM sana, perché DKIM2 si appoggerà sulle stesse fondamenta DNS. Il nostro articolo DKIM2: novità, rimozioni e date chiave dettaglia i nuovi header e la cronologia dei draft.
Conclusione: panico evitato, rotta su DKIM2
La notizia è reale ma benigna. L'IETF riclassifica ARC come « Historic »: un segnale di fine ciclo, non un'interruzione del servizio. Ricapitoliamo a seconda del vostro ruolo.
Se siete proprietari di un dominio, non dovete fare nulla su ARC, né ieri né oggi. Rafforzate SPF, DKIM e DMARC, monitorate i vostri report, e non aggiungete mai ARC come cerotto.
Se siete un intermediario, continuate a sigillare ARC finché Apple, Google e Microsoft lo leggono, ma non costruite più nuove dipendenze su di esso e preparate la transizione.
E per tutti, la rotta è la stessa: la prossima tappa dell'autenticazione email si chiama DKIM2. Nulla da fare oggi, tutto da capire per domani.
FAQ
ARC è morto o abbandonato nel 2026?
No. L'IETF riclassifica ARC (RFC 8617) come stato « Historic » tramite il draft draft-ietf-dmarc-arc-to-historic depositato il 22 aprile 2026. « Historic » scoraggia i nuovi deployment e segnala che la comunità non punta più su ARC per il futuro, ma non invalida la specifica e non obbliga nessuno a smettere di produrre o di verificare le catene ARC. Nella pratica, Apple, Google e Microsoft lo usano ancora attivamente.
Bisogna ancora implementare ARC nel 2026 se non lo si ha già?
Per la grande maggioranza delle organizzazioni, no. ARC è un meccanismo da intermediario (forwarder, mailing list, gateway), non un protocollo che i proprietari di dominio pubblicano da soli. Se gestite l'invio di posta per la vostra organizzazione, non avete mai avuto bisogno di implementare ARC, e lo stato Historic non cambia nulla in questo. Concentratevi su SPF, DKIM e DMARC.
Ho già implementato ARC su un forwarder o un gateway: devo rimuoverlo?
No, non interrompete nulla bruscamente. Apple, Google e Microsoft leggono ancora le catene ARC per recuperare messaggi legittimi inoltrati. Smettere di sigillare degraderebbe la deliverability della posta che relayate verso questi destinatari. Lo stato Historic vi invita solo a non costruire nuove dipendenze da ARC e a preparare la transizione verso DKIM2, non a fermarvi immediatamente.
Bisogna continuare a verificare gli header ARC in ricezione?
Sì, se gestite un destinatario che si appoggia già su ARC. Lo stato Historic non chiede di smettere di verificare le catene esistenti. I grandi provider continuano a leggere arc=pass per evitare di far fallire DMARC su messaggi inoltrati legittimi. Finché queste catene circolano, ignorarle penalizzerebbe posta legittima.
ARC contro DKIM2: cosa sostituisce ARC, e quando?
Il successore è DKIM2, in corso di standardizzazione presso l'IETF. A differenza di ARC che aggiunge una testimonianza sigillata senza chiudere la falla del replay, DKIM2 fa firmare ogni salto legando la sorgente e la destinazione, il che rende il replay rilevabile. DKIM2 è ancora allo stadio dei draft; i primi deployment sono attesi solo a partire dalla fine del 2026. Nessuna azione è richiesta oggi, solo vigilanza.
RFC 8617 verrà rimosso o diventerà invalido con lo stato Historic?
No. Lo stato « Historic » nel senso del processo IETF non rimuove né invalida un documento. RFC 8617 resta pubblicato, leggibile e tecnicamente valido: gli header ARC restano sintatticamente corretti e le implementazioni esistenti continuano a funzionare. Historic è un segnale documentale che scoraggia i nuovi usi, non un ritiro della specifica.
ARC risolveva il problema dell'inoltro che rompe DMARC: questo problema è risolto in altro modo?
Non ancora completamente. L'inoltro rompe SPF (l'IP del relay non è nello SPF di origine) e spesso DKIM (modifica del corpo o degli header), quindi DMARC fallisce. ARC era un cerotto che trasportava la prova di autenticazione di prima del relay. La risposta duratura consiste nel rafforzare i vostri stessi SPF, DKIM e DMARC, nel monitorare i vostri report, e nel seguire DKIM2, che affronta la causa firmando ogni salto.
« Historic » presso l'IETF: cosa cambia concretamente per un amministratore?
Per un amministratore di dominio, nel breve termine: nulla. Non implementate ARC, quindi lo stato non tocca la vostra configurazione. Ciò che conta è la rotta: non puntate su ARC per nuovi progetti, rafforzate la vostra stessa autenticazione, e preparatevi mentalmente a DKIM2. Per un operatore intermediario, il cambiamento è un'indicazione di traiettoria, non un ordine di arresto immediato.
Scarica le tabelle comparative
Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.
📖 Glossario
- Historic (stato IETF): classificazione del processo di standardizzazione (RFC 2026) che indica che un protocollo non è più raccomandato per nuovi deployment, senza essere invalidato né vietato.
- RFC 8617: la specifica di ARC (Authenticated Received Chain), pubblicata nel 2019.
- ARC (Authenticated Received Chain): meccanismo con cui un intermediario sigilla i risultati di autenticazione osservati prima di ritrasmettere un messaggio.
- Trusted sealer: intermediario la cui firma ARC è considerata affidabile da un destinatario, per esempio Microsoft 365.
- Replay (riutilizzo abusivo): reinvio indebito di un messaggio legittimamente firmato, ritrasmesso senza invalidare la firma; falla che ARC non chiude e che DKIM2 mira a correggere.
- DKIM2: successore in corso di standardizzazione presso l'IETF, che firma la sorgente e la destinazione di ogni salto per resistere al replay e all'inoltro.
