Se invii posta dal tuo dominio, devi pubblicare record DKIM nel DNS. Configurarli correttamente è importante per l’autenticazione e può favorire la recapitabilità. Senza una firma DKIM verificabile, il destinatario non può usare questo meccanismo per controllare se il contenuto firmato è stato modificato durante il trasporto. Google, Yahoo e Microsoft stabiliscono requisiti di autenticazione per determinati mittenti, soprattutto quelli massivi; DKIM è consigliato anche per i domini a basso volume.
Questa guida copre tutto il processo: generare le chiavi, pubblicare il record DNS, abilitare la firma e verificare il risultato. Senza giri di parole: passaggi, sintassi ed errori comuni. I principi sono gli stessi, sia creando record manualmente sia usando una piattaforma gestita.
Che cos’è un record DKIM?
Un record DKIM è un TXT DNS contenente la parte pubblica di una coppia di chiavi crittografiche. Il server firma i messaggi in uscita con la chiave privata. Il destinatario recupera la chiave pubblica dal DNS e verifica la firma per accertare la responsabilità del dominio firmatario e l’integrità del corpo e delle intestazioni firmate. DKIM è definito nel RFC 6376 ed è un componente fondamentale dell’autenticazione moderna della posta.
Creare record DKIM in 4 passaggi
Passaggio 1: genera la coppia di chiavi DKIM
Prima di pubblicare il record serve una coppia di chiavi: una privata che resta nel sistema firmatario e una pubblica che va nel DNS. Il metodo di generazione dipende dalla configurazione.
Se usi un servizio di posta ospitato (Google Workspace, Microsoft 365, Zoho), il provider genera le chiavi. Devi copiare i record DNS forniti. In Google Workspace, vai a Console di amministrazione > App > Google Workspace > Gmail > Autentica email e fai clic su «Genera nuovo record»; le etichette possono variare.
Se gestisci il tuo server di posta (Postfix, Exim, OpenDKIM), genera la coppia dalla riga di comando:
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pemUsa chiavi da 2048 bit quando il sistema le supporta. Alcune guide datate citano 1024 bit, una dimensione con un margine di sicurezza inferiore nel 2026. L’accettazione delle firme da 1024 bit dipende dal destinatario e dalle sue policy; preferisci chiavi più robuste quando possibile.
Scegli anche un selettore: un’etichetta che identifica questa chiave specifica. I selettori permettono la rotazione delle chiavi o chiavi diverse per servizi diversi. Convenzioni comuni sono google, s1, mail2026 oppure il nome del servizio, come sendgrid.
Passaggio 2: aggiungi la chiave pubblica al DNS
Qui pubblichi il record DKIM nel DNS del dominio. Il procedimento è solitamente semplice. Accedi al provider DNS (Cloudflare, Route 53, GoDaddy, Namecheap) e aggiungi un TXT, oppure il tipo di record richiesto dal provider di invio.
Campo Host/Nome:
selector._domainkey.yourdomain.comSostituisci selector con il nome scelto nel passaggio 1. Con il selettore s1 e il dominio example.com, il nome completo è:
s1._domainkey.example.comCampo Valore:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u...truncated...base64encodedpublickeyIl tag p= contiene la chiave pubblica completa come stringa base64. Rimuovi le intestazioni PEM (-----BEGIN PUBLIC KEY-----) e le interruzioni di riga: i dati della chiave devono formare una stringa continua. L’esempio è abbreviato e non è una chiave utilizzabile.
Importante: Ogni stringa di un TXT DNS ha un limite di 255 caratteri a byte singolo. Una chiave RSA da 2048 bit supera questa lunghezza dopo la codifica. Alcuni provider dividono automaticamente il valore in stringhe tra virgolette; altri richiedono frammenti manuali di massimo 255 caratteri, racchiusi tra virgolette doppie. Il verificatore concatena le stringhe dello stesso record.
Passaggio 3: abilita la firma DKIM sul server
Pubblicare il record DNS non basta. Il server deve firmare attivamente i messaggi in uscita con la chiave privata corrispondente.
Google Workspace: Fai clic su «Avvia autenticazione» nel pannello dove hai generato la chiave, secondo l’interfaccia attuale.
OpenDKIM (Postfix/Exim): Modifica /etc/opendkim.conf:
Selector s1
KeyFile /etc/opendkim/keys/example.com/dkim_private.pem
Domain example.com
Socket inet:8891@localhostPoi aggiungi il milter a Postfix in /etc/postfix/main.cf:
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891Riavvia entrambi i servizi dopo aver verificato i parametri per la tua installazione:
sudo systemctl restart opendkim
sudo systemctl restart postfixI provider di invio esterni (SendGrid, Mailgun, Amazon SES) hanno procedure proprie. Il modello abituale è ricevere CNAME o TXT, pubblicarli nel DNS e fare clic su «Verifica» nel pannello. Segui le istruzioni attuali del servizio.
Passaggio 4: verifica il record
Non supporre che funzioni. Verifica fin dall’inizio.
Dalla riga di comando:
dig TXT s1._domainkey.example.com +shortLa risposta dovrebbe contenere la chiave pubblica. Se è vuota, controlla nome, tipo di record, DNS autoritativo e cache. Alcune guide suggeriscono di attendere fino a 48 ore, anche se molti TXT diventano visibili in pochi minuti; i tempi dipendono dal TTL e non fanno comparire un record errato.
Con un’email di prova: Invia a un indirizzo Gmail e controlla le intestazioni originali. Cerca:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=s1Se trovi dkim=pass, la firma di quel test è stata convalidata. Con dkim=fail o dkim=neutral, esamina la configurazione e il motivo specifico del risultato; la prossima sezione presenta gli errori comuni.
La sintassi del record DKIM
Comprendere la sintassi aiuta a pubblicare record corretti, soprattutto la prima volta. Ecco i componenti:
v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQE...| Tag | Obbligatorio | Significato |
|---|---|---|
v=DKIM1 | Sì | Versione. Se presente, deve essere DKIM1 e comparire per prima. |
k=rsa | No | Tipo di chiave. RSA è il valore predefinito e più comune. Verifica il supporto Ed25519 nei sistemi interessati. |
p= | Sì | Chiave pubblica in base64. Un p= vuoto indica una chiave revocata. |
t=s | No | Limita il dominio dell’identità AUID della firma al dominio firmatario. Non definisce l’allineamento con il From visibile; senza questa restrizione sono permessi sottodomini di quell’identità. |
t=y | No | Modalità di test. I destinatari non devono penalizzare gli errori della firma più di un messaggio non firmato. Rimuovi dopo aver verificato la configurazione. |
Errori comuni nella creazione di record DKIM
Alla prima configurazione, i team incontrano spesso gli stessi errori.
1. Interruzioni di riga nella chiave pubblica. Molto comune. Copiare una chiave PEM con le interruzioni di riga nel campo DNS può invalidarla. Rimuovi interruzioni e spazi dai dati base64.
2. Selettore errato nel nome DNS. Hai generato la chiave con s1, ma il server usa default. Il destinatario cerca default._domainkey.example.com, non trova la chiave e DKIM fallisce. Il selettore DNS deve coincidere esattamente con quello usato per firmare.
3. Più record DKIM con lo stesso selettore. Diversamente da SPF, che richiede una sola policy per dominio, DKIM permette più chiavi con selettori distinti. Pubblicare due TXT separati per s1._domainkey può invalidare la ricerca della chiave; il destinatario non deve doverne scegliere uno.
4. Dimenticare di abilitare la firma. Hai aggiunto il record pensando di aver finito. Il DNS pubblica soltanto la chiave pubblica; il server deve firmare i messaggi con quella privata. Senza firma, il record non autentica nulla.
5. Usare chiavi da 1024 bit. Possono ancora essere accettate, ma le linee guida Google per i mittenti raccomandano 2048 bit quando supportati. Genera una nuova coppia, pubblica la chiave pubblica con un nuovo selettore e aggiorna la firma. Conserva la vecchia chiave durante il transito dei messaggi già inviati, poi revocala lasciando vuoto il suo p=.
DKIM, SPF e DMARC: l’insieme completo
DKIM non funziona isolatamente. È una parte di un sistema di autenticazione a tre componenti.
SPF verifica che l’IP del server mittente sia autorizzato dal dominio valutato. È importante, ma può fallire durante l’inoltro perché l’IP cambia. Se non l’hai configurato, consulta la guida alla configurazione SPF e come funziona SPF per la posta per capire il limite di 10 termini che attivano ricerche e gli altri vincoli.
DKIM può sopravvivere all’inoltro perché firma il contenuto, non l’IP mittente, purché i dati firmati restino integri. Per questo completa SPF.
DMARC collega i meccanismi. Indica al destinatario una policy per i messaggi che non superano DMARC: quarantena, rifiuto o nessuna azione richiesta. Per passare, SPF o DKIM deve convalidarsi e allinearsi al dominio From visibile.
Un obiettivo possibile è SPF valido e allineato, DKIM valido e allineato e, dopo aver controllato tutti i mittenti legittimi, p=reject per DMARC. Questo può contribuire a una buona reputazione del dominio, ma non garantisce un miglior posizionamento nella posta in arrivo.
Per un’azienda, questo insieme è una base importante delle operazioni di posta sicure, non una garanzia di sicurezza completa.
Come TrekMail può aiutarti con DKIM
Per un solo dominio, creare record manualmente è spesso gestibile. Su decine di domini, l’automazione può ridurre il lavoro: ruotare le chiavi, coordinare i selettori tra servizi e individuare errori prima che penalizzino la recapitabilità.
L’approccio TrekMail consiste nel mostrare i record SPF/DKIM/DMARC necessari collegando un dominio e verificarne la configurazione. Generazione e gestione delle chiavi dipendono dal percorso di invio: per SMTP gestito spettano alla piattaforma; con SMTP esterno devi ottenere i valori dal provider firmatario. I controlli possono segnalare problemi, senza garantire di rilevare ogni incidente prima che influisca sulla posta.
- Piano Nano ($0): BYO SMTP (Amazon SES, Mailgun, ecc.). Usa i record DKIM del provider che firma. Presentato senza carta di credito; verifica le condizioni attuali.
- Starter ($3.50/mese): SMTP gestito; verifica le funzioni disponibili di generazione e rotazione DKIM. L’offerta descritta include una prova gratuita di 14 giorni con carta.
- Pro ($10/mese): Più domini di invio con selettori DKIM indipendenti, secondo le funzioni attuali. Prova gratuita di 14 giorni nell’offerta descritta.
- Agency ($23.25/mese): Gestione centralizzata dei domini dei clienti, con un riferimento di 100+ domini. Verifica limiti e funzioni di rotazione e monitoraggio. Prova gratuita di 14 giorni nell’offerta descritta.
Non è soltanto comodità. Un record DKIM errato può passare inosservato fino alla comparsa di errori di autenticazione o consegna. La convalida automatizzata aiuta a individuare problemi, ma non sostituisce i test con messaggi reali.
Conclusione
Per creare correttamente record DKIM servono quattro elementi: una coppia di chiavi da 2048 bit quando supportata, un TXT DNS sotto il selettore corretto, un server che firma attivamente e una verifica del risultato. Un dominio semplice può richiedere circa dieci minuti di lavoro, senza contare attese e diagnosi.
Dopo DKIM, aggiungi SPF e DMARC per rafforzare l’autenticazione del dominio. Operare senza l’insieme completo può limitare i segnali di fiducia e la protezione dalla falsificazione, ma configurarlo non garantisce consegna o sicurezza assolute.
Per ridurre la gestione manuale del DNS, prova TrekMail gratis secondo le condizioni attuali e usa la procedura guidata come supporto alla configurazione.
