Vai al contenuto principale
CaptainDNS

DKIM2: a che punto è la standardizzazione e come prepararsi

Di CaptainDNS
Pubblicato il 3 novembre 2025

Aggiornato il 27 luglio 2026

La parola DKIM2, gli header DKIM2-Signature e Message-Instance e una catena di hop firmati i=1, i=2, i=3 prolungata da una freccia tratteggiata
TL;DR
  • DKIM2 non è uno standard: nessuna RFC, nessun documento in ultimo appello e un calendario del charter IETF in ritardo di circa sette mesi.
  • Il lavoro si svolge nel gruppo di lavoro dkim storico, il cui charter è stato rinnovato nel febbraio 2025. Non esiste alcun gruppo « dkim2 ».
  • La specifica attuale (draft-ietf-dkim-dkim2-spec-04, 5 luglio 2026) poggia su due header: DKIM2-Signature per ogni hop e Message-Instance per descrivere le modifiche sotto forma di ricette JSON.
  • Quasi tutta la sintassi del 2025 è scomparsa: mv=, pp=, a=, b=, bh=, l'header Mail-Version:.
  • Tre implementazioni (Rust, Python, Go) hanno dimostrato la loro interoperabilità nel luglio 2026, e da allora ne è stata annunciata una quarta, in C: il cambiamento di stato più concreto dell'ultimo anno.
  • Proprietari di dominio: nulla da fare. Le vostre chiavi e i vostri record _domainkey restano validi così come sono.

ℹ️ I termini replay DKIM, backscatter, Message-Instance e ricetta sono definiti nel glossario alla fine dell'articolo.

DKIM2 si porta dietro una reputazione contraddittoria. Si legge che sostituirà DKIM « presto », che renderà DMARC obsoleto oppure, al contrario, che esiste solo sulla carta. La realtà di luglio 2026 è più semplice: il protocollo non è ancora standardizzato, ma ha smesso di essere teorico, perché tre implementazioni indipendenti firmano, verificano e ricostruiscono messaggi insieme.

Perché è nato DKIM2?

DKIM (STD 76, RFC 6376) firma il contenuto di un messaggio. È il suo punto di forza e, dopo vent'anni di esercizio, il suo limite: la firma non dice nulla del percorso seguito né degli indirizzi realmente usati a ogni hop SMTP.

Il replay che DKIM non chiude

Un attaccante che recupera un messaggio firmato legittimamente può rispedirlo in massa senza toccare ciò che la firma copre: la firma resta valida, DMARC continua a passare, ed è il dominio firmatario a subire il degrado della reputazione. È il replay DKIM, che nessuna rotazione di chiave elimina davvero.

L'inoltro che rompe la firma

Una mailing list che aggiunge un piè di pagina, antepone un prefisso all'oggetto o inserisce un header di disiscrizione invalida l'hash firmato. DKIM non offre alcun modo per descrivere la modifica, e quindi nessun modo per tornare indietro e verificare la firma originaria.

I bounce che ripartono verso un terzo

Quando un server accetta un messaggio e poi genera un bounce a posteriori, quel bounce parte verso l'indirizzo di busta, potenzialmente falsificato. È il backscatter: una vittima innocente riceve rapporti di mancato recapito per posta che non ha mai inviato.

DKIM2 affronta i tre problemi insieme: ogni hop appone la propria firma numerata, dichiara la busta che ha usato e documenta ciò che ha modificato. Il percorso diventa verificabile e le modifiche reversibili.

Catena di firme DKIM2: ogni hop SMTP aggiunge una firma numerata che dichiara la busta utilizzata

Il vostro DKIM attuale è sano prima di pensare a DKIM2?

Verificare i miei selettori DKIMVerificare il mio DMARC

A che punto è la standardizzazione?

Un gruppo con charter rinnovato, tre documenti

Non esiste alcun gruppo di lavoro « dkim2 » all'IETF, ed è la prima fonte di errore. Il lavoro si svolge nel gruppo dkim storico, il cui charter rivisto è stato approvato dall'IESG il 20 febbraio 2025, sotto la presidenza di Murray Kucherawy e Pete Resnick.

