DKIM2: cosa c'è di nuovo, cosa cambia e le date chiave

⚡TL;DR

TL;DR — DKIM2 è una riscrittura attualmente in lavorazione come Internet-Drafts all'IETF. L'obiettivo è firmare l'origine e la destinazione di ogni hop SMTP, concatenare le firme (i=1, i=2, ...), documentare le modifiche introdotte dagli intermediari e rendere i bounce (DSN) tracciabili lungo la catena. DKIM2 non è ancora uno standard: si evolve velocemente, ma i mattoni principali sono già presenti.

ℹ️ I termini DKIM replay e backscatter sono spiegati nel glossario alla fine dell'articolo.

Perché parlare di DKIM2 adesso?

DKIM (STD 76, RFC 6376) è ampiamente distribuito per firmare il contenuto delle email. Tuttavia mostra i suoi limiti contro il DKIM replay, le modifiche applicate da mailing list/forwarder e il backscatter (bounce inviati a terzi). DKIM2 propone un modello in cui ogni relay aggiunge la propria firma numerata e dichiara esplicitamente la coppia origine → destinazione dell'hop successivo, permettendo di:

• individuare e limitare i replay;
• inoltrare bounce e report lungo il percorso autenticato;
• descrivere e, quando possibile, annullare le modifiche a body/header per verificare la firma originaria.

Novità principali (rispetto a DKIM "v1")

1. Nuovo header DKIM2-Signature (senza campo versione)

   • Numerazione con i= (1, 2, ...). Un vuoto nella sequenza invalida la catena.
   • Timestamp t=; un verificatore può considerare una firma scaduta dopo una finestra (es. 14 giorni).
   • Algoritmi: previsti RSA-SHA256 ed Ed25519-SHA256, con agilità crittografica pianificata.
   • Chiavi nel DNS: come in DKIM, sotto selector._domainkey.dominio.

2. Concatenazione e allineamento con l'envelope SMTP

   • mf= (MAIL FROM) e rt= (RCPT TO) descrivono l'envelope usato nell'hop firmato.
   • Ogni nuovo hop deve corrispondere alla destinazione precedente (oppure essere "proxy firmato" via pp=).
   • Il verificatore convalida prima la firma più recente (il i più alto).

3. Modelizzazione delle modifiche

   • La bozza introduce un header MailVersion per descrivere come tornare alla versione precedente (ricette su body/header).
   • La firma porta mv= per la versione del messaggio coperta.
   • Un campo f= (flag) può indicare modifiedbody, modifiedheader, exploded, donotmodify, feedback, ecc.

4. Bounce e feedback

   • DSN e feedback vengono riinstradati verso monte lungo la catena verso un attore coinvolto, riducendo il backscatter.
   • Possibilità di specificare preferenze di feedback (a seconda della versione della bozza).

5. Compatibilità e coesistenza

   • DKIM2 non rende immediatamente obsoleto DKIM (RFC 6376): è prevista una fase di transizione con coesistenza.
   • I record DNS restano sotto _domainkey. È prevista la firma proxy (pp=), con vincoli di allineamento e prove di autorizzazione via DNS (es. record dedicato o relazione MX), in base alle bozze.

Cosa scompare o cambia sensibilmente

• Nessun v= in DKIM2-Signature (in caso di rottura maggiore nascerebbe un futuro "DKIM3-Signature" invece di incrementare un numero interno).
• Lista semplificata degli header firmati: viene definito un set di campi obbligatori; h= resta disponibile per casi specifici.
• Gestione della scadenza semplificata: si basa su t= e raccomandazioni lato verificatore, invece di un campo dedicato rigidamente normato.
• Parametri ereditati da DKIM giudicati troppo complessi (es. z=) vengono abbandonati nelle prime bozze.

⚠️ DKIM2 è in fase di stesura: la sintassi esatta (nomi dei tag, flag, tempistiche) può ancora cambiare. Controlla le versioni dei draft citati qui sotto.

Esempio di header (bozze attuali)

DKIM2-Signature: i=1; t=2025-10-24T08:01:02Z; d=example.com; s=sel2025;
  a=ed25519-sha256; bh=BASE64(...); b=BASE64(...);
  rt=user@dest.tld; mf=bounce@example.com; mv=2; f=modifiedheader,feedback

MailVersion: v=2; bh=BASE64(...);
  h.Subject=d:*,t:[Re] Offerta speciale;
  h.From=d:*,b=am9obi5kb2VAZXhhbXBsZS5jb20=

Impatto operativo (riepilogo)

