guida · configurazione dkim

Come dovrebbe configurare DKIM in sicurezza un team di prodotto?

Configura DKIM scegliendo un dominio di firma di proprietà dell'organizzazione e un selettore univoco per ogni provider o sistema di firma, generando la coppia di chiavi in un servizio protetto, pubblicando solo la chiave pubblica in selector._domainkey.example.com e configurando il percorso di uscita effettivo in modo che firmi ogni messaggio previsto. Verifica la firma sui byte originali del messaggio da una casella esterna, conferma che il dominio d= sia allineato con il dominio From visibile quando DMARC ne dipende, poi procedi con un rilascio graduale. Documenta proprietà dei selettori, rotazione, revoca e rollback prima di spostare il traffico di produzione.

Mappa ogni percorso di uscita reale prima di generare una chiave

Inizia da un inventario, non da un record DNS. Elenca ogni sistema che può emettere posta usando i domini From visibili dell'organizzazione: worker dell'applicazione, provider transazionali, piattaforme di marketing, strumenti di assistenza, sistemi di identità, software di ticketing, relay e percorsi di emergenza. Per ciascuno, registra proprietario, classi di messaggi, mittente della busta, dominio From visibile, dominio DKIM d= corrente, selettore, componente di firma ed eventuale relay successivo che modifica il messaggio. Una chiave DKIM pubblicata per un provider non serve a un percorso diverso che non usa la sua chiave privata. Allo stesso modo, una dashboard generica del provider che mostra un dominio verificato non dimostra che ogni tenant, regione, flusso, template o fallback sia firmato. Usa campioni controllati da ogni percorso e conserva le intestazioni originali. Decidi quali percorsi sono autorizzati prima di abilitare la firma; DKIM autentica la responsabilità di un dominio per una firma, non il consenso del destinatario né la veridicità del contenuto del messaggio.

Scegli un dominio di firma che supporti l'allineamento DMARC

Il tag DKIM d= identifica il dominio di firma. Scegli un dominio che l'organizzazione controlla e può gestire per tutta la vita del flusso di posta. Quando DMARC si baserà su DKIM, il dominio d= deve essere allineato con il dominio nel campo From RFC 5322 visibile secondo la regola di allineamento relaxed o strict applicabile. Un dominio di firma di proprietà del provider può produrre un risultato DKIM valido ma restare non allineato con il dominio From dell'organizzazione. Decidi se ogni flusso debba essere firmato dal dominio apex o da un sottodominio dedicato, considerando proprietà, separazione della reputazione, DNS delegato e isolamento degli incidenti. Non inventare domini aggiuntivi solo per aggirare un problema di reputazione o di policy. Registra la relazione con il dominio organizzativo e la modalità DMARC prevista. Testa l'allineamento sulle intestazioni finali ricevute; non dedurlo mai solo dal lookup di un selettore, perché il messaggio potrebbe usare un altro valore d=.

Assegna i selettori come identità operative

Un selettore consente a un dominio di pubblicare più chiavi e cambiarle senza sostituire un record globale. Crea una policy deterministica per i selettori che identifichi un provider o firmatario e una generazione di rotazione senza esporre segreti. Ad esempio, product-a-2026q3 può essere più chiaro di default, ma mantieni i nomi entro le convenzioni DNS e i limiti dei tuoi strumenti. Non riutilizzare mai una chiave privata tra provider, ambienti o tenant non correlati solo per ridurre i record DNS. Mantieni un registro con selettore, dominio d=, scopo, servizio di firma, proprietario, data e ora di creazione, algoritmo, fingerprint della chiave pubblica, stato di distribuzione, scadenza della rotazione ed evidenze del ritiro. Controlla il nome esatto del selettore prima della pubblicazione: il lookup è `selector._domainkey.signing-domain`. Un record accidentale sul dominio From visibile, sul dominio return-path o nella zona DNS errata non verificherà la firma prevista. Evita di eliminare un vecchio selettore finché le email ritardate e i nuovi tentativi firmati con esso non sono ormai esauriti.