Tre documenti del gruppo sono attivi:

  • draft-ietf-dkim-dkim2-spec-04 (5 luglio 2026), Standards Track, 43 pagine, scade il 6 gennaio 2027. Autori: Richard Clayton (Yahoo), Wei Chuang (Google), Bron Gondwana (Fastmail).
  • draft-ietf-dkim-dkim2-bcp-00 (18 giugno 2026), Todd Herr. Adottato, ma deliberatamente messo in attesa finché il gruppo non avrà accumulato esperienza operativa.
  • draft-ietf-dkim-dkim2-dns-00 (20 luglio 2026), Wei Chuang.

Cosa dice il calendario

Nessuno di questi documenti è in ultimo appello del gruppo (WG Last Call), nessuno è stato sottoposto all'IESG, non esiste alcuna RFC. Eppure i traguardi del charter puntavano a « tutti i documenti sottoposti all'IESG entro il 31 dicembre 2025 »: il ritardo è di circa sette mesi e il calendario non è stato rivisto.

I traguardi reali del periodo trascorso sono pochi. Novembre 2025: i draft motivation, header e mailversion cessano di essere mantenuti. 20 marzo 2026, all'IETF 125: la specifica di Richard Clayton diventa il documento principale e il formato JSON viene scelto per descrivere le modifiche. 24 marzo 2026: primo draft di gruppo della specifica. 24 giugno 2026: spec-03 introduce il tag nd=. 24 luglio 2026: sessione DKIM all'IETF 126, a Vienna.

I documenti morti

Qualsiasi contenuto scritto nel 2025 su DKIM2 rimanda a draft oggi abbandonati o sostituiti: verificate sempre i nomi e le revisioni citati. draft-ietf-dkim-dkim2-motivation-02 è scaduto; draft-ietf-dkim-dkim2-header-00 e draft-gondwana-dkim2-mailversion-00 sono contrassegnati come « Dead WG Document ». Il loro contenuto è stato assorbito, riscritto o abbandonato.

Altro errore che circola: diverse pubblicazioni affermano che il gruppo avrebbe adottato un « profilo di deployment tramite milter ». È falso. L'8 maggio 2026 il presidente del gruppo ha scritto che « the working group does not wish to pursue adoption at this time ».

Cronologia DKIM2: dall'abbandono dei draft del 2025 alla pubblicazione di spec-04 e alla sessione IETF 126

Cosa cambia concretamente DKIM2

La meccanica poggia su due header distinti.

L'header DKIM2-Signature

Ogni hop aggiunge una riga. Il paragrafo 8 della specifica fissa gli obblighi: « The i=, m=, t=, d= and s= tags MUST be present. There MUST be either an nd= tag or both mf= and rt= tags. The other tags are optional. »

TagObbligatorioRuolo
i=sìNumero di sequenza dell'hop. Il mittente di origine firma con i=1, ogni hop successivo incrementa. Un vuoto nella numerazione e l'intero messaggio è considerato non firmato.
m=sìNumero del Message-Instance più alto al momento della firma.
t=sìTimestamp, espresso in secondi epoch UTC (un intero, non una data formattata).
d=sìDominio firmatario. È quello che serve a costruire la query DNS di recupero della chiave.
s=sìTripletta selettore:algoritmo:firma-base64.
mf=condizionaleMAIL FROM usato in fase di invio, codificato in base64, parentesi angolari incluse.
rt=condizionaleRCPT TO, base64, parentesi angolari incluse. Possono essere elencati più destinatari.
nd=condizionaleDominio che firmerà l'hop successivo. Mutuamente esclusivo con mf= e rt=.
n=noNonce libero, 64 caratteri al massimo.
f=noFlag.