• ESP / relay: firmare ogni hop, gestire mf=/rt=, registrare/annullare le modifiche semplici (ricette) e riemettere verso domini di destinazione allineati.
• Destinatari: verificare prima l'ultima firma (i=Max), poi retrocedere se serve; rifiutare presto in caso di errori gravi.
• DNS: selettori e chiavi invariati sotto _domainkey; pianificare autorizzazioni "proxy" in base al meccanismo DNS che sarà adottato.
• DMARC: finché DMARCbis fa riferimento a DKIM (RFC 6376), DMARC continua ad appoggiarsi a DKIM. Il passaggio DMARC→DKIM2 non è immediato.

Cronologia: tappe recenti

• 5 nov 2024: primi articoli di analisi pubblica su DKIM2 (es. Red Sift).
• 20 nov 2024: post di annuncio da parte degli operatori DMARC.
• 3 set 2025: il working group IETF adotta il documento Motivation (draft-ietf-dkim-dkim2-motivation-01).
• 17–20 ott 2025: pubblicazione dei draft -spec-02 (specifica), -dns-03 (DNS), -header-04 (header) e -modification-algebra-04 (MailVersion).

Piano di preparazione

1. Inventariare dove già firmi/verifichi DKIM (flussi, hop, SRS/VERP, mailing list).
2. Prototipare sui relay: calcolare mf=/rt=, aggiungere i=, scegliere gli algoritmi (Ed25519 consigliato) e gestire t=.
3. Tracciare le modifiche frequenti (footer delle ML, riscrittura di From:) e testarne la reversione tramite MailVersion.
4. DNS: standardizzare il ciclo di rotazione delle chiavi; preparare il meccanismo di autorizzazione "proxy" se necessario.
5. Verifica: implementare la strategia "ultimo i= per primo", emettere rifiuti 5xx durante lo scambio SMTP se la firma fallisce, 4xx su TEMPFAIL DNS.
6. Monitorare le draft (qui sotto) e predisporre feature flag per seguire i cambiamenti di campo.

Glossario

DKIM replay

• Definizione: riutilizzo (replay) di un messaggio già firmato con DKIM da un dominio legittimo per rinviarlo su larga scala o verso altri destinatari senza alterare ciò che copre la firma. La firma rimane valida perché DKIM firma il contenuto (body/header) ma non l'envelope SMTP né il percorso.
• Perché?: un attaccante ottiene una copia di un'email firmata (es. una newsletter) e la ridistribuisce così com'è; DMARC può continuare a passare se From: resta allineato.
• Sintomi: picchi di volume sulla stessa firma (bh= identico), reclami per spam, reputazione degradata del dominio firmatario.
• Mitigazioni: limitazione di banda per selettore, rotazione delle chiavi, durate brevi, DMARC più rigido (p=reject), filtri comportamentali lato ricezione.
• Cosa cambia con DKIM2: la firma include l'envelope per hop (mf=/rt=) e concatena il percorso (numero i=), rendendo il replay rilevabile (percorso incoerente) e permettendo azioni mirate.

Backscatter

• Definizione: bounce indesiderati (NDR/DSN) o auto-risposte inviati a un terzo innocente il cui indirizzo è stato falsificato in MAIL FROM/Return-Path.
• Perché?: i server accettano inizialmente il messaggio e poi generano un bounce successivo; con un indirizzo falsificato, il bounce torna alla vittima.
• Sintomi: ondate di DSN/auto-risposte su una casella legittima, reputazione compromessa, possibili inserimenti in liste.
• Mitigazioni: rifiutare durante lo scambio SMTP (non dopo), SPF/DMARC rigorosi, SRS/VERP per tracciare i bounce, regole anti auto-risposta.
• Cosa cambia con DKIM2: DSN/feedback possono essere instradati verso monte tramite la catena firmata, riducendo il backscatter e raggiungendo l'attore effettivamente coinvolto.

Fonti e approfondimenti

• DKIM2 – specifica: draft-clayton-dkim2-spec-02 (20 ottobre 2025, scadenza 23 aprile 2026).
• DKIM2 – DNS: draft-chuang-dkim2-dns-03 (20 ottobre 2025).
• DKIM2 – header: draft-gondwana-dkim2-header-04 (20 ottobre 2025).
• DKIM2 – algebra delle modifiche / MailVersion: draft-gondwana-dkim2-modification-algebra-04 (17 ottobre 2025).
• Motivation (documento del working group IETF): draft-ietf-dkim-dkim2-motivation-01 (3 settembre 2025, sostituisce le versioni individuali).
• Ripasso DKIM: RFC 6376; aggiornamenti: RFC 8301, RFC 8463.

DKIM2 è ancora un lavoro in corso. Aggiorneremo questa pagina quando le draft progrediranno verso una RFC.