Il DKIM (DomainKeys Identified Mail) è una firma digitale che il dominio mittente aggiunge a ogni email. Permette al server destinatario di verificare che il messaggio provenga davvero da quel dominio e che non sia stato modificato lungo il percorso: limita così il furto d’identità (spoofing) e incide sulla deliverability. L’IETF lo ha standardizzato nel 2007 (RFC 4871) e lo ha rivisto nel 2011 (RFC 6376).
Che cosa controlla esattamente un server quando scrive dkim=pass nell’intestazione di un messaggio? Constata che una firma allegata dal dominio mittente corrisponde a una chiave pubblica pubblicata nel DNS di quel dominio e che il corpo del messaggio non è cambiato durante il transito. Nient’altro. Una dashboard di emailing che mostra «DKIM OK» non dice quindi nulla sulla lista di destinatari né sulla reputazione dell’IP.
Dal 1° febbraio 2024 Google richiede l’autenticazione SPF, DKIM e DMARC ai mittenti che inviano più di 5.000 messaggi al giorno verso Gmail. Questa guida legge una firma campo per campo, mostra il record da pubblicare, poi passa al test e alle cause di errore.
L’intestazione DKIM-Signature, campo per campo
Aprite l’originale di un’email ricevuta: l’intestazione somiglia a questa (valori di esempio, firma abbreviata).
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=esempio.it; s=s1; t=1760000000; h=from:to:subject:date:message-id; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=Zm9ybWF0IGQnaWxsdXN0cmF0aW9u...
Ogni tag risponde a una definizione della RFC 6376, pubblicata dall’IETF nel settembre 2011.
| Tag | Valore di esempio | Funzione |
|---|---|---|
| v | 1 | Versione della specifica DKIM |
| a | rsa-sha256 | Algoritmo di firma: RSA con hash SHA-256 |
| c | relaxed/relaxed | Canonicalizzazione di intestazioni e corpo (tolleranza su spazi e a capo) |
| d | esempio.it | Dominio firmatario, confrontato con il dominio del From per l’allineamento DMARC |
| s | s1 | Selettore, che indica quale chiave recuperare nel DNS |
| t | 1760000000 | Timestamp Unix della firma (9 ottobre 2025, ore 08:53 UTC) |
| h | from:to:subject:date:message-id | Elenco delle intestazioni coperte dalla firma |
| bh | 47DEQpj8… | Hash del corpo del messaggio |
| b | Zm9ybWF0… | Firma, calcolata sulle intestazioni elencate in h |
Due tag vengono spesso confusi. bh contiene l’hash del corpo, b la firma vera e propria, calcolata sulle intestazioni di h e sull’intestazione DKIM-Signature stessa (con b vuoto). Un hash SHA-256 pesa 32 byte, cioè 44 caratteri in base64 in bh. Un corpo modificato anche di un solo byte rompe bh; un’intestazione firmata modificata rompe b. L’algoritmo rsa-sha1 è vietato dalla RFC 8301 (gennaio 2018): una firma moderna riporta rsa-sha256. Il tag opzionale l, che limita la parte firmata a un certo numero di byte del corpo, lascia aperta la porta all’aggiunta di contenuto dopo la porzione coperta; la RFC 6376 ne descrive l’uso scorretto nella sezione 8.2.
Dalla firma alla verifica: chi fa cosa
L’espressione comune («cifrare l’hash con la chiave privata») confonde i ruoli. In pratica la sequenza ha quattro tempi.
- Il server di invio (MTA) canonicalizza il corpo, ne calcola l’hash SHA-256 e lo inserisce in bh.
- Calcola poi l’hash delle intestazioni elencate in h, più quello dell’intestazione DKIM-Signature stessa, e firma il risultato con la propria chiave privata. Questa firma diventa b. La chiave privata non lascia mai il server di invio.
- Il server destinatario legge d e s, interroga il DNS su s._domainkey.d e ottiene la chiave pubblica. A questo punto il mittente non interviene più.
- Il destinatario ricalcola l’hash del corpo e lo confronta con bh, poi verifica b con la chiave pubblica. Se i due controlli concordano, il risultato è dkim=pass.
Selettore e record TXT: dove viene pubblicata la chiave
Il selettore, valore del tag s, costruisce il nome DNS che il destinatario interrogherà: s._domainkey.d. Per s=s1 e d=esempio.it la richiesta riguarda s1._domainkey.esempio.it, dove ci si aspetta un record TXT.
s1._domainkey.esempio.it. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
Il tag v indica la versione, k il tipo di chiave, p la chiave pubblica in base64. Un p vuoto segnala una chiave revocata. L’inizio del valore rivela la dimensione: MIIBIjANBgkq… corrisponde a una chiave RSA da 2048 bit, MIGfMA0GCSqG… a una da 1024 bit.
La RFC 8301 impone ai firmatari chiavi RSA di almeno 1024 bit e raccomanda 2048 bit. Una chiave da 1024 bit occupa circa 216 caratteri. Una chiave da 2048 bit ne pesa 392 in base64 e supera i 255 caratteri di una stringa DNS: il record va quindi spezzato in più stringhe tra virgolette, cosa che alcune interfacce DNS fanno da sole e altre no. Ogni strumento di invio (Google Workspace, un CRM, un ESP) riceve un proprio selettore sotto lo stesso dominio, ed è per questo che una zona ne contiene spesso diversi.
Ultima trappola: a seconda dell’interfaccia, il campo «nome host» vuole s1._domainkey da solo oppure il nome completo. Inserire il nome completo dove il dominio viene aggiunto in automatico produce s1._domainkey.esempio.it.esempio.it, che il destinatario non troverà. Questo record vive nella stessa zona degli altri record DNS del mittente (SPF, MX, DMARC): un’unica interfaccia da modificare, un unico proprietario della zona da individuare.
Configurare il DKIM su Google Workspace, Microsoft 365 o un ESP
Su Google Workspace si passa dalla console di amministrazione: App > Google Workspace > Gmail > Autentica l’email. Il pulsante «Genera nuovo record» crea la coppia di chiavi; si copia il valore TXT nella zona DNS, poi si avvia l’autenticazione. Dopo l’attivazione di Gmail, la chiave compare nella console solo dopo 24-72 ore, secondo la documentazione di aiuto di Google Workspace.
Microsoft 365 (Office 365 nelle vecchie documentazioni) funziona in modo diverso. Il portale Microsoft Defender (security.microsoft.com), nella sezione «Email authentication settings», fornisce due selettori chiamati selector1 e selector2, da pubblicare come CNAME verso record ospitati da Microsoft, sul modello selector1-esempio-it._domainkey.tenant.onmicrosoft.com. Firma un solo selettore alla volta e l’altro attende la rotazione successiva: il passaggio avviene senza interruzioni.
Con un ESP, la piattaforma fornisce i record TXT o CNAME da copiare. Finché la zona DNS non li contiene, l’ESP firma con il proprio dominio: il test mostra dkim=pass, ma il dominio d non coincide con il From e la firma non conta per il DMARC. Lo stesso effetto si ha con un gateway in uscita che aggiunge un piè di pagina: il corpo cambia dopo la firma, un caso che la documentazione di Google Workspace segnala espressamente.
Testare il DKIM: leggere Authentication-Results
Inviate un messaggio di prova a una casella Gmail, poi aprite il menu con i tre puntini del messaggio e scegliete Mostra originale. Gmail vi mostra «DKIM: PASS» con il dominio e dettaglia il verdetto nell’intestazione Authentication-Results.
Authentication-Results: mx.google.com; dkim=pass header.i=@esempio.it header.s=s1 header.b=Zm9ybWF0; spf=pass smtp.mailfrom=esempio.it; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=esempio.it
Nella riga dkim, header.s indica il selettore usato, header.i l’identità firmataria, header.b i primi caratteri della firma. Il formato è quello della RFC 8601. I verdetti possibili sono pass, fail (firma non valida), none (nessuna firma), neutral, temperror e permerror (errore DNS temporaneo o definitivo).
Per isolare un problema di DNS prima di qualsiasi invio, il comando dig +short TXT s1._domainkey.esempio.it restituisce il valore pubblicato; un tool di test DKIM online (dkim lookup, dkim checker) esegue la stessa richiesta con il valore di s preso dall’intestazione.
Perché una firma DKIM fallisce
Un dkim=fail dipende quasi sempre da uno di questi casi.
- Il corpo è cambiato dopo la firma, per esempio per un piè di pagina aggiunto da un relay. bh non corrisponde più.
- Il selettore non si trova: refuso o nome host raddoppiato con il dominio.
- La chiave pubblica è troncata: TXT da 2048 bit non spezzato.
- La chiave privata è stata rigenerata dal fornitore senza aggiornare il DNS.
- Il messaggio passa da una mailing list o da un inoltro che riscrive l’oggetto o aggiunge un piè di pagina: la firma originale non copre più il contenuto ricevuto.
- La firma passa ma il dominio d è diverso dal dominio del From: il DMARC la respinge per mancato allineamento.
Allineamento DMARC e requisiti di Gmail e Yahoo
Yahoo applica i suoi requisiti da febbraio 2024: il suo Sender Hub chiede che il dominio del From sia allineato con il dominio SPF o con il dominio DKIM (buone pratiche di Yahoo). In modalità relaxed, il valore predefinito, un d=news.esempio.it si allinea con un From su esempio.it; la modalità strict (adkim=s) richiede l’identità esatta, secondo la RFC 7489 del 2015. Un messaggio inviato da un ESP con d=mailer.esp-esempio.com e un From @esempio.it fallisce quindi l’allineamento DKIM; se anche il Return-Path appartiene all’ESP, fallisce pure l’SPF. Con una policy DMARC impostata su p=reject, un messaggio in cui né l’SPF né il DKIM sono allineati viene rifiutato.
Le soglie cambiano in base al volume. Per qualsiasi mittente verso Gmail, Google chiede SPF o DKIM dal 1° febbraio 2024; oltre i 5.000 messaggi al giorno servono entrambi. Google chiede anche un DMARC pubblicato (basta p=none), record DNS diretti e inversi validi e una connessione TLS; il formato dei messaggi segue la RFC 5322. Sul fronte della reputazione, la pagina indica un tasso di spam sotto lo 0,10% in Postmaster Tools e vieta di raggiungere lo 0,30%. Yahoo richiede SPF e DKIM insieme, un DMARC almeno in p=none e lo stesso tetto dello 0,3%. L’SPF da solo non basta quindi più per un grande volume.
Rotazione delle chiavi
Sostituire una chiave senza interruzioni richiede due selettori, per esempio s1 e poi s2. Si pubblica la nuova chiave sotto s2 mentre s1 firma ancora, si sposta la firma su s2, poi si lascia s1 nel DNS il tempo necessario perché i messaggi in coda vengano verificati. Eliminarlo troppo presto provoca dkim=fail su invii legittimi, che si scambiano a torto per un guasto del DNS.
Che cosa il DKIM non verifica
Uno spammer può firmare i propri invii con un dominio proprio e ottenere dkim=pass: la firma prova l’origine del messaggio, ma non giudica né il contenuto né la qualità della lista. Un dominio firmato alla perfezione che scrive a indirizzi inesistenti accumula hard bounce, e la sua reputazione di mittente ne risente comunque.
Prima della prossima campagna, fate passare un campione della lista da una verifica degli indirizzi: il risultato indica quanti indirizzi non validi contiene la base prima che emergano in Postmaster Tools.
