DomainKeys Identified Mail (DKIM): cos’è e come funziona

Domainkeys identified mail (dkim) in sintesi

• Meccanismo: una coppia di chiavi asimmetriche firma il messaggio in uscita e ne verifica l’integrità all’arrivo.
• Pubblicazione: la chiave pubblica viene esposta in un record TXT DNS nel formato selettore._domainkey.dominio.
• Protezione combinata: da sola non basta: va abbinata a SPF e DMARC per un controllo completo del mittente.
• Lunghezza chiave consigliata: 2048 bit, con possibilità di usare 1024 bit se l’host del dominio non supporta chiavi più lunghe.
• Rotazione: va programmata periodicamente, per ridurre il rischio di compromissione della chiave privata.
• Diagnosi: un esito negativo compare nell’intestazione come dkim=fail e può derivare da chiave mancante, scaduta o contenuto alterato dopo la firma.

Perché la posta elettronica ha bisogno di DKIM

Il protocollo SMTP alla base dell’invio delle email non prevede alcun controllo nativo sull’identità del mittente: chiunque può scrivere un indirizzo arbitrario nel campo “Da”. DKIM colma questa lacuna legando crittograficamente il contenuto del messaggio al dominio che lo ha realmente inviato, rendendo visibile qualsiasi alterazione avvenuta durante il transito.

Il meccanismo serve principalmente a tre scopi: dimostra che il server mittente era autorizzato a inviare per conto del dominio dichiarato, garantisce che testo e intestazioni non siano stati modificati dopo l’invio e costruisce reputazione presso i provider di posta, riducendo la probabilità che i messaggi finiscano in spam. Dal febbraio 2024 Google e Yahoo richiedono ai grandi speditori di superare SPF e DKIM e di mantenere i reclami spam sotto lo 0,3%, una soglia che rende la firma DKIM un requisito tecnico e non più solo una buona pratica (Metodi di autenticazione delle e-mail: SPF, DKIM, DMARC (2024)).

L’adozione dello standard è ormai diffusa su scala globale: secondo un’analisi di mercato, 263.977 siti web monitorati utilizzano DomainKeys Identified Mail, con il settore dei servizi IT e della consulenza informatica in testa con 2.369 siti rilevati (Statistiche d’uso di DomainKeys Identified Mail (DKIM)). Gli Stati Uniti restano il mercato principale con il 39,8% di quota, seguiti da Russia (10,2%) e Germania (6,1%), segno di un’adozione trasversale a settori e aree geografiche diverse.

L’assenza di autenticazione ha un costo concreto in termini di sicurezza: secondo il report 2023 dell’FBI IC3, oltre il 40% delle frodi informatiche segnalate ha coinvolto email falsificate o contraffatte, uno scenario in cui DKIM, insieme a SPF e DMARC, riduce sensibilmente la superficie d’attacco per lo spoofing del dominio (SPF, DKIM e DMARC: configurarli bene per email sicure (2023)).

Come funziona la firma di un messaggio con DKIM

Il processo si articola in tre fasi distinte, ciascuna indispensabile per completare la verifica dell’autenticità.

Firma con chiave privata

Quando il server di invio elabora un messaggio, calcola un hash crittografico di intestazioni selezionate e del corpo del testo, quindi lo firma con una chiave privata custodita sul server stesso. Il risultato viene inserito in un’intestazione aggiuntiva chiamata DKIM-Signature, che viaggia insieme al messaggio senza alterarne la lettura da parte del destinatario.

Verifica con chiave pubblica

Il server ricevente estrae dal messaggio il dominio e il selettore indicati nella firma, interroga il DNS nel punto selettore._domainkey.dominio e recupera la chiave pubblica corrispondente. Con questa chiave decifra la firma e confronta il risultato con l’hash ricalcolato localmente sul messaggio ricevuto.

Controllo di integrità del messaggio

Se i due hash coincidono, il messaggio è considerato integro e proveniente dal dominio dichiarato; l’esito viene riportato come dkim=pass nell’intestazione Authentication-Results. Un esito positivo su DKIM non garantisce da solo la piena legittimità del messaggio: un dominio con reputazione compromessa può comunque firmare correttamente email dannose, motivo per cui il controllo va sempre letto insieme a SPF e DMARC.