Il tag s= segue l'ABNF sig-set = selector ":" sig-name ":" message-sig, dove sig-name vale rsa-sha256 oppure ed25519-sha256; più firme con algoritmi diversi possono coesistere, ma « a different selector MUST necessarily be used for each signature ». Il d=, invece, deve corrispondere esattamente alle label più a destra del dominio indicato in mf=: in altri termini, d= è identico a quel dominio oppure è uno dei suoi domini padre. Quindi mf=<user@mail.example.com> è compatibile con d=example.com, mentre il contrario, mf=<user@example.com> con d=mail.example.com, viene rifiutato. Solo un mf= vuoto, cioè <>, il caso dei rapporti di mancato recapito, è esente da questa corrispondenza.

Sul versante crittografico, la specifica impone RSA di almeno 1024 bit in fase di firma ed esige che i verificatori accettino da 1024 a 2048 bit, mentre il supporto di chiavi più grandi è facoltativo. L'esponente pubblico è 65537, il padding PKCS#1 v1.5, l'hash non troncato, SHA256 obbligatorio, ed Ed25519 nella variante PureEdDSA (RFC 8032, paragrafo 5.1): « Signers SHOULD implement both RSA-SHA256 and Ed25519-SHA256, Verifiers MUST implement both ». Una firma più vecchia di 14 giorni può essere ignorata, ma è un MAY, non un obbligo.

I flag f= sono stati ridefiniti. exploded indica che il messaggio parte verso più di un indirizzo; la sua assenza autorizza un MTA a supporre che esista una sola copia, ed è esattamente questa la leva anti-replay. donotexplode e donotmodify sono divieti rivolti agli intermediari. feedback chiede un riscontro, la sua assenza significa che quel riscontro non è desiderato, e feedhere permette a un intermediario di inoltrare quel riscontro senza rivelare la destinazione finale. Ogni flag sconosciuto deve essere ignorato.

Un verificatore produce uno dei quattro stati PASS, FAIL, PERMERROR o TEMPERROR, allineati alla RFC 8601.

Il Message-Instance

Il secondo header descrive lo stato del messaggio e il modo per tornare allo stato precedente: « The m= and h= tags MUST be present. The r= tag is optional. »

Il tag m= è il numero di revisione: 1 all'origine, incrementato a ogni nuova istanza; un vuoto rende il messaggio non verificabile. Il tag h= ha la forma sha256:<hash degli header>:<hash del corpo>, entrambi in base64, e più set possono coesistere. Il tag r= contiene « the base64 encoded version of the JSON object that contains the recipes that allow the previous instance of the message to be recreated ».

Punto importante per gli operatori: se non modificate nulla, non aggiungete alcun Message-Instance; un relay che trasmette il messaggio così com'è non ha nulla da descrivere.

Le ricette formano un oggetto JSON, identificato dallo schema https://dkim2.org/schemas/recipe-v1, con una chiave "h" per gli header e/o "b" per il corpo. Ogni ricetta è un array di passi che portano esattamente una chiave: {"c": [inizio, fine]} copia un intervallo di righe o di istanze, {"d": ["..."]} emette dati letterali. Un "b": null segnala un corpo precedente non ricostruibile; un array vuoto associato a un nome di campo significa « elimina tutte le sue occorrenze ». Trappola classica: gli header sono numerati dal basso verso l'alto, le righe del corpo dall'alto verso il basso.

Le vostre chiavi DNS non cambiano

La chiave pubblica si recupera sotto <selettore>._domainkey.<d=>, esattamente come oggi: « these keys are no different, and are stored in the same locations as those for DKIM1 ». Nessun nuovo tipo di record, nessuna migrazione DNS da preparare.

Anatomia di un header DKIM2-Signature e di un Message-Instance, tag per tag

nd= o mf=/rt=: la catena di custodia

Una sequenza di più DKIM2-Signature che portano nd= è permessa, ma « MUST end with a DKIM2-Signature that contains mf= and rt= tags », e il dominio dichiarato in nd= deve corrispondere esattamente al d= della firma successiva nell'ordine degli i=.

Il paragrafo 9.3 presenta questa variante come una catena di custodia per hop immaginari. Prendete un sistema che riceve posta su un dominio e la rispedisce da un altro: la continuità tra il rt= dell'hop precedente e il mf= dell'hop successivo è interrotta. Anziché fabbricare una firma con mf= e rt= inventati, che inquinerebbero la catena con indirizzi fittizi, annuncia con nd= quale sarà il prossimo firmatario. È l'opzione che la specifica incoraggia.