Genera e proteggi la chiave privata

Genera la coppia di chiavi all'interno di un servizio di gestione delle chiavi o di un sistema di firma strettamente controllato, quando il provider lo supporta. La chiave privata non deve mai finire nel DNS pubblico, nel controllo del codice sorgente, nel codice del browser, nell'output della CI, negli analytics, nei log ordinari, nei ticket, nei documenti, nei prompt o nelle chat condivise. Concedi l'accesso alla firma solo al componente di posta che ha bisogno della chiave, separa la produzione dagli ambienti inferiori e registra gli accessi amministrativi. L'RFC 8301 aggiorna i requisiti crittografici di DKIM e stabilisce che i firmatari devono usare chiavi RSA di almeno 1024 bit e dovrebbero usarne di almeno 2048 bit; segnala anche i vincoli operativi del DNS legati alle chiavi più lunghe. Usa le capacità e le raccomandazioni attuali del firmatario scelto e dei riceventi, invece di copiare un esempio obsoleto. Se valuti Ed25519, l'RFC 8463 ne definisce l'uso con DKIM, ma l'interoperabilità va testata e, dove necessario, va mantenuta una strategia di firma compatibile. La rotazione deve essere possibile senza esportare la chiave privata.

Pubblica la chiave pubblica con precisione

Pubblica un record TXT nel nome proprietario esatto `selector._domainkey.signing-domain`. Il record della chiave DKIM contiene tag come v=DKIM1, un tipo di chiave quando necessario e p= contenente il materiale della chiave pubblica senza wrapper della chiave privata. Segui il formato di record esatto del firmatario e il comportamento delle virgolette del tuo provider DNS. Prima di salvare, controlla se l'interfaccia DNS aggiunge automaticamente la zona, divide stringhe lunghe o esegue l'escape dei caratteri. Interroga direttamente i name server autorevoli dopo la pubblicazione, quindi interroga resolver ricorsivi indipendenti e ricostruisci l'intero valore TXT. Più stringhe di caratteri in un record TXT vengono concatenate dai client DNS, mentre più record di risorsa in conflitto possono creare ambiguità. Conserva la risposta precedente e il TTL per il rollback. Non ridurre la sicurezza pubblicando una chiave più ampia o lasciando un flag di test in produzione solo per tacitare un checker. Un record visibile dimostra la pubblicazione DNS, non che il mittente usi la chiave privata corrispondente.

Configura il firmatario finale e i campi firmati

Configura il componente che consegna il messaggio finale al trasporto in uscita, oppure assicurati che nessun componente successivo modifichi il contenuto firmato. Una firma DKIM copre un body hash e i campi di intestazione elencati in h=. L'RFC 6376 richiede che il campo di intestazione From sia firmato perché la firma sia valida. Includi le intestazioni critiche per l'identità adatte al prodotto, capisci come vengono selezionate le intestazioni ripetute ed evita di firmare campi che un sistema a valle necessario deve riscrivere, a meno che quella trasformazione non sia controllata. Scegli la canonicalizzazione con consapevolezza. La canonicalizzazione relaxed tollera determinate modifiche agli spazi e alla formattazione delle intestazioni, ma non consente modifiche arbitrarie al body. La canonicalizzazione simple è più fragile. Inserimento di footer, riscrittura dei link, modifiche ai boundary MIME, conversione del transfer-encoding, tag nell'oggetto e normalizzazione dei fine riga dopo la firma possono invalidare la verifica. Firma il messaggio completamente renderizzato dopo le trasformazioni approvate e impedisci agli utenti non attendibili di scegliere d=, s=, elenchi di intestazioni o chiavi.

Verifica end-to-end i messaggi originali ricevuti

