Record DKIM: selettori, rotazione delle chiavi e diagnosi

Se le aperture calano, non rivedere solo gli oggetti: verifica anche il DNS e il record DKIM. La misurazione delle aperture è incompleta, e un calo non dimostra un problema di autenticazione.

SPF verifica l'autorizzazione dell'IP per un'identità SMTP; DKIM, DomainKeys Identified Mail, permette di validare una firma su dati specifici del messaggio. Non garantisce l'identità umana visibile né che tutto il contenuto sia identico. Dal 2024 Google e Yahoo richiedono DKIM per gli invii di massa compresi nelle rispettive regole. Un errore può contribuire a rifiuti o spam, senza decidere da solo la destinazione.

Per un fondatore, configurare DKIM può sembrare un lavoro di dieci minuti, ma i tempi variano. Per un fornitore con 500 domini significa gestire selettori, rotazioni e sintassi DNS, anche quando un problema si presenta alle 9 di sera di venerdì.

Questa guida operativa spiega il funzionamento DNS del record DKIM, il limite di 255 ottetti per stringa TXT e la diagnosi quando lo stato nel pannello non corrisponde a un invio reale.

Cos'è un record DKIM

Un record DKIM pubblica una chiave pubblica in un TXT DNS, direttamente o tramite una delega supportata dal fornitore. Il ricevente verifica una firma associata al dominio firmatario e l'integrità dei dati coperti secondo la canonicalizzazione. Non prova da solo l'autorizzazione dell'autore visibile né l'assenza di contenuti dannosi.

La ricerca usa selector._domainkey.yourdomain.com, dove selector identifica la chiave. Questo esempio è abbreviato e non può essere pubblicato come chiave valida:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...

v=DKIM1 indica la versione, k=rsa il tipo di chiave e p= contiene la chiave pubblica in base64. Quella privata resta nell'infrastruttura di firma e non deve comparire nel DNS. La guida alla creazione dei record DKIM spiega campi e processo completo.

Cosa firma DKIM e perché conta

DKIM non è soltanto una casella di configurazione. Collega una firma al dominio firmatario e consente di verificare i dati coperti, senza garantire l'identità umana del mittente o proteggere ogni parte del messaggio.

Il server deve firmare From e può selezionare altre intestazioni, normalmente Subject, Date, To e Message-ID, insieme al corpo coperto. Applica canonicalizzazione e un hash, normalmente SHA-256, e firma con la chiave privata. La firma viaggia nell'intestazione DKIM-Signature.

Quando Gmail, Outlook o un altro server riceve il messaggio:

1. Legge DKIM-Signature per ottenere selettore e dominio firmatario.
2. Cerca la chiave pubblica in selector._domainkey.yourdomain.com usando i valori della firma.
3. Verifica crittograficamente la firma con la chiave pubblica, senza decifrare il contenuto del messaggio.
4. Ricalcola gli hash dei dati ricevuti secondo i parametri della firma.
5. Verifica corrispondenza e altre condizioni, ottenendo DKIM pass o un risultato di errore.

Due proprietà della validazione sono l'autenticità della firma rispetto alla chiave del dominio firmatario e l'integrità dei dati coperti nei limiti della canonicalizzazione. Non ogni byte dell'intero messaggio deve rimanere identico. La chiave pubblica corretta permette la verifica. La specifica è nella RFC 6376, utile per esaminare conformità e limiti.

Inoltro: quando DKIM può sopravvivere

Immagina che il direttore di un cliente invii una fattura a un contatto che la inoltra tramite alias a Gmail. Se il mittente originale della busta resta invariato e il nuovo IP non è autorizzato, SPF può fallire. DMARC fallisce solo senza un'altra via valida e allineata, come DKIM. Il trattamento dipende dal ricevente, non da un rifiuto inevitabile.

DKIM può sopravvivere all'inoltro se i dati coperti restano compatibili e chiave e altre condizioni sono valide. Il ricevente finale consulta il DNS del firmatario originale. Modifiche di liste o gateway possono però invalidare la firma.

Abbina DKIM a una configurazione SPF adeguata; la guida SPF per la posta spiega le basi. DMARC richiede SPF riuscito e allineato oppure una firma DKIM valida e allineata, non necessariamente entrambi.

