Nel marzo 2026, durante un test di routing interno, un team di deliverability di un ESP europeo constata che le sue email verso liste di distribuzione Mailman falliscono sistematicamente la verifica DKIM, nonostante le chiavi siano correttamente configurate. Il messaggio è legittimo, il dominio è pulito, la lista è opt-in. Ma Mailman ha riscritto l’header From e la firma DKIM1 è stata invalidata in quel preciso momento. DKIM2 cerca di correggere questo tipo di problema. Il gruppo di lavoro IETF dkim ha adottato le prime bozze del protocollo nel marzo 2026: non ancora un RFC, zero implementazioni in produzione, ma un’architettura che distribuisce la verifica lungo l’intero percorso di consegna.
Perchè DKIM1 raggiunge i suoi limiti nel 2026
DKIM1, formalizzato nella RFC 6376 nel 2011, copre un perimetro preciso: dimostra che il dominio firmatario ha effettivamente emesso il messaggio all’origine. La specifica non sopravvive agli intermediari. Ogni server che tocca il messaggio può invalidare la firma: una mailing list che aggiunge un piè di pagina, un gateway di sicurezza che riscrive le URL, un forwarder che modifica l’involucro SMTP. Con un’adozione di DKIM vicina al 90% sulle email dirette nel 2026, si potrebbe pensare che il problema sia risolto. Ma questo tasso misura il successo sulle email che arrivano direttamente, non quelle che transitano attraverso mailing list o forwarder.
La bozza IETF draft-ietf-dkim-dkim2-motivation documenta tre falle strutturali che DKIM1 non può correggere. Prima: un’email firmata validamente può essere ricevuta senza alcuna prova che il destinatario fosse quello previsto. Seconda: l’indirizzo di rimbalzo può riferirsi a domini che non hanno avuto alcun ruolo nel transito del messaggio. Terza: non esiste un meccanismo per documentare le modifiche legittime dei forwarder o delle mailing list. Queste lacune sono dovute alla concezione stessa del protocollo originale, non a errori di configurazione.
Dal 2024, Google e Yahoo hanno reso obbligatori SPF, DKIM e DMARC per gli invii di massa. Questa pressione ha accelerato l’adozione senza risolvere i problemi architetturali. Il lavoro è stato delegato al WG IETF dkim, che opera su diverse bozze complementari: specifica principale, documento di motivazione, profilo di implementazione tramite interfaccia Milter e guida alle migliori pratiche.
La chain of signatures: sopravvivere agli intermediari
Il meccanismo centrale di DKIM2 è chiamato catena di firme. Anziché chiedere a ogni server di validare una firma unica emessa all’origine, il protocollo chiede a ogni intermediario di documentare le modifiche che ha apportato e di firmare questa documentazione. Il destinatario finale ricostruisce così la sequenza completa delle trasformazioni e verifica la legittimità di ciascuna.
Richard Clayton, co-autore della specifica DKIM2, descrive l’approccio come una “algebra delle modifiche”: gli intermediari precisano la natura esatta delle loro modifiche al posto di apporre un semplice timbro di accettazione. Una mailing list che aggiunge un footer lo dichiara nella sua firma. Un gateway di sicurezza che riscrive delle URL fa altrettanto. Il destinatario valuta quindi se ogni trasformazione era prevista e autorizzata.
Sul campo, i falsi positivi legati alle liste di distribuzione, oggi fonte frequente di invalidazione DKIM1, escono dall’ambito di responsabilità del mittente. Clayton ha indicato nell’aprile 2026 che del codice funzionale esiste già e che dei test presso dei fornitori di caselle di posta sono attesi nei prossimi mesi. La specifica tecnica principale (draft-ietf-dkim-dkim2-spec-01) è datata 20 aprile 2026.
DSN asincroni e VERP: eliminare il backscatter
Il secondo aspetto tecnico di DKIM2 riguarda un problema meno visibile ma costoso per la reputazione dei mittenti: il backscatter. Quando uno spammer falsifica l’indirizzo di ritorno con il dominio di un terzo innocente, i bounces generati da server legittimi cadono nella casella di quest’innocente. IP e domini puliti si ritrovano in blacklist a causa di traffico che non hanno mai emesso.
Steve Atkins di Word to the Wise, che segue il dossier da diverse settimane, nota che DKIM2 risolve questo problema tramite due meccanismi combinati. Le Delivery Status Notifications (DSN) asincrone permettono a un server di accettare un messaggio in SMTP e poi notificare il fallimento successivamente, dopo un’analisi completa. VERP (Variable Envelope Return Path) codifica i metadati necessari direttamente nell’indirizzo di ritorno, evitando di dover analizzare il corpo del bounce. La combinazione dei due, secondo Word to the Wise del 27 aprile 2026, permette di “registrare il bounce immediatamente e ignorare il DSN asincrono senza alcun trattamento o archiviazione supplementare.”
Per i manager della deliverability, i bounces in DKIM2 seguono un percorso crittograficamente firmato, ritornando al server precedente nella catena anziché a un indirizzo falsificato. Il backscatter perde la sua principale superficie di attacco. Atkins avverte che i volumi di bounces asincroni potrebbero aumentare di diversi ordini di grandezza durante il dispiegamento iniziale. Un aumento della capacità inbound sarà necessaria dal lato ESP.
Anti-replay: timestamps e recipient binding
DKIM1 presenta una vulnerabilità conosciuta ma sottovalutata: il replay attack. Una firma DKIM valida può essere riutilizzata per inviare lo stesso messaggio a destinatari non previsti. L’attaccante recupera un’email legittima, ne conserva intatta la firma e la ridistribuisce su larga scala. I filtri antispam vedono una firma valida e lasciano passare.
DKIM2 chiude questa finestra tramite due meccanismi complementari. Le firme ora includono i dati del percorso SMTP: mittente e destinatario. Un messaggio firmato per alice@example.com non può essere rinviato a bob@example.com senza invalidare la firma. Dei flags controllano anche la distribuzione autorizzata del messaggio. Questo meccanismo di recipient binding, come sottolinea Al Iverson di SpamResource (che segue i lavori del WG IETF DKIM), potrebbe modificare la superficie d’attacco delle campagne di spam più sofisticate.
I timestamp completano il dispositivo. Una firma DKIM2 ha una validità temporale esplicita, che impedisce la riutilizzazione di un messaggio legittimo vecchio di diverse settimane in una campagna malevola. Iverson nota che le chiavi DKIM stesse non cambiano necessariamente con DKIM2. I mittenti potrebbero non dover fare alcuna modifica significativa dal lato DNS. Sono l’infrastruttura di verifica e la catena di firme che evolvono, non la configurazione dei mittenti.
Cosa DKIM2 non sostituisce: la qualità della lista
DKIM2 mette in sicurezza il percorso di consegna, senza cambiare nulla sulla qualità dei destinatari. Una firma che sopravvive agli intermediari, delle bounces instradate crittograficamente e una protezione contro il replay presuppongono che gli indirizzi di destinazione siano validi e coinvolti. Su una lista contenente il 20% di indirizzi non validi o inattivi, DKIM2 non migliora il tasso di inbox. Autentica meglio delle email che i filtri continueranno a respingere per altre ragioni.
I benchmark pubblici di deliverability pubblicati dai principali router convergono su questo punto: i tassi di inbox variano di più in funzione della qualità di coinvolgimento della lista che dei soli parametri di autenticazione. DKIM2 rinforza lo strato di autenticazione senza compensare una lista mal curata. La verifica degli indirizzi prima dell’invio resta il prerequisito di ogni pipeline di deliverability. Il protocollo mette in sicurezza il percorso una volta che i destinatari sono validati, mai a monte.
Confronto DKIM1 e DKIM2 sui criteri chiave
| Criterio | DKIM1 (RFC 6376) | DKIM2 (bozza IETF 2026) |
|---|---|---|
| Resistenza agli intermediari | Nessuna: ogni modifica invalida la firma | Chain of signatures: ogni intermediario documenta i suoi cambiamenti |
| Protezione anti-replay | Assente: una firma valida è riutilizzabile | Recipient binding + timestamps: firma legata al destinatario e a una finestra temporale |
| Gestione dei bounces | Bounces asincroni non criptografici, backscatter possibile | DSN async + VERP firmato: ritorno al server precedente nella catena |
| Mailing list e forwarder | Rottura sistematica della firma | Modifiche documentate tramite algebra delle modifiche, firma mantenuta |
| Visibilità RSSI | Limitata: nessuna tracciabilità delle modifiche di transito | Audit completo della catena di transito documentata |
| Stato | RFC pubblicata, distribuita dal 2011 | Bozza adottata dal WG IETF a marzo 2026, non ancora RFC |
Cosa monitorare prima del dispiegamento
Quattro documenti sono stati adottati dal WG IETF dkim: la specifica principale, un documento di motivazione (draft-ietf-dkim-dkim2-motivation), un profilo di implementazione tramite interfaccia Milter e una guida alle migliori pratiche. Tutti sono prefissati draft-ietf-dkim, il che indica che sono ufficialmente nella pipeline del working group, non proposte individuali.
- Monitoraggio della specifica principale: la draft-ietf-dkim-dkim2-spec scade a ottobre 2026. Il suo rinnovo o il suo avanzamento verso lo status di Proposed Standard sarà il primo segnale concreto di una traiettoria verso RFC.
- Test presso i fornitori di caselle di posta: Richard Clayton ha menzionato implementazioni presso fornitori di caselle di posta nei prossimi mesi. Gmail, Yahoo o Outlook che annunciassero il supporto DKIM2 cambierebbero immediatamente le priorità dal lato ESP.
- Infrastruttura inbound degli ESP: l’aumento atteso dei volumi di bounces asincroni durante il dispiegamento richiede una capacità inbound rinforzata. Gli ESP che prepareranno la loro infrastruttura in anticipo avranno meno pressione operativa.
- Politica di rimozione indirizzi: i bounces asincroni DKIM2 possono arrivare 24 ore o più dopo l’invio iniziale. Le regole di rimozione automatica dovranno essere riviste per integrare questo ritardo senza generare falsi positivi nelle liste di disiscrizione.
Al Iverson ricorda nell’aprile 2026 che la specifica non è ancora finalizzata e che i dettagli sono soggetti a cambiamenti. Il WG IETF ha organizzato sessioni interim nel 2026 per accelerare i lavori. L’agenda del meeting interim del 29 aprile 2026 documenta le bozze in corso di revisione.
Per seguire l’avanzamento in tempo reale: abbonatevi alla lista di distribuzione ietf-dkim@ietf.org e verificate lo stato delle bozze su datatracker.ietf.org/group/dkim, l’arena dove si decide il calendario effettivo di DKIM2.
