Una configurazione DKIM corretta è essenziale per autenticare la posta di un dominio personalizzato e favorirne la consegna. Una chiave assente, danneggiata o troncata, o una firma con il dominio errato, può penalizzare l’arrivo nella posta in arrivo. Questa guida presenta il flusso operativo: generare la chiave, pubblicare il record DNS, verificarlo dalla riga di comando e individuare gli errori di allineamento che possono ancora far fallire DMARC dopo un controllo positivo nel pannello.
Per una configurazione completa con MX, SPF, caselle e client di posta, parti da creare email con il proprio dominio. Se devi prima scegliere la piattaforma, email aziendale illustra la decisione generale.
Il problema è semplice. La maggior parte degli errori DKIM non nasce dalla crittografia, ma da record DNS copiati male, pannelli che aggiungono due volte il dominio, chiavi da 2048 bit danneggiate o provider di invio che firmano con il proprio dominio anziché il tuo. Puoi perdere ore seguendo la pista sbagliata. La soluzione è una procedura ripetibile.
Che cosa fa realmente DKIM
Configurare DKIM pubblica una chiave pubblica nel DNS e consente al server di firmare ogni messaggio con la chiave privata corrispondente. I destinatari verificano la firma, accertano la responsabilità del dominio firmatario e rilevano modifiche alle intestazioni firmate o al corpo durante il trasporto.
DKIM usa crittografia asimmetrica. Il sistema di invio conserva la chiave privata; il DNS pubblica quella pubblica. Quando il messaggio lascia il server, riceve un’intestazione DKIM-Signature con un dominio firmatario (d=) e un selettore (s=). Il destinatario cerca quel selettore nel DNS e convalida la firma rispetto al contenuto. Il meccanismo è definito nel RFC 6376.
Da febbraio 2024, Google ha rafforzato i requisiti per i mittenti massivi. Indica che devono configurare SPF e DKIM, e che almeno uno deve allinearsi al dominio nell’intestazione From visibile per superare l’allineamento DMARC. Leggi il testo attuale nelle domande frequenti sulle linee guida Google per i mittenti.
È importante perché una firma tecnicamente valida non sempre raggiunge l’obiettivo. Una configurazione DKIM errata o non allineata può lasciare problemi di spam, errori DMARC o entrambi.
Prima di modificare il DNS
Una buona configurazione comincia identificando chi firma davvero la posta. Sembra ovvio, ma è qui che migrazioni, modifiche all’inoltro o cambi di provider possono interrompere gli invii. Il posto giusto per generare o ottenere record DKIM dipende interamente dal percorso di invio.
Prima domanda: chi invia la posta in uscita per questo dominio?
- Se la invia Google Workspace, genera la chiave DKIM in Google Admin.
- Se la invia Microsoft 365, abilita DKIM in quel servizio.
- Se la inviano SendGrid, Mailgun o Amazon SES, autentica il dominio presso quel provider.
- Se la invia TrekMail Managed SMTP, usa i valori DKIM mostrati in TrekMail.
- Se TrekMail gestisce le caselle ma usi SMTP esterno, segui le istruzioni di firma del provider SMTP, poi configura SMTP in TrekMail se necessario.
TrekMail prevede entrambi i percorsi secondo il piano. Nano usa BYO SMTP; i piani a pagamento possono usare SMTP gestito. La documentazione Bring Your Own SMTP presenta esempi SES, SendGrid e Mailgun. La documentazione di diagnostica precisa anche che Managed SMTP firma con la chiave DKIM del tuo dominio, cosa che può aiutare DMARC durante inoltri e relay se la firma rimane valida e allineata.
Esempio: la casella è in TrekMail, ma la posta in uscita passa da SendGrid. Deve firmare SendGrid. TrekMail può ospitare la casella, ma non configura automaticamente DKIM su SendGrid al posto tuo.
Prima regola: genera le chiavi nel sistema che firma il messaggio. Altrove, il record potrebbe esistere nel DNS senza produrre alcun effetto.
Tipi di record DKIM: TXT o CNAME
La configurazione solitamente pubblica un TXT contenente la chiave pubblica. Alcuni provider chiedono invece uno o più CNAME che puntano a chiavi ospitate da loro. Entrambi i metodi funzionano. L’importante è usare esattamente i valori forniti dal sistema di invio.
La configurazione classica usa un TXT in:
selector._domainkey.example.comIl valore ha questo aspetto:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...I servizi gestiti usano spesso CNAME per ruotare le chiavi senza richiedere un’altra modifica DNS. TXT dà controllo diretto, ma comporta anche la responsabilità di aggiornare il record quando la chiave viene ruotata.
| Metodo | Che cosa pubblicare | Adatto a | Rischio principale |
|---|---|---|---|
| TXT | Chiave pubblica completa nel DNS | Google Workspace e molte configurazioni autogestite o dirette | Chiavi lunghe troncate o copiate male |
| CNAME | Alias verso un record DKIM ospitato dal provider | Piattaforme gestite e rotazione delle chiavi più semplice | Destinazione errata o record mancante tra quelli richiesti |
La trappola è il campo host. Se il dominio è example.com e il selettore è k1, normalmente si inserisce:
k1._domainkeyNon questo:
k1._domainkey.example.comMolti pannelli DNS aggiungono automaticamente il dominio principale. Inserendo il nome completo in uno di questi, pubblichi k1._domainkey.example.com.example.com. Il record non si trova dove i destinatari se lo aspettano.
Per un riferimento alla base DNS richiesta da TrekMail, consulta record DNS richiesti. La documentazione spiega anche che alcuni provider richiedono valori TXT DKIM divisi in parti tra virgolette.
Configurare DKIM nel DNS passo passo
Il procedimento è breve: ottenere il selettore, pubblicare il record, attendere l’aggiornamento DNS, verificare la risposta esatta e abilitare la firma se il provider richiede un ultimo passaggio. Senza verifica, stai solo supponendo che funzioni.
Segui questa procedura.
- Apri il provider di invio e genera o visualizza il record DKIM.
- Copia esattamente il selettore. Non rinominarlo se il provider non lo consente.
- Crea il record DNS in
selector._domainkey. - Incolla il TXT completo o la destinazione CNAME esattamente come forniti.
- Imposta il TTL su 3600, salvo motivi diversi.
- Attendi la propagazione.
- Verifica con
digonslookupprima di inviare posta in produzione. - Abilita la firma nel provider se è presente un pulsante finale di attivazione.
Esempio con TXT:
; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."Esempio con CNAME:
; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.La propagazione DNS può essere rapida, ma non è immediata. La guida TrekMail indica che molti aggiornamenti compaiono in circa 5 a 15 minuti, ma i tempi variano secondo TTL e cache. Se lo stato non cambia, verifica formattazione, duplicati e nome host, senza escludere una cache ancora valida.
DKIM e il problema delle chiavi da 2048 bit
Una configurazione moderna dovrebbe usare chiavi RSA da 2048 bit quando provider e hosting DNS le supportano. Sono più robuste, ma anche più lunghe e possono creare problemi nei pannelli datati. Una chiave troncata è ingannevole: sembra presente mentre la verifica fallisce.
Google raccomanda chiavi da 2048 bit quando supportate, con 1024 bit come alternativa per host che non gestiscono record più lunghi. Il problema pratico è spesso il pannello amministrativo, non il DNS stesso.
Una configurazione DKIM da 2048 bit difettosa presenta solitamente uno di questi casi:
- Il pannello tronca il valore senza avvisare.
- Richiede frammenti tra virgolette senza spiegarlo.
- Inserisce interruzioni di riga nella chiave base64.
- Esegue l’escape dei caratteri in modo inatteso dal provider.
Se l’host DNS richiede stringhe separate, pubblica così:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"Il destinatario concatena le parti tra virgolette. È normale. Aggiungere spazi nella chiave non lo è: un carattere in più può invalidare la configurazione.
Gestendo molti domini, il costo operativo emerge qui. Un registrar gestisce bene i TXT lunghi; un altro no; un terzo li riscrive. Per questo le agenzie spesso riducono il numero di registrar o usano firme CNAME ospitate dal provider, quando possibile. Per più clienti, hosting email multidominio presenta il modello operativo complessivo.
Verificare che DKIM funzioni davvero
Un pannello che mostra «attivo» non basta. La verifica reale interroga direttamente il DNS pubblico, controlla il record restituito e conferma nelle intestazioni di messaggi reali il dominio firmatario e il selettore attesi. Il resto è un controllo parziale.
Inizia dalla riga di comando.
# macOS / Linux
dig txt k1._domainkey.example.com +short
# Windows
nslookup -type=txt k1._domainkey.example.comDevi vedere il record v=DKIM1 completo oppure i frammenti tra virgolette che formano l’intera chiave. Se il risultato è vuoto, verifica nell’ordine:
- Il selettore è corretto.
- Il dominio non è duplicato nel campo host.
- Il tipo di record coincide con quello richiesto.
- Il valore è completo e non troncato.
- Il vecchio record non è ancora in cache.
Poi invia un test a Gmail o a un’altra casella che consenta di esaminare le intestazioni. Cerca i risultati di autenticazione e la riga della firma DKIM.
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...Se il DNS sembra corretto ma la posta continua a finire nello spam, controlla gli altri fattori. La guida TrekMail sulle email nello spam evidenzia DNS, riscaldamento del dominio, qualità della lista e contenuti. DKIM risolve parte dell’autenticazione, ma non crea reputazione da solo.
Considera anche l’inoltro. SPF spesso fallisce quando i messaggi vengono inoltrati. DKIM può mantenere valido DMARC in molti di questi flussi se la firma rimane integra e allineata. Se usi l’inoltro, leggi inoltro email per non confondere un errore SPF dovuto all’inoltro con un errore completo di autenticazione.
La trappola dell’allineamento DKIM
L’allineamento è dove molte configurazioni «funzionanti» non raggiungono l’obiettivo. La firma può essere valida senza contribuire al superamento di DMARC se il dominio firmatario non si allinea al From visibile. Solo in parte dei casi è un problema DNS; di solito è un’impostazione del provider.
Errore comune:
From: ceo@example.com
Firmatario DKIM:d=sendgrid.net
Risultato: DKIM può passare, ma l’allineamento DMARC può fallire perché il dominio firmatario non si allinea aexample.com.
Google indica che, per i mittenti massivi, il dominio From visibile deve allinearsi con SPF o DKIM a livello di dominio organizzativo. Se il provider firma con il proprio dominio, la firma può essere valida senza fornire l’allineamento DKIM necessario.
La correzione può chiamarsi autenticazione del dominio, white-labeling o configurazione di return-path personalizzato, secondo il provider. Per DKIM occorre allineare il dominio della firma; cambiare soltanto il return-path riguarda SPF. La firma finale dovrebbe apparire così:
DKIM-Signature: ... d=example.com; s=s1; ...Questa configurazione può contribuire a DMARC e all’arrivo nella posta in arrivo. Una firma non allineata non completa questa parte del lavoro.
Vecchio e nuovo approccio a DKIM
Il vecchio approccio è manuale e fragile: ogni dominio, provider, selettore e particolarità DNS viene gestito separatamente. Il nuovo standardizza: scegliere un modello di invio ripetibile, centralizzare i controlli DNS e non ricostruire la stessa correzione per ogni dominio.
| Vecchio approccio | Nuovo approccio |
|---|---|
| Generare chiavi in strumenti diversi sperando che corrispondano al mittente | Generare DKIM nel sistema di invio reale |
| Incollare TXT uno per uno e aspettare le segnalazioni | Usare firme gestite quando possibile e verificare con la CLI |
| Trattare ogni dominio come un caso unico | Usare una procedura comune per domini di clienti e team |
| Analizzare lo spam dopo il fallimento della campagna | Controllare DNS, allineamento e intestazioni prima del primo invio in produzione |
TrekMail può inserirsi in questo modello. Secondo il piano attuale, consente di gestire più domini personalizzati da un pannello, usare spazio condiviso senza costi per casella, migrare caselle via IMAP e scegliere BYO SMTP o SMTP incluso. I piani a pagamento descritti partono da $3.50/mese; verifica i prezzi attuali. La piattaforma si rivolge a team, PMI, agenzie e MSP che vogliono ridurre la gestione quotidiana dell’infrastruttura di posta.
Se il problema maggiore riguarda il processo anziché il DNS, leggi gestione delle email dei clienti. In ambienti multidominio, responsabilità poco chiare possono causare problemi di recapitabilità, oltre agli errori nei record.
Lista finale per configurare DKIM
Una configurazione solida usa il sistema firmatario corretto, il nome DNS giusto, la chiave completa, la verifica del DNS pubblico e una firma allineata per DMARC. Un errore in uno di questi elementi indebolisce l’insieme.
- Conferma quale sistema firma la posta in uscita.
- Pubblica esattamente il selettore e il tipo di record del provider.
- Usa
selector._domainkeynel campo host, salvo richiesta esplicita del nome completo. - Mantieni integre le chiavi da 2048 bit. Dividi le stringhe tra virgolette solo se il pannello lo richiede.
- Verifica con
digonslookup. - Invia un test e cerca
dkim=passe unheader.dallineato nelle intestazioni. - Controlla i risultati DMARC dopo la messa in produzione.
È tutto. Una buona configurazione DKIM non è complicata, ma precisa. Per ridurre le dipendenze, standardizza domini e percorso di invio in TrekMail quando è adatto alle tue esigenze, mantieni una vista centralizzata del DNS ed evita di ripetere attività manuali costose.