SRS, secondo la configurazione di inoltro TrekMail, riscrive l'identità della busta per consentire SPF sul dominio dell'intermediario; non ripristina l'allineamento SPF con il From originale. Verifica inoltre quali uscite siano firmate da TrekMail o dal tuo SMTP esterno, senza presumere una copertura universale predefinita.

Selettori e gestione di più chiavi DKIM

Il selettore DKIM indica quale chiave pubblica cercare. Un valore errato può causare problemi, ma questa guida non presenta una proporzione misurata di tutte le cause.

SPF ammette una politica applicabile per nome, non un unico TXT di qualsiasi tipo. DKIM consente più selettori, come selector._domainkey.yourdomain.com, secondo le capacità DNS e del servizio. Puoi mantenere dieci selettori attivi se necessario, per esempio uno per fornitore.

Perché usare più selettori

Con Google Workspace e Mailchimp, chiavi distinte per servizio sono generalmente più pratiche e riducono l'estensione di un'esposizione. Condividere la chiave privata aumenta i rischi e non è supportato ovunque. Ogni fornitore usa il proprio selettore:

• Google Workspace: Può usare google in google._domainkey.yourdomain.com; conferma il valore assegnato.
• Mailchimp: Può indicare k1 o k2, per esempio in k1._domainkey.yourdomain.com. Segui le istruzioni attuali.
• TrekMail: Può fornire tm1 in tm1._domainkey.yourdomain.com, con TXT o CNAME secondo la configurazione indicata.

Separare le chiavi permette di revocare k1 in caso di esposizione del servizio marketing senza revocare necessariamente la chiave aziendale. Verifica comunque messaggi in transito, dipendenze ed effetti: i selettori non garantiscono continuità o isolamento assoluto di reputazione. La guida ai selettori spiega sintassi e identificazione dei valori assegnati.

Un errore classico di pubblicazione

Alcuni pannelli aggiungono automaticamente il dominio: vuoi creare google._domainkey.yourdomain.com, ma ottieni google._domainkey.yourdomain.com.yourdomain.com. La ricerca del nome atteso può restituire NXDOMAIN nonostante l'altro record esista. Confronta pannello, DNS e firme reali. La verifica dello stato DNS mostra la diagnosi con una consultazione dig.

Lunghezza delle chiavi e rotazione

La chiave influisce sulla sicurezza DKIM. Una configurazione di cinque anni fa merita una revisione, ma l'età non dimostra da sola debolezza o compromissione. Verifica algoritmo, lunghezza, custodia e requisiti attuali.

Chiavi da 2048 bit

Le chiavi RSA da 1024 bit sono state usate per anni. Google mantiene quel minimo e raccomanda 2048 bit quando possibile; controlla separatamente i requisiti attuali Yahoo. Se una vecchia installazione cPanel o Postfix usava 1024 bit prima del 2019, rivedi la politica e pianifica un aggiornamento, senza dedurre un errore soltanto dalla data.

Una chiave da 512 bit è inadeguata. Con dkim=perm_fail per chiave debole o politica, verifica la causa reale. Genera una chiave da 2048 bit se opportuno, pubblica un nuovo selettore prima di firmare e conserva la vecchia chiave pubblica mentre messaggi in transito devono essere verificati. Consulta le linee guida Google per i mittenti.

Frequenza di rotazione

Una rotazione annuale è una politica operativa possibile, non un obbligo universale DKIM. Se la privata viene esposta da intrusione, gestione errata dei segreti o accessi eccessivi, rispondi secondo l'incidente: qualcuno potrebbe firmare finché la chiave resta accettata. Non aspettare il peggioramento della reputazione del dominio email.

Tratta la privata come un segreto sensibile. Conservarla per cinque anni richiede una politica motivata e rivalutata, senza indicare automaticamente compromissione. Custodia e risposta agli incidenti contano quanto il calendario.

Il limite DNS di 255 ottetti e la sua gestione

Con chiavi da 2048 bit, un valore pubblico da 2048 bit in base64 può essere di circa 400 caratteri secondo la codifica. Ogni stringa TXT ammette 255 ottetti. I pannelli possono dividere, rifiutare o gestire diversamente valori lunghi; il troncamento silenzioso non è universale.