Esempio di header

spec-04 non contiene alcun esempio di messaggio o di header: il draft che avrebbe dovuto fornirli, draft-robinson-dkim2-message-examples-00, è scaduto nel 2025. L'esempio qui sotto è quindi ricostruito a partire dalla grammatica ABNF del documento e non ha alcun valore normativo.

Scenario a due hop: un mittente scrive a una mailing list, la lista aggiunge un header List-Unsubscribe e rispedisce.

DKIM2-Signature: i=2; m=2; t=1740001000; d=test2.dkim2.com;
  mf=PGJvdW5jZUB0ZXN0Mi5ka2ltMi5jb20+; rt=PHJlY2lwaWVudEBleGFtcGxlLmNvbT4=;
  s=ed25519:ed25519-sha256:FDYZopU8W+c7...;
DKIM2-Signature: i=1; m=1; t=1740000000; d=test1.dkim2.com;
  mf=PHNlbmRlckB0ZXN0MS5ka2ltMi5jb20+; rt=PGxpc3RAdGVzdDIuZGtpbTIuY29tPg==;
  s=ed25519:ed25519-sha256:oKZmf7rabJv4...;
Message-Instance: m=2; h=sha256:u4RFAizDeEqt...:SgG5fNGEg1x2...;
  r=eyJoIjp7Imxpc3QtdW5zdWJzY3JpYmUiOltdfX0=;
Message-Instance: m=1; h=sha256:SLtzk6LO68CC...:SgG5fNGEg1x2...;
Received: from test1.dkim2.com by relay.example.com; ...
List-Unsubscribe: <mailto:unsub@relay.example.com>
From: sender@test1.dkim2.com
To: list@test2.dkim2.com
Subject: ...

Decodifichiamo. I valori di busta sono in base64, parentesi angolari comprese, come richiede la specifica. Al primo hop, mf= vale <sender@test1.dkim2.com> e rt= vale <list@test2.dkim2.com>. Al secondo, la lista rispedisce: mf= vale <bounce@test2.dkim2.com> e rt= vale <recipient@example.com>. La continuità della catena è visibile a occhio nudo, ed è proprio questo il senso del meccanismo.

Il passaggio più istruttivo è il r= del Message-Instance numero 2. Decodificato dal base64, dà:

{"h":{"list-unsubscribe":[]}}

Traduzione in italiano: « per tornare all'istanza precedente, elimina tutte le occorrenze del campo List-Unsubscribe ». Un verificatore che vuole convalidare la firma i=1 applica questa ricetta, ritrova il messaggio così come il mittente l'ha emesso, ricalcola l'hash e confronta. La modifica non ha rotto la catena: è stata dichiarata e resa reversibile.

I valori di s= e gli hash dell'h= sono troncati: dipenderebbero da chiavi private e da un messaggio reale, quindi non sono ricalcolabili dal lettore. L'esempio serve a mostrare la struttura degli header, non a essere verificato.

Cosa è cambiato rispetto ai draft del 2025

Se avete letto una guida DKIM2 pubblicata a fine 2025, praticamente tutta la sintassi che descriveva è scomparsa.

Elemento del 2025Stato in spec-04
Header unico DKIM2: (Active/Historical)Rimosso, sostituito dalla coppia DKIM2-Signature e Message-Instance
Header Mail-Version:Rimosso, rifuso in Message-Instance; le ricette compatte lasciano il posto a JSON codificato in base64
mv=Rinominato m=
v=Non esiste e non esisterà
pp= (procura)Rimosso; nd= ne occupa il posto da spec-03 (24 giugno 2026)
a=Rimosso, fuso in s=
b=Rimosso, assorbito da s=
bh=Spostato nell'h= del Message-Instance
h= (elenco dei campi firmati)Senso invertito: DKIM2 firma tutto tranne una lista di esclusione
t=Passa da un date-time formattato a un intero epoch
f=modifiedbody, f=modifiedheaderRimossi, giudicati ridondanti rispetto ai dati di versione
f=donotforwardRimosso
f=feedhereNuovo, comparso in spec-03

