Cos'è DKIM e perché conta nel 2026
DKIM (DomainKeys Identified Mail) è uno standard di autenticazione email definito nell'RFC 6376 che permette a un dominio mittente di firmare crittograficamente i messaggi in uscita. Il destinatario recupera la chiave pubblica corrispondente dal DNS, ricalcola la firma e conferma che il messaggio è stato autorizzato dal proprietario del dominio e non è stato alterato in transito. Senza DKIM, uno spoofer può falsificare il tuo From:, danneggiare la tua sender reputation e dirottare silenziosamente le risposte verso domini simili — un problema che la maggior parte dei team nota solo dopo che la deliverability crolla.
Nel 2026, DKIM non è più opzionale. Le regole bulk-sender di Gmail e Yahoo — applicate da febbraio 2024 e strette nel corso del 2025 — richiedono a ogni dominio che invia oltre 5.000 messaggi al giorno di pubblicare SPF, DKIM e DMARC validi. Microsoft 365 ha annunciato un enforcement equivalente per i mittenti ad alto volume. Un fallimento DKIM non solo abbassa il tasso di inbox; innesca hard reject, report dmarc=fail e in molti casi la rimozione dalla allow-list del destinatario. Validare DKIM settimanalmente è l'assicurazione più economica sulla deliverability che puoi comprare.
Come funziona DKIM — crittografia a chiave pubblica/privata
DKIM si basa sulla crittografia asimmetrica standard. Quando configuri DKIM, la tua piattaforma di posta genera una coppia di chiavi RSA: una chiave privata che tiene sul server mittente e una chiave pubblica che tu pubblichi nel DNS. Ogni messaggio in uscita viene hashato (body + header selezionati), l'hash viene cifrato con la chiave privata e il risultato viene aggiunto come header DKIM-Signature. Il destinatario recupera la tua chiave pubblica dal DNS, decifra la firma, ricalcola l'hash dal messaggio ricevuto e confronta i due. Se corrispondono, DKIM passa; in caso contrario, la firma è rotta e il messaggio è trattato come sospetto.
L'header DKIM-Signature porta i metadati di cui i receiver hanno bisogno per verificare: v= (versione), a= (algoritmo, normalmente rsa-sha256), d= (dominio firmatario), s= (selettore), c= (canonicalizzazione, normalmente relaxed/relaxed), h= (header firmati), bh= (hash del body) e b= (la firma). Insieme dicono al destinatario esattamente quale record DNS recuperare e quali byte sono stati coperti.
Example DKIM-Signature header:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=google;
h=from:to:subject:date:message-id;
bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
b=KX5vRn3...truncated...Cos'è un selettore DKIM?
Un selettore DKIM è una breve etichetta che permette a un singolo dominio di pubblicare più chiavi DKIM contemporaneamente. I receiver trovano la chiave pubblica combinando il selettore e il dominio firmatario in un nome DNS nella forma selettore._domainkey.dominio.com. Per esempio, Google Workspace usa google._domainkey.example.com, mentre un messaggio firmato da Mailgun cerca k1._domainkey.example.com. I selettori sono cruciali perché ti permettono di ruotare le chiavi, far girare in parallelo piattaforme di invio diverse (transazionale, marketing, sales) e mettere in stage chiavi nuove prima di ritirare le vecchie — il tutto senza che due record si scontrino. Non c'è wildcard o fallback su _domainkey.dominio.com stesso; il selettore è obbligatorio.
Example DNS record format:
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."5 errori comuni di DKIM e come risolverli
Il lookup DNS non restituisce nulla
Il receiver ha interrogato selettore._domainkey.iltuodominio.com e ha ottenuto NXDOMAIN. È il fallimento DKIM più comune. Cause: il record TXT non è mai stato pubblicato, è stato pubblicato sotto il selettore sbagliato o è stato aggiunto sull'apex (iltuodominio.com) invece che sul sottodominio del selettore. Risolvi ripubblicando il nome esatto fornito dal tuo provider (es. google._domainkey) come record TXT e verificando la propagazione con dig TXT selettore._domainkey.iltuodominio.com o rieseguendo questo checker. Concedi fino a 48 ore per la propagazione globale.
Chiave pubblica non valida
Il DNS restituisce un record ma il valore p= è malformato, troncato o rifiutato dal receiver. La causa più frequente è una chiave a 2048 bit divisa su più stringhe TXT e riassemblata in modo errato — molte UI DNS aggiungono virgolette, spazi o ritorni a capo casuali. Risolvi copiando la chiave pubblica esattamente come l'ha esportata la tua piattaforma di posta, incollandola come singolo valore TXT (la maggior parte dei provider la divide automaticamente al limite dei 255 byte) e confermando che il record contenga v=DKIM1; k=rsa; p=BASE64KEY senza spazi all'interno del blocco base64.
Mismatch dell'hash del body
DKIM ha firmato bh=ABC ma il receiver ha calcolato bh=XYZ dal body ricevuto, quindi la verifica fallisce. Significa che qualcosa ha modificato il messaggio dopo la firma. Sospetti comuni: un gateway downstream (anti-virus, DLP, mailing list) riscrive i link o aggiunge un footer, un relay SMTP ricodifica i terminatori di riga o un forwarder rimuove gli allegati. Risolvi firmando con canonicalizzazione relaxed/relaxed (tollera modifiche di whitespace), rimuovendo il middleware che riscrive o — per le mailing list — implementando ARC così il DKIM originale viene preservato attraverso gli hop.
Verifica della firma fallita
L'hash del body coincide ma la firma crittografica non si verifica con la chiave pubblica. Cause: il server firmatario ha usato una chiave privata che non corrisponde più alla chiave pubblica pubblicata (comune dopo una rotazione di chiave in cui il DNS è stato aggiornato ma la cache del mail server no), la chiave pubblica nel DNS è stata modificata e corrotta, o l'algoritmo di firma in a= non corrisponde al tipo di chiave. Risolvi riesportando la chiave pubblica dalla piattaforma di invio, ripubblicandola pari pari e riavviando il servizio di posta per ricaricare la chiave privata.
Selettore non trovato / sbagliato
Il tuo mail server sta firmando con il selettore s1 ma il DNS pubblica solo s2, oppure hai migrato provider e il vecchio selettore è stato ritirato. Risolvi controllando il tag s= nell'header DKIM-Signature di una vera email in uscita (la maggior parte dei client permette di vedere gli header completi), confermando che esista un record TXT esattamente su quel selettore e rimuovendo i selettori obsoleti che non hanno più una chiave privata corrispondente — i vecchi selettori con valori p= vuoti causano hard fail.
Setup DKIM passo-passo
- 1
Scegli la lunghezza della chiave (1024 vs 2048 bit)
Nel 2026 scegli sempre RSA a 2048 bit. Le chiavi a 1024 bit sono ancora accettate dalla maggior parte dei receiver, ma Gmail, Yahoo e Microsoft ora le segnalano attivamente come deboli nei report DMARC, e i team di sicurezza falliscono regolarmente gli audit che trovano DKIM a 1024 bit in produzione. L'unica ragione per scendere a 1024 è un provider DNS legacy che non può memorizzare un record TXT oltre i 255 byte — e anche quelli oggi quasi tutti supportano lo split TXT multi-stringa. Le chiavi a 2048 bit aggiungono circa due millisecondi al tempo di firma, trascurabile per qualsiasi mail server di produzione.
- 2
Genera la coppia di chiavi
La maggior parte delle piattaforme genera le chiavi per te — Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark e Amazon SES espongono tutti una pagina di setup DKIM in un click che produce entrambe le metà e ti mostra la chiave pubblica da pubblicare. Se gestisci il tuo server (Postfix + OpenDKIM, Exim o Haraka), usa opendkim-genkey -b 2048 -d iltuodominio.com -s s1 che scrive s1.private (tienila segreta) e s1.txt (pubblicala). Non riutilizzare mai una chiave tra domini o piattaforme.
- 3
Aggiungi la chiave pubblica come record TXT
Crea un record TXT su selettore._domainkey.iltuodominio.com — per esempio s1._domainkey.example.com — con il valore v=DKIM1; k=rsa; p=MIIBIjANBgkq... incollato dal file .txt prodotto dal generatore. Molti provider DNS dividono automaticamente il valore in chunk da 255 byte; va bene, i receiver li riassemblano. Imposta TTL a 3600 secondi durante i test e portalo a 86400 una volta che il record è stabile. Non includere come parte del valore le virgolette di contorno presenti nell'output del generatore.
- 4
Configura il servizio email per firmare con la chiave privata
Sulle piattaforme hosted è automatico una volta pubblicato il record DNS e cliccato Verify. Sui server self-hosted, punta il tuo milter (OpenDKIM, Rspamd) al file .private, imposta il selettore in modo che corrisponda al record DNS e riavvia il processo di posta. Invia un messaggio di test a un indirizzo Gmail e visualizza il sorgente raw — dovresti vedere l'header Authentication-Results: dkim=pass header.d=iltuodominio.com. Se vedi dkim=none, il server non sta ancora firmando; se dkim=fail, le chiavi non corrispondono.
- 5
Testa con un DKIM checker gratuito
Usa questo DKIM Checker per confermare la pubblicazione DNS, poi invia un vero messaggio di test a mail-tester.com o a un account Gmail che controlli e ispeziona gli header. Atteso: Authentication-Results mostra dkim=pass e il selettore corrisponde al record pubblicato. Riesegui il test dopo ogni rotazione di chiave, ogni nuova piattaforma di invio e almeno una volta a trimestre. Aggiungi il check al tuo tool di monitoring così un fallimento DKIM silenzioso non possa abbattere la deliverability per settimane.
Selettori DKIM comuni per provider
Le diverse piattaforme email scelgono ognuna la propria convenzione sui selettori. Conoscere la convenzione rende il troubleshooting molto più rapido — se ricevi un messaggio da Google Workspace e DKIM è rotto, sai già di guardare google._domainkey prima di scandagliare cinquanta alternative. Qui sotto i selettori usati dai principali provider nel 2026:
Google Workspace — google._domainkey.iltuodominio.comMailgun — k1._domainkey.iltuodominio.com (a volte mta._domainkey)SendGrid — s1._domainkey.iltuodominio.com e s2._domainkey.iltuodominio.com (basato su CNAME)Mailchimp — k1._domainkey.iltuodominio.com e k2._domainkey.iltuodominio.comMicrosoft 365 — selector1._domainkey.iltuodominio.com e selector2._domainkey.iltuodominio.comPostmark — pm._domainkey.iltuodominio.com (oppure 20XXXXXXX.pm._domainkey)Amazon SES — selettori random personalizzati tipo abc123._domainkey.iltuodominio.com (basato su CNAME)Mandrill (di Mailchimp) — mandrill._domainkey.iltuodominio.comConstant Contact — ctct1._domainkey.iltuodominio.com e ctct2._domainkey.iltuodominio.comConvertKit — ck._domainkey.iltuodominio.comMailjet — mailjet._domainkey.iltuodominio.comBrevo (ex Sendinblue) — mail._domainkey.iltuodominio.com
Il DKIM Checker di Nova Uptime scansiona automaticamente tutti i selettori sopra più altri 38, in parallelo, così non devi sapere in anticipo quale usa il tuo provider.
Requisiti Gmail e Yahoo 2026
Da febbraio 2024, Gmail e Yahoo applicano un'autenticazione più stringente a ogni dominio che invia oltre 5.000 messaggi al giorno verso i loro utenti. Le regole: ogni messaggio deve essere firmato con un record DKIM valido (raccomandato 2048 bit), SPF deve allinearsi col dominio del From: e va pubblicata una policy DMARC — almeno p=none — con un indirizzo di reporting rua= raggiungibile. Durante il 2025 e nel 2026, entrambi i provider hanno abbassato la soglia di volume e iniziato a rifiutare i messaggi a priori (5.7.26) invece di instradarli nello spam. Microsoft 365 ha avviato un enforcement equivalente a maggio 2025. Effetto pratico: un singolo record DKIM rotto causa ora hard bounce, non solo problemi di posizionamento in inbox, e il recupero richiede giorni perché i report DMARC arrivano con 24 ore di ritardo. Il monitoring continuo non è più opzionale.