Una chiave lunga può occupare più stringhe fra virgolette in un unico TXT. La RFC 6376 ne prevede la concatenazione senza inserire spazi prima di interpretare la chiave.

Esempio abbreviato di una stringa lunga, non pubblicabile come chiave completa:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3...

Esempio strutturale con due stringhe concatenate; sostituisci il contenuto abbreviato:

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

L'inserimento dipende dal DNS. Alcuni accettano la notazione dei file di zona con parentesi; altri gestiscono le stringhe nel pannello. Non creare TXT indipendenti. Consulta la configurazione DNS presso i fornitori comuni per Cloudflare, Route 53, GoDaddy e altri.

Una delega CNAME supportata da TrekMail può evitare la gestione locale del TXT lungo: pubblichi l'alias breve, sotto 255 caratteri nell'esempio, e il fornitore gestisce la destinazione. Verifica valori esatti, chiavi per dominio e strategia dei selettori. CNAME non può coesistere con TXT allo stesso nome; un alias stabile non garantisce rotazione trasparente.

Verifica della configurazione

Non affidarti solo a «Verificato». Il pannello può mostrare dati di ore o giorni prima. Combina DNS autoritativo, resolver pertinenti e prove di firma; una sola consultazione non conferma tutto il processo.

Passaggio 1: verificare il nome DNS

Su Linux o macOS usa il terminale. Su Windows apri la riga di comando e usa nslookup:

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

Sostituisci selector con quello dell'invio e yourdomain.com con il tuo dominio.

v=DKIM1 può indicare la versione, ma la sua assenza non invalida automaticamente la chiave quando si applica il valore predefinito. NXDOMAIN non è atteso: NXDOMAIN indica che il nome non esiste in quella risposta. Verifica nome, pubblicazione e cache. Attendere 30 minuti è un suggerimento illustrativo, non un tempo garantito di propagazione.

Passaggio 2: validare il contenuto della chiave

Se il nome esiste ma persistono errori, esamina il valore:

dig txt selector._domainkey.yourdomain.com +short

Controlla due aspetti:

• Troncamento: Una stringa base64 sotto 200 caratteri per una chiave RSA attesa da 2048 bit può essere incompleta. La lunghezza è un indizio, non una prova; concatena tutte le stringhe e valida la chiave.
• Caratteri alterati: Esamina la stringa base64, a capo, spazi ed escape secondo formato TXT e interpretazione DKIM. Alcuni spazi ammessi non modificano la chiave; altri errori invalidano la codifica. Confronta il valore interpretato con la pubblica fornita.

Passaggio 3: inviare e leggere le intestazioni

Invia a un Gmail che controlli, apri il menu con tre puntini e «Mostra originale». Cerca Authentication-Results aggiunto dal server ricevente attendibile, non da un mittente arbitrario:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=pass conferma quella verifica. Se attendevi una firma valida e trovi fail, neutral, perm_fail o temperror, indaga il motivo completo; i nomi possono dipendere dall'implementazione e neutral non è sempre un errore. La guida DKIM descrive il processo; la lista di prima configurazione completa le fasi di autenticazione.

Errori DKIM: tre scenari

La chiave corretta può esistere nel DNS senza che la firma passi. Verifica firma concreta, dati ricevuti e intero percorso: «dovrebbe funzionare» non basta.

La guida alla diagnosi DKIM approfondisce risultati e motivi. Questi tre scenari sono esempi pratici, non una classifica misurata delle cause più frequenti.

Scenario 1: hash del corpo non verificato

Un errore dell'hash del corpo può influire sul recapito email. L'hash calcolato non coincide con quello dichiarato, per modifiche incompatibili dei dati coperti o altri problemi di elaborazione. Non prova da solo che la firma delle intestazioni sia crittograficamente valida.

Possibili cause:

• Avvisi di mittente esterno: Un gateway aggiunge «EMAIL ESTERNA - ATTENZIONE» prima della verifica DKIM. Può invalidare il corpo firmato. Esamina l'ordine di verifica e modifica, anche in Microsoft 365 con regole di flusso.
• Note legali: Un gateway aggiunge un piè di pagina di 15 righe dopo la firma, modificando potenzialmente l'hash. Firma la versione finale sotto il tuo controllo dopo aver esaminato la copertura.
• Riscrittura degli URL: Mimecast, Proofpoint o Defender for Office 365 possono trasformare google.com in protect.mimecast.com/s/.... Modifiche incompatibili con canonicalizzazione e copertura possono invalidare l'hash; non ogni cambiamento di byte lo fa.