L'assenza di v= è deliberata

Il paragrafo 8 la giustifica: « Experience from IMF onwards shows that it is essentially impossible to change version numbers. If it becomes necessary to change DKIM2 in the sort of incompatible way that a v=2 / v=3 version number would support, it is expected that header fields will be labelled as DKIM3 instead. » Una rottura maggiore produrrebbe quindi un header DKIM3-Signature, non un numero di versione interno.

L'inversione dell'h=

DKIM elenca i campi che firma. DKIM2 fa il contrario: firma tutto, tranne sette famiglie di campi elencate al paragrafo 4.1, ossia ARC-*, Authentication-Results, Delivered-To, DKIM-Signature, Received, Return-Path e X-*. Esattamente i campi che un intermediario è legittimamente portato ad aggiungere o modificare in transito.

ARC va in pensione

ARC rispondeva allo stesso sintomo: l'inoltro rompe SPF e DKIM. Ma si limitava a trasportare una testimonianza sigillata dei risultati di autenticazione constatati prima del relay, senza mai chiudere la falla del replay. È tracciabilità, non integrità end-to-end. L'IETF lo riclassifica oggi allo stato « Historic » e concentra lo sforzo su DKIM2, che tratta la causa anziché il sintomo. Il dettaglio di questa riclassificazione e le sue conseguenze pratiche sono oggetto di un articolo dedicato.

A che punto sono le implementazioni?

È qui che l'anno è stato decisivo: si è passati da zero implementazioni a tre che si capiscono tra loro, e da allora ne è stata annunciata una quarta.

Il 4 luglio 2026 una dimostrazione di interoperabilità ha riunito tre implementazioni indipendenti: mail-auth in Rust (Stalwart Labs), l'implementazione Python di Bron Gondwana e l'implementazione Go di Steve Atkins. Firma, verifica e ricostruzione tramite ricette sono state testate nei due sensi, comprese le catene multi-hop. Risultato annunciato: con il folding degli header disattivato, tutte le combinazioni passano. Due bug di folding sono stati individuati in quell'occasione, uno sul versante Go (base64 rigoroso, senza rimozione degli spazi), l'altro sul versante Python (suddivisione su : senza unfolding preliminare).

L'8 luglio 2026 Bron Gondwana ha centralizzato la suite di test nell'organizzazione GitHub dkim2wg e ha menzionato una quarta implementazione, in C (PhoenixDKIM).

Sul calendario esistono pronostici, datati e attribuiti. Laura Atkins (Word to the Wise, 23 aprile 2026) si aspetta di vedere DKIM2 funzionante presso i grandi provider entro fine 2026. Al Iverson (Spam Resource, 21 aprile 2026) ricorda che la specifica non è ancora finalizzata e che le cose possono cambiare, e sottolinea che le chiavi, invece, per ora non cambiano. Nessuna fonte primaria annuncia una data di obbligo per i mittenti, e i calendari di obbligo che circolano non poggiano su alcuna fonte primaria.

Stato dei documenti del gruppo di lavoro dkim all'IETF e delle tre implementazioni DKIM2 che hanno dimostrato la loro interoperabilità

Cosa non è ancora deciso

