DKIM è un sistema di autenticazione della posta elettronica che permette a un dominio di applicare una firma crittografica ai messaggi inviati. Il server che riceve l’email può recuperare dal DNS la chiave pubblica associata al dominio e verificare che la firma sia valida.
Il punto importante è che il sistema non coincide con il record pubblicato nel DNS. Quel record rende disponibile la chiave necessaria alla verifica, ma perché tutto funzioni serve anche che il servizio di posta firmi realmente i messaggi con la chiave privata corrispondente.
È proprio questa distinzione a rendere incompleti molti controlli: trovare una chiave nel DNS non dimostra ancora che le email in uscita vengano firmate correttamente.
Il funzionamento del protocollo è definito principalmente dalla RFC 6376, che descrive firme, selector e recupero delle chiavi pubbliche.
DKIM in breve: cosa verifica e cosa non verifica
Prima di configurare record e chiavi conviene chiarire cosa dimostra realmente una firma valida. Il meccanismo autentica tecnicamente un dominio coinvolto nell’invio, ma non certifica da solo l’identità della persona che ha scritto il messaggio né la sicurezza del suo contenuto.
Cosa significa DomainKeys Identified Mail
DKIM significa DomainKeys Identified Mail.
Il suo scopo è associare un dominio a un messaggio attraverso una firma digitale verificabile. Il sistema che invia la posta possiede una chiave privata; la corrispondente chiave pubblica viene resa disponibile attraverso il DNS.
Durante l’invio, il server calcola valori crittografici basati sul corpo del messaggio e su determinati header, quindi aggiunge una firma DKIM nell’intestazione DKIM-Signature.
Il destinatario legge quella firma, identifica dominio e selector, recupera la chiave pubblica e verifica il risultato.
In forma semplificata:
messaggio → firma con chiave privata → DKIM-Signature → lookup DNS → chiave pubblica → verifica
Questo significa anche che il meccanismo non cifra il contenuto dell’email. La sua funzione è consentire una verifica crittografica e rilevare modifiche rilevanti alle parti firmate, non impedire a soggetti non autorizzati di leggere il messaggio.
Cosa dimostra una firma valida
Una verifica riuscita dimostra che la firma presente nel messaggio è compatibile con la chiave pubblica pubblicata dal dominio indicato nell’header e che le parti firmate non sono cambiate in modo incompatibile con il processo di canonicalizzazione utilizzato.
Non significa però automaticamente che la persona indicata nel campo From: sia chi sostiene di essere.
La RFC 6376 separa infatti il dominio che firma il messaggio dall’autore apparente dell’email. Il dominio usato per la firma si trova nel parametro d= dell’header DKIM-Signature.
Questo è uno dei motivi per cui l’autenticazione della posta viene normalmente completata con SPF e soprattutto DMARC, che può verificare l’allineamento tra il dominio visibile al destinatario e i domini autenticati.
Perché una firma valida non garantisce che un’email sia sicura o finisca in inbox
Una firma valida è un segnale tecnico importante, ma non è un certificato di affidabilità del contenuto.
Un dominio controllato da un criminale può firmare correttamente le proprie email. Un account legittimo compromesso può inviare messaggi autenticati. Anche un messaggio tecnicamente verificato può contenere link fraudolenti.
È quindi sbagliato tradurre dkim=pass in “questa email è sicuramente sicura”.
Lo stesso vale per la deliverability. L’autenticazione è una parte dell’infrastruttura di invio, non l’unico criterio utilizzato dai provider per decidere dove collocare un messaggio. Reputazione, segnalazioni spam, qualità delle liste, caratteristiche dell’invio e altri segnali continuano a contare.
Se vuoi approfondire il problema dal lato dell’attacco e dell’impersonificazione, nella guida al phishing trovi il contesto di sicurezza più ampio.
L’autenticazione è comunque diventata un requisito operativo importante. Google richiede almeno SPF o DKIM per i mittenti che inviano verso account Gmail personali; per chi supera determinate soglie di invio verso Gmail richiede SPF, questo sistema di firma e DMARC, insieme ad altri requisiti. Google indica inoltre chiavi RSA di almeno 1024 bit e raccomanda 2048 bit quando supportati dal provider.
Come funziona DKIM dalla firma alla verifica
Il processo coinvolge due lati distinti: chi invia firma il messaggio usando una chiave privata, mentre chi riceve recupera dal DNS la chiave pubblica necessaria per controllare quella firma.
Capire questa sequenza è più utile che memorizzare singoli record.
Chiave privata, hash e firma del messaggio
La coppia di chiavi è il cuore del sistema.
La chiave privata resta nel servizio che firma la posta e non deve essere pubblicata nel DNS. La chiave pubblica deve invece essere raggiungibile dai server destinatari.
Durante l’invio il sistema lavora sul corpo del messaggio e su determinati header. L’intestazione DKIM-Signature contiene diversi parametri che descrivono come è stata costruita la firma.
Tra quelli più utili per la diagnostica:
d=identifica il dominio che firma;s=identifica il selector;a=indica l’algoritmo;h=elenca gli header inclusi nella firma;bh=contiene l’hash del corpo;b=contiene il valore della firma.
Non serve memorizzare ogni tag per completare una configurazione. Per il troubleshooting, però, d= e s= sono fondamentali perché indicano dove cercare la chiave effettivamente utilizzata dal messaggio.
Come il destinatario recupera la chiave pubblica dal DNS
Supponiamo che una firma contenga:
d=example.com s=mail2026
Il verificatore costruisce un nome DNS basato sul selector e sul dominio:
mail2026._domainkey.example.com
La RFC 6376 definisce _domainkey come namespace dedicato alle chiavi pubbliche e specifica il DNS come parte del meccanismo di recupero.
Il destinatario può così ottenere la chiave associata a quel selector e usarla per controllare la firma.
Il selector risolve anche un problema pratico: uno stesso dominio può avere più chiavi contemporaneamente.
Questo permette, per esempio, di utilizzare chiavi diverse per servizi di invio differenti oppure di preparare una nuova chiave prima di dismettere quella precedente.
Come leggere DKIM-Signature: dominio, selector e firma
Un header reale può essere molto lungo, ma per una prima diagnosi bastano pochi elementi.
Esempio semplificato:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail2026; h=From:Date:Subject; bh=...; b=...
Il parametro d=example.com mostra il dominio che ha firmato il messaggio.
Il valore s=mail2026 identifica invece il selector DKIM usato per individuare la chiave.
L’algoritmo rsa-sha256 indica il metodo crittografico impiegato.
Questa lettura è molto più affidabile che provare a indovinare il selector partendo soltanto dal dominio. Se hai già un messaggio realmente inviato, l’header ti dice direttamente quale valore è stato utilizzato.
Record DKIM e selector: dove si trova la chiave pubblica
La chiave pubblica non viene cercata genericamente sul dominio. Il destinatario deve conoscere anche il selector indicato nella firma, perché è la combinazione dei due valori a determinare il nome DNS da interrogare.
Come funziona selector._domainkey.dominio
Un record DKIM è associato a un selector.
Non esiste quindi necessariamente un unico record chiamato semplicemente “DKIM” valido per tutti i servizi che utilizzano il dominio.
Puoi incontrare nomi come:
selector1._domainkey.example.com google._domainkey.example.com mail._domainkey.example.com
La parte prima di ._domainkey è il selector.
Se utilizzi più piattaforme per spedire email — per esempio posta aziendale, newsletter e un servizio transazionale — ciascuna può utilizzare una propria coppia di chiavi.
È anche il motivo per cui non conviene cancellare un record soltanto perché ne hai trovato un altro. Potrebbero appartenere a servizi differenti ancora attivi.
Se vuoi capire meglio in quale livello dell’infrastruttura stai intervenendo, la guida su cos’è il DNS e come funzionano i record distingue zona autorevole, resolver, TXT, CNAME, MX e altri elementi che spesso vengono confusi durante queste configurazioni.
Record TXT o CNAME: perché dipende dal provider
La specifica utilizza record TXT per rendere disponibile la chiave. Nella pratica, però, il pannello del tuo provider può chiederti di pubblicare un CNAME invece di inserire direttamente la chiave pubblica.
Non è necessariamente un errore.
In questo scenario il CNAME delega quel nome DNS a una destinazione gestita dal provider, che può occuparsi delle chiavi senza costringerti ad aggiornare manualmente il valore ogni volta.
Microsoft 365 è un esempio concreto: per i domini personalizzati utilizza record CNAME dedicati e può alternare i selector durante la rotazione delle chiavi. La procedura è descritta nella documentazione Microsoft per la configurazione DKIM.
Altri servizi possono proporre implementazioni differenti.
La regola pratica è quindi semplice: non costruire il record partendo da un tutorial generico. Recupera la configurazione direttamente dal servizio che invia la posta e pubblica esattamente nome, tipo e destinazione richiesti.
Chiavi da 1024 e 2048 bit e rotazione dei selector
Per RSA, la RFC 8301 ha aggiornato i requisiti crittografici del protocollo: le chiavi devono essere almeno di 1024 bit e l’uso di dimensioni pari o superiori a 2048 bit è raccomandato quando possibile.
La stessa specifica ha inoltre rafforzato l’uso di rsa-sha256 rispetto ai vecchi algoritmi basati su SHA-1.
La RFC 8463 ha successivamente definito anche Ed25519-SHA256, la cui disponibilità pratica dipende però dal software e dal provider utilizzato.
In un servizio gestito non conviene scegliere autonomamente algoritmo e formato se la piattaforma si occupa già delle chiavi. È preferibile seguire l’implementazione supportata.
La presenza dei selector permette inoltre la rotazione delle chiavi: una nuova coppia può essere preparata e pubblicata senza dover riutilizzare indefinitamente quella precedente.
Come configurare DKIM sul proprio dominio
Non esiste una stringa universale da copiare. Chiave, selector e tipo di record dipendono dal servizio che firma realmente le tue email.
Per questo la configurazione deve partire dal sistema di invio, non dal pannello DNS.
- Individua tutti i servizi che inviano email usando il dominio. Considera posta aziendale, newsletter, CRM, ecommerce, email transazionali, ticketing e piattaforme SaaS. Uno stesso dominio può avere più sender legittimi.
- Apri la configurazione di autenticazione del servizio interessato. È il provider a doverti fornire selector, nome DNS, tipo di record e relativo valore o destinazione.
- Pubblica il record nella zona DNS autorevole. Controlla di modificare la zona realmente delegata, non un vecchio pannello rimasto associato all’hosting.
- Rispetta il formato richiesto. Se il provider indica TXT, inserisci il TXT. Se indica CNAME, non trasformarlo arbitrariamente in un altro tipo.
- Attendi che il dato sia interrogabile pubblicamente. TTL e cache possono fare in modo che resolver differenti vedano temporaneamente risultati diversi.
- Attiva la firma nel provider, se esiste un passaggio separato. Pubblicare la chiave non obbliga automaticamente ogni servizio a iniziare a firmare.
- Invia un messaggio reale verso un sistema esterno e controlla gli header. È questo il passaggio che completa davvero la verifica.
Il quarto e il sesto punto evitano una parte rilevante degli errori.
Un record perfettamente pubblicato può infatti rimanere inutilizzato se il servizio non è stato abilitato alla firma. Viceversa, il server può tentare di firmare usando un selector la cui chiave non è raggiungibile correttamente.
Come fare un test DKIM e verificare che funzioni davvero
Una verifica affidabile deve separare due controlli diversi: DNS e messaggio reale. Il primo dimostra che la chiave è raggiungibile; il secondo dimostra che il sistema di invio la sta effettivamente usando.
Verificare record e selector nel DNS
Il primo livello di controllo consiste nell’interrogare il nome corretto.
Se dall’header hai ottenuto:
d=example.com s=mail2026
devi verificare:
mail2026._domainkey.example.com
Se il provider usa direttamente un TXT, dovresti ottenere il record contenente la chiave pubblica.
Se usa un CNAME, dovresti vedere la delega prevista e verificare che conduca alla destinazione gestita dal servizio.
Questo controllo può individuare problemi come selector inesistente, nome errato o record pubblicato nella zona sbagliata.
Ma non basta.
Inviare un’email reale e controllare DKIM-Signature
Il secondo controllo è più importante: manda un messaggio dal servizio che vuoi verificare verso una casella esterna.
Non limitarti all’interrogazione DNS.
Apri gli header completi del messaggio ricevuto e cerca:
DKIM-Signature:
Se l’header non esiste, quel particolare messaggio potrebbe non essere stato firmato.
Se esiste, guarda soprattutto d= e s=.
Questi valori permettono di confrontare la firma realmente utilizzata con la configurazione pubblicata.
Microsoft raccomanda infatti di completare la verifica inviando un messaggio verso un sistema esterno e controllando sia DKIM-Signature sia il successivo risultato di autenticazione.
Leggere Authentication-Results
Il passaggio successivo è cercare l’header:
Authentication-Results:
Puoi trovare, per esempio:
dkim=pass
Un pass indica che la firma è stata verificata con successo dal sistema che ha prodotto quell’header.
Il risultato deve comunque essere letto nel contesto del messaggio completo. È possibile avere più firme contemporaneamente e ciascuna può riferirsi a un dominio differente.
Perché un record corretto può esistere anche se le email non vengono firmate
Questo è uno degli errori diagnostici più comuni.
Il DNS risponde correttamente, quindi si conclude che l’autenticazione funziona.
In realtà hai verificato soltanto che una chiave è pubblicata.
Il servizio potrebbe non firmare affatto, usare un selector differente, firmare con un altro dominio, utilizzare una chiave ruotata oppure applicare la firma soltanto a determinati flussi.
La prova completa richiede quindi due livelli:
DNS corretto + messaggio reale firmato e verificato
Solo il primo non chiude il controllo.
DKIM, SPF e DMARC: cosa cambia
I tre meccanismi vengono spesso nominati insieme, ma non svolgono la stessa funzione. La differenza principale riguarda ciò che viene autenticato e il modo in cui il controllo reagisce a inoltri e modifiche del messaggio.
| Meccanismo | Cosa controlla principalmente | Informazione nel DNS | Punto critico |
|---|---|---|---|
| SPF | se l’IP che invia è autorizzato dal dominio usato nel percorso SMTP | record SPF pubblicato come TXT | l’inoltro può cambiare il server che effettua la consegna |
| DKIM | se una firma associata a un dominio è crittograficamente valida | chiave pubblica individuata tramite selector | modifiche alle parti firmate possono invalidare la firma |
| DMARC | se SPF e/o la firma sono allineati con il dominio visibile nel From: e quale policy applicare | record TXT sotto _dmarc | un semplice pass non implica automaticamente alignment |
SPF controlla l’infrastruttura di invio, DKIM firma il messaggio
SPF verifica se il server che sta inviando il messaggio è autorizzato dal dominio utilizzato nel controllo SPF.
Il secondo meccanismo utilizza invece una firma inserita nel messaggio e una chiave pubblica recuperata attraverso il DNS.
Per questo i due sistemi reagiscono diversamente durante alcuni passaggi intermedi.
Un forwarding tradizionale può creare problemi a SPF perché il server che consegna il messaggio al destinatario non è più necessariamente quello autorizzato dal dominio originario.
Una firma crittografica può invece continuare a essere verificabile dopo l’inoltro se il messaggio non viene modificato nelle parti rilevanti.
DMARC aggiunge allineamento e policy sul dominio visibile
La distinzione decisiva è l’allineamento.
Un messaggio può ottenere dkim=pass per un dominio che non coincide con quello visibile all’utente nel campo From:.
DMARC verifica invece se il dominio autenticato tramite SPF oppure tramite firma è adeguatamente allineato con quello del From: e consente al proprietario del dominio di pubblicare una policy.
La specifica corrente è la RFC 9989, che ha sostituito la precedente RFC 7489.
Se stai lavorando sulla deliverability di campagne, newsletter o automazioni, nella guida all’email marketing trovi questi meccanismi inseriti nel contesto più ampio di reputazione, consenso, liste, contenuti e recapito.
Perché la firma può sopravvivere all’inoltro e fallire se il messaggio viene modificato
Il controllo crittografico non dipende semplicemente dall’indirizzo IP del server che effettua l’ultima consegna.
Per questo può rimanere valido durante un forwarding.
Ma non significa che sia indistruttibile.
Servizi intermedi possono modificare oggetto, corpo, MIME, allegati o header. Se la modifica interessa elementi coperti dalla firma in un modo che la canonicalizzazione non assorbe, la verifica può fallire.
La RFC 6376 considera esplicitamente la possibilità che modifiche apportate durante il transito rendano una firma non più verificabile.
Errori DKIM più comuni e come diagnosticarli
Quando una verifica fallisce, cambiare subito il record DNS non è sempre la soluzione corretta. Conviene individuare prima a quale livello si trova il problema: chiave pubblicata, firma generata oppure messaggio modificato dopo l’invio.
Selector sbagliato o record pubblicato nella zona DNS errata
Se il destinatario cerca:
mail2026._domainkey.example.com
ma tu hai pubblicato la chiave sotto:
default._domainkey.example.com
la semplice presenza di una chiave sul dominio non risolve il problema. Il selector della firma deve condurre alla chiave corretta.
Lo stesso accade quando il record viene aggiunto in un pannello DNS che non gestisce più la zona autorevole del dominio.
Prima di modificare i valori, controlla quindi selector reale del messaggio e nameserver effettivamente delegati.
TXT e CNAME configurati in modo diverso da quanto richiesto dal provider
Un’altra fonte di errore è applicare una ricetta universale.
Se il provider richiede:
selector1._domainkey → CNAME → destinazione.provider.example
non devi sostituirlo con un TXT costruito manualmente.
Viceversa, se il servizio ti fornisce direttamente una chiave pubblica da pubblicare come TXT, devi mantenere quella configurazione.
I due tipi di record possono comparire entrambi nelle implementazioni reali, ma non sono intercambiabili a piacere.
Il servizio invia senza firmare o usa un dominio diverso
Una query DNS può funzionare mentre il controllo sul messaggio fallisce perché il servizio non sta utilizzando quella configurazione.
Controlla l’header DKIM-Signature.
Se manca, verifica che la firma sia realmente attivata nel servizio.
Se è presente, confronta d= con il dominio atteso e s= con il selector pubblicato.
È inoltre possibile trovare più firme nello stesso messaggio. Non fermarti quindi alla prima occorrenza: verifica quale riguarda il dominio che stai configurando.
La chiave è stata ruotata ma il DNS non è aggiornato
La rotazione evita di utilizzare indefinitamente la stessa coppia crittografica.
Durante il passaggio da una chiave alla successiva possono coesistere selector differenti.
Se il sistema inizia a firmare con il nuovo selector prima che la relativa chiave sia disponibile ai destinatari, la verifica può fallire.
Al contrario, eliminare troppo presto il vecchio selector può creare problemi a flussi che non hanno ancora completato la migrazione.
Nei servizi che gestiscono automaticamente la rotazione conviene quindi seguire il modello previsto dal provider invece di cancellare manualmente record che sembrano duplicati.
Il messaggio viene modificato dopo la firma
Se la verifica funziona all’uscita dal sistema mittente ma fallisce dopo il passaggio attraverso un gateway, una mailing list o un altro intermediario, controlla il percorso del messaggio.
Una modifica successiva alla firma può essere la causa.
È un caso diverso da un record DNS errato: la chiave può essere corretta e il messaggio può essere stato firmato perfettamente prima che un sistema intermedio cambiasse le parti protette.
La diagnostica dovrebbe quindi distinguere:
problema della chiave → problema della firma → modifica successiva del messaggio
Sono tre livelli differenti.
Conclusione
DKIM diventa molto più semplice da capire quando smetti di considerarlo soltanto come “un record da aggiungere al DNS”.
Il processo completo è:
servizio di invio → chiave privata → firma → selector → DNS → chiave pubblica → verifica del destinatario
Il dato pubblicato nel DNS è necessario, ma rappresenta soltanto un anello della catena.
Quando configuri l’autenticazione, parti sempre dal provider che invia realmente le email, pubblica selector e record richiesti nella zona autorevole, quindi invia un messaggio verso un sistema esterno e controlla DKIM-Signature e Authentication-Results.
Se il DNS risponde ma nell’email non compare una firma verificabile, il lavoro non è ancora concluso.
Per una configurazione completa del dominio, controlla infine anche SPF, allineamento DMARC, servizi di invio effettivamente autorizzati e comportamento degli eventuali sistemi intermedi.