In uscita, firma dopo le tue ultime modifiche. In ricezione, verifica prima di alterare e conserva risultati attendibili. Firmare alla fine del gateway non impedisce modifiche successive in altri sistemi. Conferma percorsi e ordine applicabili in TrekMail; consulta la diagnosi degli errori di invio.

Scenario 2: mancato allineamento

Puoi trovare questo risultato nelle intestazioni:

dkim=pass (signature was valid)

DKIM passa, ma DMARC può fallire per mancato allineamento DKIM se non esiste un'altra via valida e allineata. La destinazione successiva dipende dal ricevente.

DMARC confronta il dominio d= di una firma valida con Header From. Il modo rigoroso richiede corrispondenza esatta; quello rilassato ammette lo stesso dominio organizzativo. Qualsiasi firma DKIM valida e allineata può fornire questa via.

Esempio illustrativo:

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

La firma è valida per sendgrid.net. La politica DMARC del dominio dell'autore si valuta rispetto a yourcompany.com: sendgrid.net != yourcompany.com. Quella firma non è allineata, ma SPF riuscito e allineato o un'altra firma DKIM allineata può ancora far passare DMARC.

Il fornitore può offrire autenticazione di dominio o firma personalizzata. Configura una chiave DKIM per il tuo dominio secondo le istruzioni, affinché d= usi yourcompany.com anziché sendgrid.net quando opportuno. Supporto e pubblicazione TXT o CNAME variano. Comprendi l'allineamento DMARC prima di modificare flussi di produzione.

Scenario 3: chiavi deboli o non accettate

dkim=perm_fail per politica o chiave debole richiede di esaminare la chiave reale. Chiavi da 512 o 768 bit sono inadeguate ai requisiti attuali pertinenti, ma il motivo non prova da solo quella lunghezza. Un errore permanente di autenticazione non significa che tutto il messaggio sia irrecuperabile o che non esistano altre firme valide.

Pianifica una nuova coppia da 2048 bit con selettore distinto: pubblica, verifica, cambia la firma e conserva la vecchia chiave pubblica finché necessario. In caso di compromissione adatta la revoca all'incidente. Non eliminare prima l'unica chiave attiva. Consulta le indicazioni di generazione locale e la guida ai generatori DKIM.

Generatori di chiavi e precauzioni

DKIM richiede una coppia di chiavi. Se un generatore web mostra quella privata, verifica dove viene creata e chi può accedervi prima di usarla in produzione.

Mostrarla nel browser non dimostra una compromissione per definizione: la generazione può essere locale. Un servizio remoto o codice non attendibile può però conoscerla o esporla. Chi la ottiene può firmare finché resta accettata, non necessariamente per sempre. Preferisci ambiente locale controllato o infrastruttura di un fornitore affidabile.

Confrontare i metodi di generazione

Se amministri il tuo server, puoi generare localmente con OpenSSL dopo aver protetto accesso e permessi:

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

La chiave privata non va trasmessa senza necessità autorizzata e canale sicuro. Il DNS riceve la chiave pubblica nel formato appropriato: cat mostra soltanto il PEM, senza rimuovere intestazioni o convertire automaticamente il valore DNS. Rifiuta richieste di inviare la chiave privata per email a scopo di «verifica».

Fondatori e agenzie possono delegare la generazione a un fornitore affidabile quando il servizio lo offre. Conferma custodia, rotazione, revoca e ambito invece di presumere controlli identici presso tutti.

Gestione manuale e automatizzata

La rotazione rende visibile il lavoro operativo DKIM. Rivedi periodicamente ogni chiave e dipendenza. Questo esempio annuale confronta processi, senza imporre un calendario universale.

Esempio di rotazione manuale annuale per dominio