Il gruppo si è riunito all'IETF 126, a Vienna, il 24 luglio 2026. I punti seguenti vi sono stati sollevati, non decisi; i verbali della sessione non sono ancora pubblicati.

  1. Ricette nulle per gli header: vanno rimosse, in mancanza di un caso d'uso individuato?
  2. Message-Instance fallaci: i MUST NOT attuali sono troppo stringenti e hanno provocato rifiuti di messaggi durante le prove di interoperabilità.
  3. Algoritmo post-quantistico: il gruppo cerca il parere di esperti, la difficoltà individuata è che chiavi molto lunghe passano male nel DNS su UDP.
  4. Maiuscole e minuscole nei nomi dei campi: bisogna imporre le minuscole nelle ricette JSON?
  5. Rapporti di mancato recapito: serve un flag dedicato e l'omissione del Message-Instance?
  6. Allineamento e DMARC: « The DKIM2 spec deliberately stays away from saying anything about DMARC », il tema è rinviato al documento di buone pratiche. L'aspettativa espressa è un allineamento tra il From: di origine, il MAILFROM iniziale e il d= della prima DKIM2-Signature, mentre oggi DKIM2 esige solo l'allineamento degli ultimi due.
  7. Messaggi ritrasmessi con il solo DKIM1: vanno firmati in DKIM2?
  8. Loop di feedback: bisogna standardizzarne il formato?

Questa lista è la migliore misura della maturità reale del protocollo, e la ragione per cui il documento di buone pratiche resta congelato.

Impatti operativi

Le conseguenze non sono le stesse a seconda del vostro ruolo, e la ripartizione è sbilanciata.

Proprietario di dominio: nulla da fare

Nessuna azione da intraprendere oggi. L'unica cosa utile è mantenere un DKIM1 sano, con una rotazione delle chiavi sotto controllo, e un DMARC attivo: è la base su cui DKIM2 si appoggerà.

Precisazione che torna spesso: DMARC non scompare. Conserva un valore proprio, in particolare i report aggregati a livello di dominio e il rilevamento dello spoofing del dominio del From:, che DKIM2 non replica.

ESP, relay e mailing list: il vero cantiere

Firmare a ogni hop, tracciare le modifiche sotto forma di ricette e soprattutto anticipare un effetto collaterale sottovalutato: l'afflusso di bounce asincroni in entrata. DKIM2 rimanda il messaggio all'hop precedente, il che cambia il volume e la natura dei ritorni da trattare, un punto che Laura Atkins sottolinea in modo particolare.

Altro punto di attenzione: la doppia firma (quella del marchio e quella della piattaforma), così come si pratica oggi in DKIM, non si traspone direttamente. Al Iverson osservava il 9 maggio 2026 che non esistono, a rigore, firme multiple dirette.

Verificatori: cominciare dall'alto

La verifica è invertita rispetto all'intuizione: si parte dall'i= più alto, la firma più recente, poi si risale la catena applicando le ricette per ricostruire le istanze precedenti.

Posizione DNS delle chiavi DKIM2 sotto _domainkey, identica a quella di DKIM1

Piano di preparazione

  1. Inventariate i vostri flussi: dove firmate, dove verificate, quali hop intermedi esistono, quali meccanismi di riscrittura della busta (SRS, VERP) sono in uso.
  2. Risanate DKIM1: selettori aggiornati, chiavi di dimensione corretta, rotazione documentata.
  3. Prototipate lato relay se ne gestite uno: mf= e rt= in base64 parentesi angolari comprese, numerazione i=, timestamp epoch, scelta degli algoritmi.
  4. Modellate le vostre modifiche abituali sotto forma di ricette JSON: piè di pagina, prefisso dell'oggetto, List-Unsubscribe. È l'esercizio che rivela i casi difficili.
  5. Dimensionate il trattamento dei bounce asincroni in entrata, il punto più spesso dimenticato.
  6. Non toccate il vostro DNS per DKIM2: non c'è nulla di nuovo da pubblicare.
  7. Predisponete un monitoraggio di draft-ietf-dkim-dkim2-spec e prevedete dei feature flag: quattro revisioni in poco più di tre mesi, la sintassi si muove ancora.

FAQ

DKIM2 è uno standard nel 2026?

No. Al 25 luglio 2026 non esiste alcuna RFC DKIM2: la specifica è allo stadio draft-ietf-dkim-dkim2-spec-04, pubblicata il 5 luglio 2026, e nessun documento del gruppo è in ultimo appello né sottoposto all'IESG. I traguardi del charter puntavano a una sottomissione entro il 31 dicembre 2025, quindi circa sette mesi di ritardo.

Devo modificare i miei record DNS per DKIM2?