Struttura del record DKIM e ruolo del selettore

Un record DKIM è composto da due elementi distinti ma collegati: l’intestazione inserita nel messaggio in uscita e il record pubblicato nel DNS del dominio mittente. Il selettore è la stringa che mette in relazione i due, permettendo a un dominio di gestire più chiavi contemporaneamente, ad esempio quando più fornitori inviano email per lo stesso dominio.

Esempio di firma DKIM

Una firma tipica si presenta nella forma v=1; a=rsa-sha256; d=esempio.it; s=mail2024; bh=...; b=.... Ogni coppia chiave-valore descrive un aspetto preciso della firma, come riportato nella tabella seguente.

Come leggere un record DKIM nel DNS

Il record si trova all’host selettore._domainkey.dominio ed è interrogabile con un comando nslookup -type=TXT selettore._domainkey.dominio oppure con uno strumento di lookup online dedicato. L’assenza di risposta a questa interrogazione, spesso descritta come “no DKIM record found”, indica che il selettore indicato nella firma non corrisponde a nessun record pubblicato, oppure che la propagazione DNS non è ancora completa.

Selettore

Identificatore scelto liberamente dall’amministratore del dominio, utile per ruotare le chiavi senza interrompere la firma delle email già in transito.

Record TXT DKIM

Voce DNS di tipo testo che ospita la chiave pubblica e i parametri crittografici necessari alla verifica.

Come generare e verificare un record DKIM

La creazione di una firma DKIM funzionante segue una sequenza di passaggi che vale indipendentemente dal server di posta utilizzato.

1. Generare una coppia di chiavi DKIM con un generatore dedicato, scegliendo lunghezza 2048 bit quando l’host del dominio lo supporta.
2. Pubblicare la chiave pubblica come record TXT all’host selettore._domainkey.dominio, rispettando il limite di 255 caratteri per singola stringa previsto da molti provider DNS.
3. Caricare la chiave privata nella configurazione del server di invio, assicurandosi che venga applicata a tutte le email in uscita dal dominio.
4. Attendere la propagazione del record, che può richiedere fino a 48 ore prima che tutti i resolver DNS lo restituiscano correttamente.
5. Inviare un’email di prova e controllare l’intestazione Authentication-Results per confermare l’esito dkim=pass.

Strumenti di controllo DKIM

Un controllo DKIM (DKIM check) interroga il record TXT pubblicato e segnala eventuali anomalie di sintassi, selettori mancanti o chiavi incoerenti con quelle attese. Un inspector DKIM più completo analizza anche le intestazioni di un’email realmente ricevuta, mostrando il risultato della verifica calcolato dal server ricevente e non solo la presenza del record. Strumenti con funzione di test DKIM permettono inoltre di simulare l’invio di un messaggio e di leggere l’esito di SPF, DKIM e DMARC nello stesso report, utile per isolare quale dei tre protocolli sta fallendo.

Controllo della lunghezza della chiave

Un controllo mirato sulla lunghezza della chiave confronta i bit dichiarati nel tag p= con quanto effettivamente pubblicato: un disallineamento tra una chiave generata a 2048 bit e una pubblicata per errore a 1024 bit produce un fallimento sistematico della verifica, anche se il record è formalmente presente.

DKIM, SPF e DMARC: ruoli distinti nella stessa catena

DKIM, SPF e DMARC coprono tre livelli diversi della stessa verifica e vanno controllati insieme, non in alternativa. Un controllo congiunto su SPF, DKIM e DMARC è il modo corretto di valutare se un dominio è autenticato in modo completo, perché un singolo protocollo può risultare positivo pur lasciando scoperti altri vettori di spoofing.

Differenza tra DKIM e SPF

SPF autorizza indirizzi IP specifici a inviare per conto di un dominio, ma non protegge il contenuto del messaggio: se l’email transita per un server autorizzato, SPF risulta positivo anche in presenza di manomissioni. DKIM, al contrario, non riguarda l’indirizzo IP del mittente ma verifica che intestazioni e corpo non siano stati alterati, grazie alla firma crittografica applicata al momento dell’invio.

