Cos'è DKIM?
DKIM (DomainKeys Identified Mail) è un protocollo di autenticazione delle email che usa la crittografia a chiave pubblica per verificare che un messaggio email sia stato inviato da un server autorizzato e che il contenuto del messaggio non sia stato alterato durante il transito. Il server mittente firma i messaggi in uscita con una chiave privata e il server ricevente verifica la firma usando una chiave pubblica pubblicata nel DNS del mittente. A differenza di SPF, che verifica solo l'indirizzo IP del server mittente, DKIM verifica l'integrità del messaggio e sopravvive all'inoltro delle email. DKIM è definito nell'RFC 6376.
Questa guida fa parte della nostra guida completa a DKIM. Correlati: il record DKIM e come funzionano le firme DKIM.
DKIM - DomainKeys Identified Mail - è il secondo pilastro della moderna autenticazione delle email. Mentre SPF verifica che un messaggio sia stato inviato da un server autorizzato, DKIM va oltre: firma crittograficamente il messaggio stesso, dimostrando che il contenuto non è stato manomesso e che il dominio mittente dichiarato ha effettivamente autorizzato il messaggio.
RFC 6376 definisce DKIM come un metodo per associare un nome di dominio a un messaggio email, consentendo così a una persona, un ruolo o un’organizzazione di rivendicare una certa responsabilità per il messaggio. La firma sopravvive all’inoltro delle email, il che rappresenta un vantaggio cruciale rispetto a SPF.
Comprendere DKIM è essenziale per chiunque gestisca un’infrastruttura email, perché l’allineamento DKIM è uno dei due percorsi per superare l’autenticazione DMARC - e per la posta inoltrata è spesso l’unico percorso.
Come funziona DKIM: il quadro generale
DKIM opera su un semplice principio crittografico: il server mittente firma il messaggio con una chiave privata e il server ricevente verifica la firma con una chiave pubblica pubblicata nel DNS.
Il processo di firma (in uscita)
- Il server di posta mittente genera un hash di intestazioni email specifiche e del corpo del messaggio
- Il server cifra questo hash usando la chiave privata DKIM del dominio
- Il server aggiunge un’intestazione
DKIM-Signatureal messaggio contenente l’hash cifrato, il nome del selettore, il dominio firmatario e i metadati su quali intestazioni sono state firmate - Il messaggio viene trasmesso al server ricevente
Il processo di verifica (in entrata)
- Il server ricevente estrae l’intestazione
DKIM-Signaturedal messaggio - Legge i valori
d=(dominio) es=(selettore) dalla firma - Esegue un lookup DNS per
<selector>._domainkey.<domain>per recuperare la chiave pubblica - Usa la chiave pubblica per decifrare la firma e recuperare l’hash originale
- Calcola in modo indipendente l’hash delle stesse intestazioni e del corpo usando l’algoritmo specificato
- Se i due hash corrispondono, la firma è valida - il messaggio è autentico e non modificato
Per una spiegazione tecnica dettagliata di questo processo, vedi Come funziona DKIM: una guida completa all’autenticazione delle email.
Per i dettagli a livello di RFC dell’algoritmo di verifica, vedi Dentro l’RFC 6376: come funziona davvero la verifica DKIM.
L’intestazione DKIM-Signature
Un’intestazione di firma DKIM ha questo aspetto:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; t=1618884473;
h=from:to:subject:date:message-id;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
| Tag | Significato |
|---|---|
v=1 | Versione DKIM (sempre 1) |
a=rsa-sha256 | Algoritmo di firma |
d=example.com | Dominio firmatario (usato per l’allineamento DMARC) |
s=selector1 | Selettore - identifica quale chiave pubblica usare |
c=relaxed/relaxed | Metodo di canonicalizzazione per intestazione/corpo |
q=dns/txt | Metodo di interrogazione per la chiave pubblica |
t=1618884473 | Timestamp della firma |
h=from:to:subject:... | Elenco delle intestazioni incluse nella firma |
bh=... | Hash del corpo |
b=... | La firma stessa |
Chiavi DKIM: pubbliche e private
DKIM usa la crittografia asimmetrica. Il proprietario del dominio genera una coppia di chiavi:
- Chiave privata - Conservata in modo sicuro sul server di posta mittente. Mai condivisa né pubblicata. Usata per firmare i messaggi in uscita.
- Chiave pubblica - Pubblicata nel DNS come record TXT all’indirizzo
<selector>._domainkey.<domain>. Usata dai server riceventi per verificare le firme.
Formato del record DNS
Un record DNS DKIM ha questo aspetto:
selector1._domainkey.example.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
| Tag | Significato |
|---|---|
v=DKIM1 | Versione |
k=rsa | Tipo di chiave (RSA è lo standard; Ed25519 è emergente) |
p=... | La chiave pubblica, codificata in base64 |
Puoi cercare la chiave pubblica DKIM di qualsiasi dominio usando lo strumento di lookup DKIM.
Dimensioni delle chiavi
- RSA a 1024 bit - La dimensione minima consigliata della chiave. Ancora ampiamente usata ma considerata debole per gli standard moderni.
- RSA a 2048 bit - Lo standard attualmente consigliato. Offre una sicurezza robusta ma produce record DNS più lunghi che possono richiedere la suddivisione del record TXT.
- Ed25519 - Un algoritmo più recente ed efficiente che produce firme e chiavi più corte. Supportato da un numero crescente di server di posta ma non ancora universale.
Guida dettagliata: Comprendere gli algoritmi crittografici di DKIM: RS256 vs RS512 e tendenze emergenti
Selettori: gestire più chiavi
I selettori DKIM consentono a un dominio di pubblicare più chiavi DKIM contemporaneamente. Ogni chiave è identificata da una stringa selettore, e il tag s= nell’intestazione DKIM-Signature indica al ricevente quale selettore (e quindi quale chiave pubblica) usare per la verifica.
I selettori servono a diversi scopi:
- Più servizi di invio - Il tuo server di posta principale e ogni servizio di terze parti (SendGrid, Mailchimp, ecc.) possono avere ciascuno la propria coppia di chiavi DKIM con un selettore univoco
- Rotazione delle chiavi - Durante la rotazione delle chiavi, puoi pubblicare la nuova chiave sotto un nuovo selettore mentre il vecchio selettore rimane attivo durante il periodo di transizione
- Separazione per reparto - Team o divisioni diverse possono usare selettori diversi a fini di tracciamento e gestione
Le convenzioni comuni di denominazione dei selettori includono s1, s2, google, sendgrid, k1 o nomi basati sulla data come 202604.
Canonicalizzazione: gestire le modifiche ai messaggi
I messaggi email vengono frequentemente modificati durante il transito - vengono aggiunti o rimossi spazi bianchi, le intestazioni vengono riscritte e le interruzioni di riga possono cambiare. La canonicalizzazione definisce come i processi di firma e verifica normalizzano il messaggio prima dell’hashing, così che modifiche minori non compromettano la firma.
Esistono due modalità di canonicalizzazione, applicate in modo indipendente alle intestazioni e al corpo:
- simple - Quasi nessuna tolleranza alle modifiche. Le intestazioni devono corrispondere esattamente (eccetto per gli spazi bianchi finali). Il corpo è normalizzato solo per le righe vuote finali. Usala quando controlli l’intero percorso di consegna e nessun intermediario modificherà il messaggio.
- relaxed - Più tollerante. I nomi delle intestazioni sono convertiti in minuscolo, gli spazi bianchi sono normalizzati e gli spazi multipli sono ridotti a uno. Nel corpo, gli spazi bianchi finali vengono rimossi da ogni riga. Usala per la maggior parte delle implementazioni reali.
L’impostazione c=relaxed/relaxed (relaxed sia per intestazioni che per corpo) è la configurazione più comune e consigliata.
Allineamento DKIM
L’allineamento DKIM è un concetto DMARC che determina se il dominio nella firma DKIM (valore d=) corrisponde al dominio nell’intestazione From visibile. Questo è cruciale perché DMARC richiede che almeno uno tra SPF e DKIM sia valido e allineato.
Allineamento relaxed
I domini organizzativi devono corrispondere, ma i sottodomini sono ammessi. Ad esempio:
- From:
user@example.comcond=mail.example.com- Supera l’allineamento relaxed (stesso dominio organizzativo) - From:
user@example.comcond=example.com- Supera l’allineamento relaxed
Allineamento strict
I domini devono corrispondere esattamente:
- From:
user@example.comcond=example.com- Supera l’allineamento strict - From:
user@example.comcond=mail.example.com- Fallisce l’allineamento strict
Guida dettagliata: Padroneggiare l’allineamento DKIM: chiavi, firme e perché le email falliscono la verifica
Rotazione delle chiavi DKIM
Le chiavi private DKIM dovrebbero essere ruotate periodicamente per limitare i danni in caso di compromissione di una chiave. Il processo di rotazione prevede:
- Generare una nuova coppia di chiavi con un nuovo selettore
- Pubblicare la nuova chiave pubblica nel DNS
- Configurare il server mittente per firmare con la nuova chiave privata
- Attendere la propagazione DNS e verificare le firme con la nuova chiave
- Rimuovere la vecchia chiave pubblica dal DNS dopo un periodo di transizione
Con quale frequenza ruotarle? Non esiste uno standard universale, ma le raccomandazioni comuni vanno da ogni 6 mesi a ogni anno. Gli ambienti ad alta sicurezza possono ruotarle più frequentemente.
Guida dettagliata: Quando dovresti ruotare le tue chiavi DKIM?
Perché DKIM fallisce
La verifica DKIM può fallire per diversi motivi:
Modifica del messaggio durante il transito
Se un’intestazione firmata o il corpo del messaggio vengono modificati dopo la firma, l’hash non corrisponderà e la verifica fallirà. I responsabili comuni includono:
- Mailing list che aggiungono footer o modificano la riga dell’oggetto
- Gateway email che riscrivono le intestazioni per conformità o scansione di sicurezza
- Servizi di inoltro che alterano le intestazioni dei messaggi
Problemi DNS
- Il record della chiave pubblica DKIM non esiste o è irraggiungibile
- Il selettore nella firma non corrisponde ad alcuna chiave pubblicata
- Ritardi di propagazione DNS dopo una rotazione delle chiavi
Errori di configurazione
- La chiave privata non corrisponde alla chiave pubblica pubblicata
- L’algoritmo di firma specificato nella firma non corrisponde al tipo di chiave
- Le intestazioni elencate nel tag
h=non erano incluse nel calcolo effettivo della firma
Guide dettagliate:
- Perché DKIM fallisce? Cosa puoi fare al riguardo?
- Errore di firma DKIM non valida: ecco come puoi risolverlo
- Evitare gli errori comuni di SPF e DKIM nel 2026
DKIM vs SPF: complementari, non concorrenti
DKIM e SPF servono a scopi diversi e hanno punti di forza diversi:
| Caratteristica | SPF | DKIM |
|---|---|---|
| Cosa verifica | Indirizzo IP del server mittente | Integrità e origine del messaggio |
| Come funziona | Lookup DNS degli IP autorizzati | Verifica della firma crittografica |
| Sopravvive all’inoltro | No - l’inoltro cambia l’IP mittente | Sì - la firma viaggia con il messaggio |
| Protegge l’integrità del contenuto | No | Sì - rileva la manomissione |
| Tipo di record DNS | TXT sul dominio | TXT all’indirizzo selector._domainkey.domain |
| Base dell’allineamento DMARC | Dominio Return-Path | Dominio d= nella firma |
Poiché SPF si rompe durante l’inoltro delle email (l’IP del server di inoltro non è nel record SPF del dominio originale), DKIM è spesso l’unico metodo di autenticazione che supera i controlli per i messaggi inoltrati. Questo rende l’allineamento DKIM essenziale per i domini che usano mailing list, regole di inoltro o qualsiasi infrastruttura di relay.
Guide dettagliate:
- In che modo SPF differisce da DKIM e DMARC
- I tuoi identificatori SPF e DKIM sono allineati?
- Come combinare il test SPF, DKIM e DMARC per la sicurezza
DKIM per la posta inoltrata e in relay
Uno dei vantaggi pratici più importanti di DKIM rispetto a SPF è il suo comportamento durante l’inoltro delle email. Quando un messaggio viene inoltrato attraverso un server intermediario (una mailing list, una regola di inoltro automatico o un servizio di relay), SPF si rompe perché l’indirizzo IP del server di inoltro non è elencato nel record SPF del dominio originale. DKIM, al contrario, sopravvive all’inoltro finché il contenuto del messaggio non viene modificato. Se sei alle prime armi con questa configurazione, le FAQ di AutoSPF rispondono alle domande più comuni sulla configurazione.
Ecco perché DKIM è cruciale per la conformità DMARC in ambienti con:
- Mailing list - Organizzazioni che partecipano a mailing list di settore o gruppi di distribuzione interni
- Inoltro email - Utenti che inoltrano email da un provider all’altro (ad esempio, inoltrare un indirizzo universitario a Gmail)
- Hosting condiviso - Ambienti in cui la posta passa attraverso server di relay condivisi
- Gateway email - Appliance di sicurezza che inoltrano la posta senza modificarne il contenuto
Tuttavia, DKIM si romperà se l’intermediario modifica le porzioni firmate del messaggio. Le modifiche comuni che rompono DKIM includono l’aggiunta di footer, la riscrittura della riga dell’oggetto o la rimozione degli allegati. Software per mailing list come Mailman e LISTSERV spesso aggiungono intestazioni e footer di lista, che possono rompere le firme DKIM basate sul corpo.
La soluzione è configurare DKIM con la canonicalizzazione c=relaxed/relaxed (che tollera piccole modifiche agli spazi bianchi) e assicurarsi che qualsiasi software per mailing list che gestisci sia configurato per preservare le firme DKIM ove possibile.
Schemi comuni di configurazione DKIM
Configurazioni di infrastruttura email diverse richiedono approcci di configurazione DKIM diversi:
Provider singolo
Se tutta la tua posta passa attraverso un unico provider (ad esempio, Google Workspace), quel provider gestisce automaticamente la firma DKIM. Devi solo pubblicare nel tuo DNS la chiave pubblica che ti fornisce.
Più provider con selettori separati
Quando più servizi inviano email per tuo conto, ogni servizio ottiene la propria coppia di chiavi DKIM con un selettore univoco. Ad esempio:
google._domainkey.example.com- Chiave DKIM di Google Workspaces1._domainkey.example.com- Chiave DKIM di SendGridk1._domainkey.example.com- Chiave DKIM di Mailchimp
Ogni servizio firma i messaggi con la propria chiave privata e i destinatari cercano la chiave pubblica corretta in base al selettore nell’intestazione DKIM-Signature.
Firma on-premise
Le organizzazioni che gestiscono i propri server di posta (Exchange, Postfix, Exim) devono generare le proprie coppie di chiavi, installare la chiave privata sul server di posta e pubblicare la chiave pubblica nel DNS. Puoi creare una coppia di chiavi con il nostro generatore DKIM gratuito. Questo ti dà il pieno controllo del processo di firma ma richiede di gestire la generazione, la rotazione e l’archiviazione delle chiavi.
DKIM e TLS: livelli di sicurezza diversi
DKIM e TLS (Transport Layer Security) contribuiscono entrambi alla sicurezza delle email ma operano a livelli diversi:
- TLS cifra la connessione tra i server di posta durante la trasmissione, impedendo l’intercettazione durante il transito. Non verifica l’identità del mittente né protegge dalla falsificazione.
- DKIM verifica l’identità del mittente e l’integrità del messaggio ma non cifra il contenuto del messaggio.
Entrambi sono necessari per una sicurezza email completa.
Guida dettagliata: TLS e DKIM: perché ti servono entrambi per una solida sicurezza delle email
Configurare DKIM per la tua piattaforma
La configurazione DKIM varia in base alla piattaforma email. Il processo generale è:
- Genera una coppia di chiavi DKIM (di solito lo fa la tua piattaforma email)
- Pubblica la chiave pubblica come record DNS TXT nella posizione corretta del selettore
- Abilita la firma DKIM sulla piattaforma di invio
- Verifica la configurazione con un Lookup DKIM
Per istruzioni specifiche per piattaforma, consulta queste guide:
- Guida definitiva alla configurazione di SPF e DKIM di Microsoft 365
- Autenticazione DKIM: una guida completa alla deliverability sicura delle email
- Impostare SPF e DKIM per Salesforce
- Padroneggiare SPF e DKIM per SendGrid
- Guida completa alla configurazione di SPF e DKIM di Mailgun
- Come AutoSPF abilita SPF e DKIM in cPanel
DKIM nello stack di autenticazione
DKIM è uno dei tre protocolli che collaborano per autenticare le email:
- SPF - Verifica che il server mittente sia autorizzato
- DKIM - Verifica l’integrità del messaggio e fornisce una firma a livello di dominio (questa guida)
- DMARC - Collega SPF e DKIM con requisiti di allineamento, definisce la policy di enforcement e abilita il reporting
DMARC richiede che almeno uno tra SPF e DKIM superi i controlli e sia allineato con il dominio dell’intestazione From. In pratica, configurare sia SPF che DKIM massimizza le tue possibilità di superare DMARC, perché se un metodo fallisce (ad esempio, SPF fallisce a causa dell’inoltro), l’altro può comunque fornire un risultato valido e allineato.
Guide dettagliate:
- Come SPF, DKIM e DMARC collaborano durante i fallimenti di autenticazione
- Protocolli di autenticazione delle email: SPF, DKIM, DMARC spiegati
- Come testare la compatibilità dello SPF Flattener con DMARC e DKIM
Strumenti diagnostici
- Strumento di lookup DKIM - Cerca e convalida le chiavi pubbliche DKIM per qualsiasi dominio e selettore
- Domain Auth Checker - Controlla SPF, DKIM e DMARC in un unico lookup
- SPF Checker - Convalida il tuo record SPF insieme a DKIM
- DMARC Checker - Verifica la tua policy DMARC e le impostazioni di allineamento
Prossimi passi
- Verifica la tua attuale configurazione DKIM - Usa lo strumento di lookup DKIM per controllare se il tuo dominio ha chiavi DKIM valide pubblicate
- Controlla l’allineamento - Assicurati che il dominio
d=nelle tue firme DKIM corrisponda al dominio della tua intestazione From - Rivedi la robustezza delle chiavi - Conferma di usare chiavi RSA di almeno 2048 bit
- Pianifica la rotazione delle chiavi - Stabilisci un calendario di rotazione e documenta il processo
- Distribuisci DMARC - Se non l’hai già fatto, configura DMARC per applicare l’allineamento di SPF e DKIM e ricevere report aggregati
- Monitora con i report DMARC - Usa i report aggregati DMARC per identificare i fallimenti DKIM su tutti i server riceventi