Invia messaggi controllati attraverso ogni percorso reale con configurazione di produzione verso caselle di test esterne gestite dal team. Conserva il messaggio originale raw, non un body copiato o un allegato di ticket riserializzato. Esamina i valori d= e s= della DKIM-Signature, l'elenco delle intestazioni firmate, il body hash, l'algoritmo, la canonicalizzazione, il timestamp e l'eventuale scadenza. Interroga la chiave pubblica da una rete indipendente ed esegui un verificatore conforme agli standard sui byte originali. Confronta l'intestazione Authentication-Results del ricevente attendibile con il tuo verificatore, rispettando i perimetri di fiducia dell'RFC 8601. Testa testo semplice, multipart alternative, allegati previsti, oggetti Unicode, intestazioni lunghe, template, trasformazioni di tracking, nuovi tentativi e percorsi tramite relay. I test negativi dovrebbero includere un'intestazione firmata modificata di proposito in una fixture, un selettore mancante, un selettore scaduto o ritirato e un percorso che salta la firma. Non manomettere mai la posta reale dei clienti per creare un test.

Valuta DKIM, DMARC e consegna come risultati separati

Un esito DKIM positivo indica che il verificatore ha trovato una firma valida per il dominio di firma identificato sui campi firmati e sul body. Non autentica ogni intestazione non firmata, non conferma un autore umano, non dimostra il consenso del destinatario, non stabilisce la conformità legale né garantisce accettazione e arrivo in inbox. DMARC valuta separatamente se un dominio DKIM o SPF con esito positivo è allineato con il dominio From visibile e applica la policy del proprietario del dominio. Per i test controllati, registra almeno l'esito DKIM e il motivo, il dominio d=, il selettore, il dominio From visibile, il risultato dell'allineamento, il risultato SPF, il risultato DMARC, il server ricevente e il timestamp. Tieni gli indirizzi completi dei destinatari e il contenuto fuori dalle metriche di routine. L'accettazione SMTP del provider, l'accettazione del server destinatario, il bounce successivo, il posizionamento nella cartella della casella e l'engagement sono stati successivi. Se DKIM ha esito positivo ma la posta viene rifiutata o filtrata, esamina l'allineamento DMARC, SPF, reputazione dell'IP e del dominio, tasso di segnalazioni di spam, policy dei messaggi, frequenza e indicazioni del server ricevente anziché ruotare ripetutamente le chiavi.

Ruota le chiavi senza creare un vuoto di verifica

Usa selettori sovrapposti. Prima genera una nuova chiave protetta e pubblica il suo record pubblico con un nuovo selettore. Verifica il DNS autorevole e ricorsivo, configura il firmatario per usare il nuovo selettore e invia test controllati attraverso ogni percorso. Monitora la proporzione di firme che usano il vecchio e il nuovo selettore e i relativi esiti di verifica. Mantieni disponibile la vecchia chiave pubblica per l'età massima dei messaggi in coda, la finestra dei nuovi tentativi e il periodo di cache DNS, più un margine di sicurezza esplicito. Poi interrompi ogni firma con il vecchio selettore, conferma che nessuna configurazione attiva vi faccia riferimento e ritira il suo record secondo la policy. Una revoca d'emergenza dopo l'esposizione della chiave privata può richiedere una rimozione più rapida, la sospensione del traffico, la rotazione delle credenziali del provider e una comunicazione dell'incidente; documenta questo compromesso in anticipo. Non sovrascrivere un selettore sul posto durante una rotazione di routine, perché le vecchie chiavi pubbliche in cache possono far fallire la verifica dei messaggi firmati con la nuova chiave privata.

Diagnostica gli errori partendo dalla firma