1. Genera una coppia RSA con nuovo selettore, per esempio s2026.
2. Pubblica la chiave pubblica in s2026._domainkey.yourdomain.com.
3. L'esempio riserva 48 ore: verifica pubblicazione e cache senza presumere un tempo universale.
4. Soltanto dopo la verifica configura l'uscita con la nuova chiave privata.
5. L'esempio conserva entrambe le chiavi pubbliche per 7 giorni; adatta la sovrapposizione a code e messaggi ancora verificabili.
6. Ritira il vecchio selettore quando non è più necessario, secondo la politica di incidente.
7. Distruggi in modo sicuro la chiave privata ritirata quando non va più conservata, comprese le copie pertinenti.

Sono 7 passaggi per dominio: con 50 domini, 350 operazioni prima dei test aggiuntivi. Omettere il passaggio 5 può influire sui messaggi in transito; dimenticare il 6 può mantenere una chiave pubblica inutile. Pubblicare la chiave pubblica non espone di per sé la chiave privata. Il processo può essere automatizzato con controlli.

Per un solo dominio il lavoro manuale può essere sostenibile. Con 50, automazione e registro delle modifiche aiutano a evitare dimenticanze, senza garantire l'assenza di una diagnosi il venerdì.

Il ruolo di TrekMail nella gestione DKIM

TrekMail si rivolge alla gestione multidominio, da un fondatore con cinque progetti a un fornitore con 800 domini clienti. Verifica che l'implementazione disponibile copra percorsi e necessità.

Delega CNAME e rotazione

La procedura può indicare un CNAME aggiungendo un dominio. Questo esempio del testo non è una destinazione da riusare senza validazione:

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

Una delega stabile consente al fornitore di gestire il TXT di destinazione. Sostituire la chiave sotto lo stesso selettore può invalidare firme vecchie o in transito e coinvolge le cache. Verifica rotazione coordinata, sovrapposizione e nuovi selettori quando necessari, senza presumere assenza di interruzioni. Un portafoglio di 80 domini richiede ancora controlli anche con meno modifiche DNS.

L'esempio Pro a $8 al mese per 100 domini stima 700 operazioni manuali evitate all'anno. È un confronto illustrativo, non un prezzo attuale verificato o un risparmio garantito: test e controlli restano necessari.

Procedura guidata DNS

La procedura TrekMail può riunire raccomandazioni MX, SPF, DKIM e DMARC e verifiche disponibili. Ogni resolver può avere una cache: conferma risultati, inventario e invii reali prima di fidarti dello stato. Consulta i record DNS richiesti.

Modello senza prezzo per utente

Il modello descritto addebita la piattaforma entro i limiti dei piani. Il testo cita Starter a $3.50 al mese con 50 domini e 100 utenti per dominio, Pro a $8 al mese con 100 domini e 300 utenti per dominio e Agency a 1,000+ domini. Verifica prezzi, spazio condiviso, firma DKIM e limiti attuali: aggiungere account non garantisce un costo invariato indefinitamente.

La configurazione DNS e DKIM dipende dai percorsi e dalle funzionalità del piano. Conferma disponibilità e responsabilità senza presumere tutta l'autenticazione gestita per impostazione predefinita su ogni trasporto.

Confronto della gestione DKIM

Conclusione

Un record DKIM corretto conta per l'autenticazione nel 2025 e oltre, soprattutto per invii soggetti ai requisiti dei fornitori. La sua assenza non causa sempre un fallimento DMARC, perché SPF valido e allineato può fornire un'altra via, ma limita la verifica delle firme e può influire sul trattamento.

Parti da una chiave RSA da 2048 bit quando opportuna, selettore corretto, TXT concatenato adeguatamente e allineamento con From. Definisci poi rotazione, revoca e politica DMARC con inventario e test, integrati da Google Postmaster Tools quando sono disponibili dati.

Il confronto SPF, DKIM e DMARC spiega relazioni e ordine di preparazione. Se indaghi il recapito, la guida per evitare email nello spam aiuta a dare priorità secondo le evidenze.

Con più domini, documenta e automatizza quando utile: una chiave incompleta o una firma non allineata può influire sui flussi pertinenti. La delega CNAME TrekMail può ridurre il lavoro, non eliminare ogni causa di errore. Consulta i piani e verifica l'opzione gratuita descritta per 10 domini senza carta di credito e le condizioni attuali.