Cos'è DKIM? Il protocollo di autenticazione email spiegato
Riassunto
DKIM usa la crittografia RSA a chiave pubblica per attestare l'origine delle email in uscita. Il server mittente firma ogni messaggio con una chiave privata. L'MTA ricevente cerca la chiave pubblica nel DNS tramite il selettore, verifica la firma e riporta il risultato. DKIM non blocca nulla da solo: produce un segnale pass o fail che condiziona l'applicazione della policy DMARC e il punteggio di reputazione dei provider di posta in arrivo.
DKIM (DomainKeys Identified Mail) è un protocollo crittografico di autenticazione email. Cos'è DKIM in termini pratici: associa una firma RSA a ogni messaggio in uscita inviato dal tuo server di posta. L'MTA ricevente recupera la chiave pubblica dal DNS, verifica la firma e riporta il risultato come dkim=pass o dkim=fail. Questo risultato alimenta il modello di reputazione del dominio e determina se l'allineamento DMARC regge. Senza una firma valida, l'MTA ricevente non ha conferma crittografica che il messaggio provenga dalla tua infrastruttura.
DKIM è un protocollo di firma, non un filtro
Il nome genera un malinteso comune. DKIM non blocca le email. Non mette in quarantena i messaggi né applica da solo alcuna politica. Quello che fa è apporre su ogni messaggio in uscita un'attestazione verificabile: questo messaggio è stato firmato dal dominio indicato nel campo d=, utilizzando la chiave privata corrispondente al selettore s=.
L'MTA ricevente prende questa attestazione, costruisce una query DNS verso <selettore>._domainkey.<dominio>, recupera il record TXT contenente la chiave pubblica ed esegue la verifica crittografica. Se la verifica ha esito positivo, l'intestazione dei risultati di autenticazione mostra dkim=pass. In caso di fallimento, compare dkim=fail o dkim=temperror.
Nessuno dei due esiti causa un rifiuto immediato. Il segnale alimenta il modello di reputazione del server ricevente e, in modo determinante, la valutazione DMARC. Il compito di DKIM è produrre un risultato verificabile, non agire su di esso.
Cosa viene firmato e cosa copre la firma DKIM
DKIM firma due elementi: le intestazioni selezionate del messaggio e il corpo. L'algoritmo di firma crea un hash di entrambi e lo memorizza nel campo dell'intestazione DKIM-Signature.
La lista delle intestazioni è controllata dal tag h= nella firma. Una configurazione tipica in produzione include from:subject:date:message-id:content-type. L'intestazione from è quella rilevante per l'allineamento DMARC. L'hash del corpo copre l'intero corpo del messaggio, canonicalizzato con la modalità simple o relaxed.
La canonicalizzazione relaxed è quella usata dalla maggior parte degli stack in produzione. Normalizza gli spazi prima dell'hashing, il che consente alla firma di sopravvivere a piccole riformattazioni da parte degli MTA relay. La canonicalizzazione simple è più rigida: una singola modifica degli spazi finali rompe la firma. Nel campo DKIM-Signature di ogni ESP ben configurato si trova praticamente sempre c=relaxed/relaxed.
Cosa non firma DKIM: il mittente dell'envelope SMTP, le intestazioni di routing come Received e qualsiasi intestazione fuori dalla lista h=. Questo è intenzionale. Firmare l'envelope romperebbe gli scenari di inoltro, che è esattamente il vantaggio di DKIM rispetto a SPF.
Il selettore: meccanismo di controllo accessi spesso trattato come etichetta
Il selettore è la parte di DKIM che la maggior parte dei team sottovaluta finché non deve ruotare le chiavi sotto pressione.
Il campo s= nel tuo DKIM-Signature punta a una chiave pubblica specifica nel DNS. Il formato di lookup è <selettore>._domainkey.<tuodominio.com>. Se il selettore è mail2026 e il dominio è example.com, il resolver cerca un record TXT in mail2026._domainkey.example.com.
Un singolo dominio può avere più selettori attivi simultaneamente. Ogni servizio di invio, ogni ESP, ogni MTA interno dovrebbe usare il proprio selettore. Questo fornisce tre capacità operative concrete:
Rotazione indipendente delle chiavi per servizio senza toccare gli altri mittenti.
Attribuzione tracciabile nei log di autenticazione: il selettore indica quale chiave di firma è stata usata su un dato messaggio.
Offboarding pulito: elimina il record DNS del selettore e quell'ESP non potrà più firmare come il tuo dominio, indipendentemente da quello che fa dalla sua parte.
Quello che si osserva nelle tracce: i team che configurano un selettore condiviso tra tutti i servizi di invio non possono revocare l'accesso a un singolo mittente senza interrompere tutti gli altri. Il selettore non è decorativo. È un meccanismo di controllo degli accessi.
DKIM e allineamento DMARC: come funziona il livello di enforcement
Il superamento di DKIM è un prerequisito per un tipo specifico di pass DMARC chiamato allineamento DKIM.
DMARC richiede almeno una delle due condizioni di allineamento: allineamento SPF o allineamento DKIM. L'allineamento DKIM significa che il dominio nell'intestazione From: corrisponde al valore d= nella firma DKIM e la firma viene verificata. Quando entrambe le condizioni sono soddisfatte, DMARC considera il messaggio autenticato.
Ecco perché DKIM è il segnale di autenticazione più duraturo. L'allineamento SPF si rompe sull'inoltro: quando un messaggio viene inoltrato, il mittente dell'envelope SMTP cambia e la valutazione SPF fallisce rispetto al nuovo IP di invio. L'allineamento DKIM sopravvive all'inoltro perché la firma e l'intestazione From: viaggiano con il corpo del messaggio e non vengono riscritte dagli MTA relay, a condizione che il corpo non venga modificato in transito.
Per i domini con una policy DMARC p=reject, un messaggio che fallisce sia l'allineamento SPF che quello DKIM viene rifiutato dall'MTA ricevente. Questo è il meccanismo che impedisce alle email falsificate del tuo dominio di raggiungere le caselle di posta su larga scala. DKIM non è l'ultima linea di difesa. Ma è la linea che regge quando il percorso include l'inoltro.
Dal 2024, Google, Yahoo e Microsoft richiedono DKIM per i mittenti che inviano 5.000 o più messaggi al giorno ai loro MX. I messaggi provenienti da domini non firmati vengono instradati verso la cartella spam o rifiutati per impostazione predefinita.
Non è una funzionalità di marketing. È un vincolo di infrastruttura.
Lunghezza delle chiavi e rotazione: decisioni pratiche per il 2026
La maggior parte delle implementazioni DKIM usa RSA-SHA256. La questione chiave riguarda la lunghezza delle chiavi.
Le chiavi RSA a 1024 bit compaiono ancora in configurazioni legacy. Il NIST ha deprecato RSA a 1024 bit per la maggior parte degli usi nel 2015. Una chiave a 2048 bit offre un margine di sicurezza significativamente più ampio ed è supportata da ogni MTA e provider ricevente di rilievo. Se stai generando una nuova chiave oggi, usa 2048 bit.
Alcuni team hanno migrato la chiave di firma attiva a 2048 bit ma hanno lasciato pubblicati nel DNS vecchi selettori a 1024 bit perché nessuno ha verificato l'inventario. Tre segnali che cambiano il comportamento del motore: se vedi k=rsa con una chiave a 1024 bit in un vecchio selettore, quel selettore è una vulnerabilità anche se la tua infrastruttura di firma attuale ha già fatto il passaggio. Un selettore valido ma deprecato è sfruttabile.
Programma di rotazione delle chiavi: la maggior parte dei team di infrastruttura ruota annualmente, alcuni trimestralmente per i domini più sensibili. La sequenza è importante:
Genera una nuova coppia di chiavi.
Pubblica la nuova chiave pubblica sotto un nuovo nome di selettore nel DNS.
Attendi la propagazione del TTL, tipicamente 24-48 ore per i record con TTL basso.
Aggiorna la configurazione della chiave di firma sul tuo MTA al nuovo selettore.
Verifica il pass DKIM sui messaggi in uscita tramite uno strumento di test email o ispezionando le intestazioni dei risultati di autenticazione su un messaggio di test.
Dopo aver confermato che la nuova chiave è attiva e firma correttamente, elimina il vecchio record DNS.
La rotazione è non dirompente se si segue l'ordine corretto: prima il DNS, poi il cambio della firma, infine l'eliminazione del vecchio record. Invertire i passi 4 e 6 causa una finestra di dkim=fail.
Segnali operativi da monitorare dopo la configurazione DKIM
DKIM non è un'attività di configurazione una tantum. I seguenti segnali indicano che qualcosa è cambiato o si è interrotto.
dkim=temperror nelle intestazioni ricevute. I fallimenti temporanei indicano solitamente problemi di lookup DNS sul lato ricevente, o una mancata corrispondenza del TTL durante la rotazione delle chiavi. Se vedi questo sui messaggi in uscita poco dopo una rotazione delle chiavi, attendi la propagazione completa prima di concludere che la chiave stessa sia configurata in modo errato.
dkim=fail su messaggi inviati. La modifica del corpo da parte di un relay intermedio è la causa più comune. Verifica se nel percorso di consegna è presente un hop di inoltro, un processore di mailing list o un relay che inietta footer. Se il fallimento è costante su un singolo flusso, mappa la catena dei relay hop per hop.
Intestazione DKIM-Signature completamente assente. Il daemon di firma sul tuo MTA non è in esecuzione, il percorso della chiave di firma è errato o la mappatura dominio-selettore è mal configurata nella configurazione MTA. Questa è un'interruzione completa di DKIM per i flussi di messaggi interessati.
Record TXT del selettore assente dal DNS. La zona DNS è stata modificata o migrata senza conservare il record del selettore DKIM. Verifica con dig TXT <selettore>._domainkey.<dominio> da un resolver esterno.
Su una configurazione di invio multi-regione, risultati DKIM incoerenti tra i nodi sono spesso causati da nodi diversi che usano configurazioni di selettori diverse. Conferma che la configurazione della chiave di firma sia sincronizzata su tutti i nodi di invio prima di distribuire una rotazione.
Cosa DKIM non protegge
DKIM non è un filtro antispam. Un mittente può registrare un nuovo dominio, configurare DKIM valido e inviare spam completamente autenticato. La firma viene verificata senza problemi. L'autenticazione conferma l'origine, non l'intento o la qualità del contenuto.
DKIM non affronta nemmeno lo spoofing del nome visualizzato, dove l'intestazione From: mostra un nome affidabile come "Team Paghe" abbinato a un dominio controllato dall'attaccante. La verifica crittografica opera sul dominio, non sulla presentazione visiva nell'MUA. La maggior parte del phishing a livello MUA si basa sull'inganno del nome visualizzato piuttosto che sullo spoofing del dominio esatto.
Cosa protegge DKIM: lo spoofing del dominio esatto, dove un attaccante tenta di inviare come il tuo dominio senza possedere la tua chiave privata. Combinato con una policy DMARC p=reject che applica l'allineamento DKIM, questo impedisce a quella categoria di messaggi falsificati di raggiungere le caselle di posta presso i provider che applicano DMARC.
Una nota pratica: DKIM da solo non è sufficiente. Il modello di protezione richiede l'applicazione della policy DMARC presso l'MTA ricevente. DKIM è il livello di autenticazione che rende DMARC significativo. SPF è l'altro livello di autenticazione, e gestisce la verifica del mittente dell'envelope. Tutti e tre lavorano insieme. L'assenza di uno qualsiasi lascia una lacuna nella catena di enforcement.
Se hai già configurato DKIM e SPF ma non hai ancora pubblicato un record DMARC, le firme esistono ma nessuna policy di enforcement è attiva. La modalità di monitoraggio (p=none con reporting rua) è un primo passo ragionevole: ottieni report aggregati che mostrano i tassi di autenticazione sul tuo dominio di invio prima di impegnarti su p=quarantine o p=reject.