Chiave DKIM: lunghezza consigliata, DNS e rotazione

La tua chiave DKIM è un elemento di autenticazione pubblicato nel DNS il cui stato può influire sulla consegna. Se è debole, malformata o obsoleta, i destinatari possono non convalidare più le firme. Conta soprattutto per i requisiti Gmail introdotti a febbraio 2024 e il rafforzamento annunciato da novembre 2025; consulta le condizioni attuali. Se stai ancora rivedendo le basi DNS, parti da email aziendale e poi torna qui.

In breve: usa una chiave DKIM RSA da 2048 bit quando supportata. Pubblicala correttamente, spesso dividendo il TXT in più stringhe tra virgolette. Pianifica la rotazione con i selettori. In una rotazione ordinaria, conserva il vecchio selettore qualche giorno dopo il cambio per i messaggi in transito. È un processo prudente, non una garanzia di consegna.

Per un nuovo dominio, consulta anche creare email con il proprio dominio e i record DNS richiesti di TrekMail per preparare insieme DKIM, SPF e DMARC.

Che cos’è una chiave DKIM?

Qui indica la parte pubblica della configurazione di firma DKIM. Il server firma i messaggi in uscita con la chiave privata; il destinatario recupera quella pubblica dal DNS per verificare i dati firmati e la responsabilità del dominio firmatario. Non prova da sola l’identità personale né l’affidabilità del From visibile.

DKIM significa DomainKeys Identified Mail. La chiave privata resta nel sistema di invio e quella pubblica viene pubblicata sotto un selettore, solitamente a un nome come s1._domainkey.example.com.

All’arrivo, il server esamina la firma DKIM, cerca la chiave pubblica nel DNS e la convalida. Se passa, ottiene due indicazioni:

• Corpo e intestazioni firmate mantengono l’integrità secondo le regole di canonicalizzazione della firma.
• La firma è stata prodotta con accesso alla chiave privata corrispondente al dominio e selettore.

Non garantisce l’arrivo nella posta in arrivo. Fornisce un segnale crittografico verificabile che i filtri possono considerare.

Quale lunghezza di chiave DKIM scegliere?

Usa RSA da 2048 bit come raccomandazione DKIM per 2025 e 2026. Il minimo normativo consente ancora RSA da 1024 bit, ma il consiglio pratico è 2048 bit: più robustezza con meno problemi di dimensione DNS e compatibilità che possono accompagnare chiavi da 4096 bit.

Il RFC 8301 richiede almeno 1024 bit per RSA e raccomanda almeno 2048 bit. È una raccomandazione tecnica importante per la gestione.

Se erediti una vecchia infrastruttura, non supporre che la chiave sia adeguata. Molti pannelli e sistemi generavano 1024 bit per impostazione predefinita. Anche se un tempo era comune, è una scelta da rivedere.

La documentazione Google mostra l’importanza operativa. Gmail richiede DKIM per i mittenti massivi e la FAQ descrive possibili limitazioni quando l’autenticazione fallisce. Consulta le domande frequenti sulle linee guida Google per i mittenti.

Perché una chiave DKIM da 2048 bit può fallire nel DNS

Una chiave DKIM da 2048 bit può creare problemi perché ogni stringa TXT DNS ha un massimo di 255 ottetti per frammento tra virgolette. La chiave pubblica completa supera questa dimensione. Se il pannello si aspetta un unico valore lungo, può rifiutarlo, troncarlo o salvarlo male.

È una trappola frequente: il problema è spesso l’interfaccia DNS, non la crittografia.

Il valore pubblico di p= per una chiave RSA DKIM da 2048 bit può richiedere più stringhe tra virgolette all’interno di un solo TXT. Le concatena il verificatore DKIM o l’applicazione che usa il record; non presumere che lo faccia automaticamente il resolver DNS. Dati pubblicati male possono causare un errore di verifica.

Errori comuni:

• Il pannello taglia il record a 255 caratteri a byte singolo.
• Aggiunge spazi o interruzioni di riga nella chiave.
• Pubblichi più TXT separati invece di un TXT con più stringhe tra virgolette.
• Rimuovi parte del prefisso v=DKIM1; k=rsa; p= tentando di accorciarlo.

Non ottieni una chiave più debole, ma una chiave potenzialmente non verificabile.

Pubblicare correttamente una chiave DKIM da 2048 bit

Pubblica un solo TXT per selettore e dividi il valore esclusivamente in stringhe interne a quel record. Il verificatore destinatario le concatena. Mantieni valida la sintassi, poi controlla la risposta DNS esatta dalla riga di comando.

Sintassi da file di zona:

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

Molte interfacce web richiedono lo stesso record su una riga:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

Poi verifica dall’esterno. Non fidarti solo dell’anteprima.

dig txt s1._domainkey.example.com +short

Cerca una risposta TXT completa. Due stringhe tra virgolette sono normali se appartengono allo stesso record. Frammenti mancanti, escape inattesi o output parziale richiedono di controllare sia i dati pubblicati sia lo strumento di interrogazione.

Con TrekMail, consulta SMTP gestito da TrekMail e la procedura guidata DNS. Secondo il piano attuale, puoi usare SMTP gestito e ottenere nel pannello il valore del record DKIM del dominio. L’offerta descritta presenta Starter a $3.50 al mese e una prova gratuita di 14 giorni con carta per i piani a pagamento. Nano è presentato come gratuito e usa SMTP esterno, le cui chiavi e selettori devono provenire dal provider firmatario. Verifica le condizioni attuali.

Esempio concettuale: generi una chiave DKIM da 2048 bit, la incolli in un registrar che tronca silenziosamente i TXT lunghi e la posta continua a uscire dal server. Il problema può restare invisibile finché Gmail rileva un’autenticazione non valida. Per questo serve la verifica esterna.

Ruotare una chiave DKIM riducendo le interruzioni

In una rotazione ordinaria, aggiungi un selettore, pubblica la nuova chiave, cambia la firma e conserva temporaneamente il precedente. Evita di sovrascrivere la chiave attiva. Selettori distinti riducono gli errori su messaggi ritardati o ritentati. In caso di possibile fuga, revocare subito può essere più importante del periodo di transizione.

Procedura prudente per una rotazione programmata:

1. Genera una nuova coppia DKIM da 2048 bit.
2. Assegna un nuovo selettore, come s2.
3. Pubblica s2._domainkey.example.com nel DNS.
4. Passa la configurazione di firma a s2.
5. Conserva s1 pubblicato per alcuni giorni secondo code e policy.
6. Rimuovi s1 quando i vecchi messaggi firmati non sono più in transito.

Un esempio di margine è 7 giorni. Può coprire ritardi, tentativi e cache comuni, ma non è universale: adattalo all’ambiente e al motivo della rotazione.

Non sostituire la chiave sotto lo stesso selettore se non controlli tutti i casi di firma e consegna o se il provider non lo richiede. La maggior parte dei team non ha controllo completo. Usa i selettori per distinguere le chiavi.

Con più sistemi di invio, documenta l’attribuzione dei selettori. Conta quando analizzi CRM, supporto, applicazione web e provider di caselle che usano lo stesso dominio.

Quando ruotare una chiave DKIM?

Segui una policy fissa e ruota anche dopo esposizione della chiave privata, cambio di provider o migrazione di invio. Una frequenza semestrale può essere un punto di partenza per alcuni team. Ambienti ad alto rischio possono richiedere altri ritmi; una policy prevedibile è generalmente preferibile all’improvvisazione.

Regola operativa: se la chiave privata può essere trapelata, sostituiscila e valuta la revoca immediata. Senza incidenti, applica comunque la policy di rotazione.

Motivi per anticipare la rotazione:

• Hai cambiato provider di posta in uscita.
• Hai dismesso un fornitore con accesso di firma.
• Hai esportato chiavi con una procedura non sicura.
• Hai trovato un vecchio account amministrativo condiviso di cui nessuno sa spiegare l’uso.

Argomenti che non giustificano un rinvio:

• «Lo faremo quando avremo tempo».
• «La chiave passa ancora, quindi va bene».
• «Non ricordiamo dove sia la chiave privata».

Con molti domini dei clienti diventa gestione operativa, non solo crittografia. Qui assume importanza l’hosting email multidominio. Un dominio può essere manuale; cinquanta richiedono un processo.

Conviene usare Ed25519 per DKIM?

Ed25519 offre chiavi molto più corte e riduce i problemi di lunghezza TXT legati a RSA-2048. Il compromesso è la compatibilità. Il RFC 8463 lo ha standardizzato per DKIM, ma RSA-2048 è generalmente la scelta conservativa per un’ampia interoperabilità.

Il vantaggio principale è la dimensione. La chiave pubblica Ed25519 è piccola rispetto a RSA, quindi pubblicarla è spesso più semplice.

Lo svantaggio è la variabilità del supporto. Alcuni destinatari e strumenti lo gestiscono bene, altri potrebbero non farlo. Anche RSA-2048 richiede verifiche, pur essendo ampiamente usato. Se la piattaforma supporta doppia firma e conosci il percorso, provare Ed25519 insieme a RSA può essere sensato.

Per la maggior parte degli operatori:

• Usa RSA-2048 come impostazione predefinita.
• Considera Ed25519 se conosci la compatibilità dei destinatari e puoi verificarla.
• Non passare a Ed25519 esclusivo solo perché il DNS è più corto.

Vecchio e nuovo approccio: gestire DKIM su larga scala

Il vecchio approccio modifica TXT a mano, incolla chiavi grandi in pannelli diversi e spera che nessuno dimentichi la rotazione. Il nuovo adotta gestione DNS e firma ripetibile e, quando opportuno, delegata: il ciclo di vita delle chiavi fa parte del processo di posta.

Vecchio approccio:

• Ogni dominio ha un’interfaccia DNS diversa.
• Ogni rotazione dipende da un promemoria che può essere ignorato.
• Un refuso in un registrar può danneggiare la posta di un cliente senza essere notato fino ai problemi di consegna.

Nuovo approccio:

• Una procedura comune per molti domini.
• Firma gestita con una configurazione coerente.
• Meno lavoro ripetitivo su TXT lunghi e scostamenti dell’autenticazione.

TrekMail può inserirsi in questo modello di hosting multidominio a tariffa fissa anziché per utente. L’offerta descritta comprende spazio condiviso, caselle IMAP, migrazione IMAP integrata, catch-all, inoltro, BYO SMTP su Nano e SMTP gestito nei piani a pagamento; verifica le funzioni attuali. Se gestisci inoltri, esamina anche l’autenticazione su quei percorsi: inoltrare la posta del dominio a Gmail presenta un caso correlato.

Per team e agenzie, il vantaggio potenziale non è un DNS «magico», ma meno errori ripetitivi con un processo centralizzato. L’offerta descritta Starter parte da $3.50/mese; consulta i prezzi attuali.

Conclusione sulla chiave DKIM

In generale, scegli RSA-2048, pubblica correttamente, verifica con query reali e pianifica la rotazione per selettore. Se usi ancora 1024 bit, prepara un aggiornamento compatibile. Se il pannello altera i TXT lunghi, correggi il formato o scegli un sistema che li gestisca adeguatamente.

Non considerare DKIM isolatamente. Una chiave verificabile è più utile quando anche SPF, DMARC e l’infrastruttura di invio sono ben configurati e allineati. Consulta i record DNS richiesti di TrekMail e creare email con il proprio dominio per rivedere l’insieme.