No. La specifica precisa che le chiavi DKIM2 non sono diverse e sono memorizzate nelle stesse posizioni di quelle di DKIM1, sotto selettore._domainkey.vostrodominio. Nessun nuovo tipo di record, nessuna migrazione DNS da prevedere.

Qual è la differenza tra DKIM2-Signature e Message-Instance?

DKIM2-Signature viene aggiunto da ogni hop SMTP: numero di sequenza i=, timestamp, dominio firmatario, firma e busta utilizzata. Message-Instance descrive lo stato del messaggio e il modo per tornare al precedente, tramite ricette JSON codificate in base64 nel tag r=. Un intermediario che non modifica nulla aggiunge una firma, ma nessun Message-Instance.

DKIM2 sostituisce DMARC?

No. DMARC conserva un valore proprio che DKIM2 non replica: report aggregati a livello di dominio e rilevamento dello spoofing del dominio del From:. La specifica evita d'altronde deliberatamente di parlare di DMARC e rinvia la questione dell'allineamento al documento di buone pratiche.

Esistono implementazioni di DKIM2 funzionanti?

Sì: tre implementazioni hanno dimostrato la loro interoperabilità, e da allora ne è stata annunciata una quarta, che non ha partecipato alla dimostrazione. Il 4 luglio 2026 una dimostrazione di interoperabilità ha riunito mail-auth in Rust (Stalwart Labs), un'implementazione Python di Bron Gondwana e un'implementazione Go di Steve Atkins, comprese le catene multi-hop. Una quarta implementazione in C, PhoenixDKIM, è stata menzionata solo dopo, l'8 luglio 2026, quando la suite di test è stata centralizzata nell'organizzazione GitHub dkim2wg.

Cosa devo fare oggi se gestisco semplicemente un dominio aziendale?

Nulla di specifico per DKIM2: verificate che il vostro DKIM attuale sia pubblicato e firmato correttamente, che il vostro DMARC sia attivo e monitorato, e che la vostra rotazione delle chiavi sia documentata. Il lavoro reale di migrazione riguarda gli ESP, i relay e le mailing list, non i proprietari di dominio.

📖 Glossario

Replay DKIM

Rispedizione massiva, o verso altri obiettivi, di un messaggio già firmato da un dominio legittimo, senza alterare ciò che la firma copre: questa resta valida, perché DKIM firma il contenuto ma non la busta SMTP né il percorso. Il dominio firmatario vede la propria reputazione degradarsi per posta che non ha inviato, e nessuna mitigazione DKIM1 (limitazione del volume per selettore, rotazione delle chiavi, irrigidimento di DMARC) chiude la falla. In DKIM2 la firma include la busta dell'hop e concatena il percorso tramite il numero i=.

Backscatter

Bounce indesiderati (NDR, DSN) o risposte automatiche inviati a un terzo innocente il cui indirizzo è stato falsificato in MAIL FROM o in Return-Path: la sua casella viene inondata di rapporti di mancato recapito. In DKIM1 si rifiuta durante lo scambio SMTP anziché dopo, con SRS o VERP per tracciare i bounce; in DKIM2 i ritorni risalgono la catena firmata fino all'hop precedente, quindi verso un attore realmente coinvolto.

Message-Instance

Header DKIM2 che descrive lo stato di un messaggio in un dato momento del suo percorso: m= (numero di revisione) e h= (hash degli header e del corpo) obbligatori, r= (ricette) facoltativo.

Ricetta

Descrizione JSON, codificata in base64 nel tag r= di un Message-Instance, che permette di ricostruire l'istanza precedente del messaggio.

Fonti

DKIM2 resta un lavoro in corso. Questa pagina sarà aggiornata al ritmo delle revisioni del draft di specifica.

Verificare il vostro DKIM attuale

È la vostra configurazione DKIM (RFC 6376) attuale a essere riutilizzata. Ispezionate i vostri selettori in tempo reale con il DKIM Record Checker e validate la sintassi di ogni record pubblicato con il DKIM Syntax Validator.

Guide di autenticazione email correlate

Articoli simili