# Cos'è DKIM? Il protocollo di autenticazione email spiegato

URL: https://notificationharbor.com/it/journal/cose-dkim
Type: blog
Locale: it
Published: 2026-09-08
Updated: 2026-09-09

---

> DKIM aggiunge una firma crittografica RSA a ogni email in uscita. L'MTA ricevente la verifica con la chiave pubblica nel DNS prima di decidere dove consegnare il messaggio.

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.

![Due buste digitali protette con lucchetto che rappresentano email DKIM firmate in transito](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/95ba5d-img-2.webp)

## 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.

![Terminale che mostra record DNS TXT per la configurazione del selettore DKIM](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-09/02b314-img-3.webp)

## 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`.

## FAQ

### Cos'è DKIM e come funziona?

DKIM (DomainKeys Identified Mail) è un protocollo crittografico di autenticazione email. Il server di invio firma ogni messaggio in uscita con una chiave RSA privata e allega la firma all'intestazione DKIM-Signature. L'MTA ricevente interroga il DNS per la chiave pubblica corrispondente sotto il sottodominio del selettore, verifica la firma e riporta dkim=pass o dkim=fail. Questo risultato alimenta il punteggio di reputazione della casella di posta e la valutazione dell'allineamento DMARC.

### Cosa protegge DKIM?

DKIM protegge dallo spoofing del dominio esatto: un attaccante che tenta di inviare dal tuo dominio senza accesso alla tua chiave di firma privata. Combinato con una policy DMARC p=reject e l'allineamento DKIM, impedisce a quella categoria di messaggi falsificati di raggiungere le caselle di posta. Non protegge dallo spoofing del nome visualizzato, dallo spam proveniente da domini legittimamente autenticati o dal phishing basato sul contenuto dove l'attaccante controlla il proprio dominio valido.

### Cos'è un selettore DKIM e perché è importante?

Un selettore DKIM è un'etichetta nell'intestazione DKIM-Signature (il campo s=) che indica all'MTA ricevente quale chiave pubblica cercare nel DNS. Il formato della query DNS è selettore._domainkey.tuodominio.com. Su un singolo dominio possono coesistere più selettori, ciascuno puntando a una chiave pubblica diversa. Questo consente una rotazione indipendente delle chiavi per ogni servizio di invio e una revoca pulita: elimina il record DNS del selettore e quel mittente non potrà più firmare come il tuo dominio.

### Con quale frequenza vanno ruotate le chiavi DKIM?

La maggior parte dei team in produzione ruota le chiavi DKIM annualmente. La sequenza sicura è: pubblica la nuova chiave pubblica sotto un nuovo selettore nel DNS, attendi la propagazione del TTL (24-48 ore), cambia la chiave di firma sul tuo MTA al nuovo selettore, verifica dkim=pass sui messaggi di test in uscita, poi elimina il vecchio record DNS. L'eliminazione del vecchio record prima che la nuova chiave sia confermata attiva causa una finestra di dkim=fail.

### DKIM sopravvive all'inoltro email?

Sì, a differenza di SPF. Quando un messaggio viene inoltrato, il mittente dell'envelope SMTP cambia e l'allineamento SPF fallisce rispetto al nuovo IP di invio. L'allineamento DKIM sopravvive all'inoltro perché la firma viaggia con le intestazioni e il corpo del messaggio e non viene riscritta dagli MTA relay, a condizione che il corpo del messaggio non venga modificato in transito. Questo rende DKIM il segnale di autenticazione più affidabile per l'applicazione della policy DMARC sulla posta inoltrata.

### Quale lunghezza di chiave DKIM usare nel 2026?

Usa chiavi RSA a 2048 bit. Il NIST ha deprecato RSA a 1024 bit per la maggior parte degli usi nel 2015, e le chiavi a 1024 bit presentano un rischio calcolabile ai costi di calcolo attuali. Tutti i principali MTA e provider riceventi supportano chiavi a 2048 bit. Se hai ancora selettori legacy a 1024 bit pubblicati nel DNS, verificali: un selettore valido ma deprecato è un'esposizione alla sicurezza anche se la tua attuale infrastruttura di firma ha già migrato a chiavi più lunghe.

### Qual è la differenza tra DKIM, SPF e DMARC?

SPF autentica il dominio del mittente dell'envelope SMTP verificando se l'IP mittente è elencato nel DNS di quel dominio come autorizzato. DKIM autentica il messaggio stesso tramite una firma crittografica su intestazioni e corpo. DMARC usa i risultati di allineamento SPF e DKIM per applicare una policy del proprietario del dominio: none, quarantine o reject. SPF fallisce sull'inoltro; DKIM tipicamente sopravvive. DMARC richiede che almeno un allineamento superi il test prima di applicare la sua policy.