Come impostare insieme SPF, DKIM e DMARC

L’ordine operativo corretto prevede prima la pubblicazione del record SPF con i server autorizzati, poi l’attivazione della firma DKIM sul server di invio e infine la pubblicazione di una policy DMARC che indichi come trattare i messaggi che falliscono uno o entrambi i controlli precedenti. Impostare DMARC prima di aver verificato che DKIM e SPF funzionino correttamente rischia di bloccare email legittime già in produzione.

Lunghezza della chiave e rotazione periodica

La lunghezza minima utilizzabile per una chiave DKIM è 1024 bit, ma lo standard attuale raccomanda 2048 bit per una resistenza adeguata contro attacchi di forza bruta sulla crittografia asimmetrica. La scelta tra le due lunghezze dipende in parte dal provider DNS: alcuni limitano i record TXT a 255 caratteri per stringa, costringendo a suddividere la chiave a 2048 bit in più segmenti racchiusi tra virgolette all’interno dello stesso record.

Quando ruotare la chiave DKIM

La rotazione periodica della chiave riduce la finestra di esposizione in caso di compromissione della chiave privata. La pratica consigliata prevede di ruotare la chiave almeno due volte l’anno, pubblicando il nuovo selettore con un certo anticipo rispetto alla disattivazione del vecchio, in modo da non invalidare le firme già in transito al momento del cambio.

Se la chiave scade senza essere rinnovata

Se la chiave DKIM viene lasciata scadere senza aggiornamento, tutte le email firmate con quella chiave falliscono la verifica non appena il record viene rimosso o sostituito. In questo caso occorre generare una nuova coppia di chiavi, pubblicare il nuovo record TXT con un selettore diverso e aggiornare la configurazione del server di invio prima di disattivare il selettore precedente.

Come risolvere un errore DKIM fail

Un esito dkim=fail nell’intestazione Authentication-Results indica che il server ricevente non è riuscito a confermare la firma, ma le cause tecniche sono diverse tra loro e richiedono verifiche distinte.

Se l’errore indica “body hash did not verify”

Questo esito significa che il corpo del messaggio è stato modificato dopo la firma. Le cause più frequenti sono gateway di sicurezza o antivirus che aggiungono disclaimer dopo la firma, oppure client di posta che alterano la codifica del testo in fase di inoltro.

1. Verificare se un sistema intermedio modifica il contenuto dopo la firma DKIM.
2. Spostare l’aggiunta di disclaimer o footer prima della fase di firma, non dopo.
3. Passare dalla canonicalizzazione simple/simple a relaxed/relaxed, che tollera piccole variazioni di spaziatura senza invalidare la firma.

Se l’errore indica “signature did not verify”

In questo caso la firma presente nel messaggio non corrisponde alla chiave pubblica pubblicata nel DNS. Occorre confrontare il selettore indicato nella firma con quello effettivamente pubblicato e verificare che la chiave non sia stata sovrascritta da un aggiornamento DNS incompleto.

Se non viene trovato nessun record DKIM

Quando uno strumento di verifica restituisce “no DKIM record found”, il selettore cercato non corrisponde a nessun record TXT pubblicato: può trattarsi di un selettore pubblicato nel sottodominio sbagliato, di una propagazione DNS non ancora completata o di un record rimosso senza aggiornare la configurazione del server di invio.

Se uno strumento come MxToolbox segnala autenticazione fallita

Un test effettuato con uno strumento di diagnostica DNS pubblico confronta il record DKIM atteso con quello effettivamente risolvibile dai server pubblici. Se la verifica fallisce solo da alcune località, il problema è quasi sempre legato alla propagazione DNS ancora in corso; se fallisce ovunque, il record o il selettore pubblicato è errato.

DKIM su piattaforme di posta gestite

Sulle piattaforme di posta aziendale gestite, come Google Workspace, Microsoft 365 o soluzioni di sicurezza email come Mimecast, la generazione della chiave e la pubblicazione del record restano concettualmente identiche a quanto descritto per un server di posta autonomo, ma la console amministrativa automatizza buona parte dei passaggi.