Se manca la firma, individua se il messaggio ha usato un flusso non firmato, un dominio From non autorizzato, un relay di fallback o un percorso di template. Se la chiave non viene trovata, controlla il lookup esatto di s= e d=, la delega della zona, la risposta autorevole, gli errori DNSSEC o del resolver e la propagazione. In caso di mancata corrispondenza del body hash, confronta il MIME raw prima della firma con quello ricevuto per trovare le trasformazioni successive alla firma. In caso di mancata corrispondenza della firma, verifica che la chiave pubblica pubblicata corrisponda alla chiave privata attiva ed esamina canonicalizzazione e intestazioni firmate. Con un pass DKIM e un fail DMARC, valuta l'allineamento con il dominio From visibile. Classifica gli errori temporanei di lookup DNS separatamente dai problemi di configurazione persistenti e usa nuovi tentativi di trasporto limitati solo quando la risposta SMTP è transitoria. Sospendi il flusso interessato in caso di firma tra domini diversi, chiavi sconosciute, errori di verifica diffusi o sospetta esposizione di una chiave. Conserva prove ridotte al minimo per la privacy e cambia una sola variabile per ogni nuovo test controllato.

Usa la documentazione DKIM del tuo sistema di invio

Configura DKIM nei sistemi di invio effettivi e nell'autorità DNS, convalida i messaggi originali ricevuti e affidati agli standard IETF correnti e alla documentazione specifica del provider.

Domande frequenti

Dove si pubblica una chiave pubblica DKIM?

Pubblicala come record TXT in selector._domainkey.signing-domain, usando esattamente il selettore e il dominio d= che conterrà la firma in uscita.

La chiave privata DKIM va inserita nel DNS?

No. Il DNS contiene solo il materiale della chiave pubblica. Conserva la chiave privata all'interno di un firmatario gestito o di un perimetro per i segreti, con accesso strettamente limitato e controlli di rotazione.

Si può riutilizzare un solo selettore DKIM per tutti i provider email?

Evita questo approccio. Separa selettori e chiavi private per provider, firmatario, ambiente o perimetro di rischio, così che rotazioni e compromissioni non coinvolgano percorsi non correlati.

Un pass DKIM significa che DMARC passa?

Non necessariamente. DMARC richiede che il dominio d= DKIM valido sia allineato con il dominio From visibile, a meno che non sia un pass SPF allineato a soddisfare DMARC.

Perché DKIM fallisce dopo l'aggiunta di un footer o la riscrittura del tracking?

DKIM copre le intestazioni selezionate e un body hash. Una modifica a valle non consentita dalle regole di canonicalizzazione scelte può invalidare la firma dopo la sua creazione.

Come vanno ruotate le chiavi DKIM?

Prima pubblica e verifica un nuovo selettore, poi passa la firma controllata al nuovo selettore, monitora i risultati, conserva la vecchia chiave pubblica per le finestre dei nuovi tentativi e della cache, quindi ritirala.

DKIM determina l'arrivo in inbox?

No. DKIM fornisce una prova circoscritta della firma del dominio. I riceventi valutano comunque in modo indipendente DMARC, SPF, reputazione, segnalazioni di spam, contenuto, velocità di invio e policy della casella prima di decidere l'esito della consegna.

Un record DNS pubblico dimostra che la firma DKIM è attiva?

No. Convalida i messaggi originali ricevuti rispetto alla chiave pubblicata e conferma i valori d= e s= nell'intestazione DKIM-Signature.

Fonti

Continua ad approfondire

Come verificare DKIM per le email applicativeVerifica DKIM esaminando una firma reale, interrogando selettore e dominio, verificando il messaggio, leggendo i risultati del ricevente e testando l'allineamento.Come eseguire una verifica DMARC per le email applicativeVerifica individuazione del record DMARC, sintassi, allineamento SPF e DKIM, policy, report e messaggi applicativi reali, senza confondere un lookup DNS con la consegna.Come verificare un record SPF per le email applicativeVerifica il dominio SPF corretto, la sintassi, i meccanismi, il budget di lookup DNS annidati, l'autorizzazione dell'IP di origine, il risultato e l'allineamento DMARC per le email applicative.Come valutare un servizio di deliverability emailValuta i servizi di deliverability email in base ad ambito, prove, autenticazione, feedback loop, soppressioni, privacy, portabilità e adeguatezza operativa.Protocollo SMTP: come viaggiano le email applicativeScopri come submission SMTP, relay, buste, codici di risposta, TLS, nuovi tentativi e contenuto del messaggio definiscono un flusso di email applicative.