In questi ambienti l’amministratore genera la coppia di chiavi dal pannello di sicurezza, copia il nome host e il valore del record TXT proposti e li incolla presso il provider DNS del dominio, senza intervenire manualmente sulla sintassi della chiave. Dopo l’attivazione, lo stato dell’autenticazione viene mostrato direttamente nella console, insieme a eventuali avvisi relativi a propagazione DNS incompleta o a limiti di caratteri imposti dal provider DNS.

Come verificare se un’email o un dominio sono legittimi

Oltre al controllo tecnico dei protocolli, esistono verifiche complementari utili a stabilire se un messaggio o un dominio mittente sono autentici, rilevanti soprattutto per chi riceve email sospette piuttosto che per chi le invia.

Controllo dell’intestazione email

L’intestazione completa di un messaggio, consultabile tramite la funzione “mostra originale” dei principali client di posta, riporta l’esito di SPF, DKIM e DMARC nella riga Authentication-Results, oltre al percorso dei server attraversati dal messaggio prima della consegna. Un percorso che include server non riconducibili al dominio dichiarato è un indicatore tecnico più affidabile della sola formattazione dell’indirizzo mittente.

Strumenti di verifica dell’indirizzo email

Gli strumenti di verifica email controllano formato, dominio e, dove possibile, l’esistenza effettiva della casella senza inviare un messaggio reale, restituendo un bounce-back in caso di indirizzo inesistente. Questi controlli sono utili per ridurre il tasso di rimbalzo nelle campagne di invio, ma non sostituiscono la verifica di autenticazione del dominio: un indirizzo formalmente valido può comunque appartenere a un dominio privo di protezioni DKIM, SPF o DMARC.

Segnali di un indirizzo email sospetto

Un dominio appena registrato, privo di cronologia pubblica o con informazioni WHOIS oscurate, un mittente che richiede urgenza nell’azione e un esito negativo di DKIM o SPF nell’intestazione sono tre segnali che, combinati, indicano un rischio elevato di messaggio contraffatto. Nessuno di questi elementi, preso singolarmente, è però una prova definitiva di frode.

Domande frequenti

Cosa significa un DKIM fail?

Un DKIM fail indica che il server ricevente non è riuscito a verificare la firma crittografica del messaggio, perché il contenuto è stato alterato dopo la firma, la chiave pubblica non è stata trovata nel DNS o il selettore indicato è errato.

Come si attiva DKIM?

Si attiva generando una coppia di chiavi, pubblicando la chiave pubblica come record TXT nel DNS del dominio e configurando il server di invio affinché firmi ogni messaggio in uscita con la chiave privata corrispondente.

Qual è la differenza tra DKIM e SPF?

SPF autorizza specifici server a inviare per conto di un dominio in base all’indirizzo IP, mentre DKIM verifica, tramite firma crittografica, che il contenuto del messaggio non sia stato alterato e provenga dal dominio dichiarato.

Come controllare se DKIM funziona?

Si invia un’email di prova e si consulta l’intestazione Authentication-Results del messaggio ricevuto, cercando l’esito dkim=pass; in alternativa si interroga direttamente il record TXT con uno strumento di lookup DNS.

Quale lunghezza di chiave DKIM usare?

È consigliata una chiave a 2048 bit per una maggiore resistenza crittografica; una chiave a 1024 bit resta accettabile solo se il provider DNS non supporta record TXT sufficientemente lunghi per la chiave più robusta.

Perché un’email con DKIM corretto finisce comunque in spam?

DKIM verifica solo integrità e identità del dominio firmatario: se SPF fallisce, se non esiste una policy DMARC o se la reputazione del dominio mittente è compromessa, il messaggio può comunque essere filtrato come spam.

Cosa fare se non si trova il record DKIM?

Occorre verificare che il selettore cercato corrisponda esattamente a quello pubblicato, controllare che il record sia stato creato nel sottodominio corretto e attendere la propagazione DNS, che può richiedere fino a 48 ore.

DKIM protegge da tutti i tipi di spoofing?

No: DKIM conferma l’integrità del contenuto e l’autorizzazione del dominio firmatario, ma non impedisce da solo lo spoofing del nome visualizzato o l’uso di domini visivamente simili a quello originale.