Skip to main content
New SPF lookups must resolve in milliseconds — why a DMARC tool's add-on isn't enough Learn Why → →

Cos'è DKIM?

DKIM (DomainKeys Identified Mail) è un protocollo di autenticazione delle email che usa la crittografia a chiave pubblica per verificare che un messaggio email sia stato inviato da un server autorizzato e che il contenuto del messaggio non sia stato alterato durante il transito. Il server mittente firma i messaggi in uscita con una chiave privata e il server ricevente verifica la firma usando una chiave pubblica pubblicata nel DNS del mittente. A differenza di SPF, che verifica solo l'indirizzo IP del server mittente, DKIM verifica l'integrità del messaggio e sopravvive all'inoltro delle email. DKIM è definito nell'RFC 6376.

Questa guida fa parte della nostra guida completa a DKIM. Correlati: il record DKIM e come funzionano le firme DKIM.

DKIM - DomainKeys Identified Mail - è il secondo pilastro della moderna autenticazione delle email. Mentre SPF verifica che un messaggio sia stato inviato da un server autorizzato, DKIM va oltre: firma crittograficamente il messaggio stesso, dimostrando che il contenuto non è stato manomesso e che il dominio mittente dichiarato ha effettivamente autorizzato il messaggio.

RFC 6376 definisce DKIM come un metodo per associare un nome di dominio a un messaggio email, consentendo così a una persona, un ruolo o un’organizzazione di rivendicare una certa responsabilità per il messaggio. La firma sopravvive all’inoltro delle email, il che rappresenta un vantaggio cruciale rispetto a SPF.

Comprendere DKIM è essenziale per chiunque gestisca un’infrastruttura email, perché l’allineamento DKIM è uno dei due percorsi per superare l’autenticazione DMARC - e per la posta inoltrata è spesso l’unico percorso.

Come funziona DKIM: il quadro generale

DKIM opera su un semplice principio crittografico: il server mittente firma il messaggio con una chiave privata e il server ricevente verifica la firma con una chiave pubblica pubblicata nel DNS.

Il processo di firma (in uscita)

  1. Il server di posta mittente genera un hash di intestazioni email specifiche e del corpo del messaggio
  2. Il server cifra questo hash usando la chiave privata DKIM del dominio
  3. Il server aggiunge un’intestazione DKIM-Signature al messaggio contenente l’hash cifrato, il nome del selettore, il dominio firmatario e i metadati su quali intestazioni sono state firmate
  4. Il messaggio viene trasmesso al server ricevente

Il processo di verifica (in entrata)

  1. Il server ricevente estrae l’intestazione DKIM-Signature dal messaggio
  2. Legge i valori d= (dominio) e s= (selettore) dalla firma
  3. Esegue un lookup DNS per <selector>._domainkey.<domain> per recuperare la chiave pubblica
  4. Usa la chiave pubblica per decifrare la firma e recuperare l’hash originale
  5. Calcola in modo indipendente l’hash delle stesse intestazioni e del corpo usando l’algoritmo specificato
  6. Se i due hash corrispondono, la firma è valida - il messaggio è autentico e non modificato

Per una spiegazione tecnica dettagliata di questo processo, vedi Come funziona DKIM: una guida completa all’autenticazione delle email.

Per i dettagli a livello di RFC dell’algoritmo di verifica, vedi Dentro l’RFC 6376: come funziona davvero la verifica DKIM.

L’intestazione DKIM-Signature

Un’intestazione di firma DKIM ha questo aspetto:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
    c=relaxed/relaxed; q=dns/txt; t=1618884473;
    h=from:to:subject:date:message-id;
    bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
    b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk...
TagSignificato
v=1Versione DKIM (sempre 1)
a=rsa-sha256Algoritmo di firma
d=example.comDominio firmatario (usato per l’allineamento DMARC)
s=selector1Selettore - identifica quale chiave pubblica usare
c=relaxed/relaxedMetodo di canonicalizzazione per intestazione/corpo
q=dns/txtMetodo di interrogazione per la chiave pubblica
t=1618884473Timestamp della firma
h=from:to:subject:...Elenco delle intestazioni incluse nella firma
bh=...Hash del corpo
b=...La firma stessa

Chiavi DKIM: pubbliche e private

DKIM usa la crittografia asimmetrica. Il proprietario del dominio genera una coppia di chiavi:

  • Chiave privata - Conservata in modo sicuro sul server di posta mittente. Mai condivisa né pubblicata. Usata per firmare i messaggi in uscita.
  • Chiave pubblica - Pubblicata nel DNS come record TXT all’indirizzo <selector>._domainkey.<domain>. Usata dai server riceventi per verificare le firme.

Formato del record DNS

Un record DNS DKIM ha questo aspetto:

selector1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4..."
TagSignificato
v=DKIM1Versione
k=rsaTipo di chiave (RSA è lo standard; Ed25519 è emergente)
p=...La chiave pubblica, codificata in base64

Puoi cercare la chiave pubblica DKIM di qualsiasi dominio usando lo strumento di lookup DKIM.

Dimensioni delle chiavi

  • RSA a 1024 bit - La dimensione minima consigliata della chiave. Ancora ampiamente usata ma considerata debole per gli standard moderni.
  • RSA a 2048 bit - Lo standard attualmente consigliato. Offre una sicurezza robusta ma produce record DNS più lunghi che possono richiedere la suddivisione del record TXT.
  • Ed25519 - Un algoritmo più recente ed efficiente che produce firme e chiavi più corte. Supportato da un numero crescente di server di posta ma non ancora universale.

Guida dettagliata: Comprendere gli algoritmi crittografici di DKIM: RS256 vs RS512 e tendenze emergenti

Selettori: gestire più chiavi

I selettori DKIM consentono a un dominio di pubblicare più chiavi DKIM contemporaneamente. Ogni chiave è identificata da una stringa selettore, e il tag s= nell’intestazione DKIM-Signature indica al ricevente quale selettore (e quindi quale chiave pubblica) usare per la verifica.

I selettori servono a diversi scopi:

  • Più servizi di invio - Il tuo server di posta principale e ogni servizio di terze parti (SendGrid, Mailchimp, ecc.) possono avere ciascuno la propria coppia di chiavi DKIM con un selettore univoco
  • Rotazione delle chiavi - Durante la rotazione delle chiavi, puoi pubblicare la nuova chiave sotto un nuovo selettore mentre il vecchio selettore rimane attivo durante il periodo di transizione
  • Separazione per reparto - Team o divisioni diverse possono usare selettori diversi a fini di tracciamento e gestione

Le convenzioni comuni di denominazione dei selettori includono s1, s2, google, sendgrid, k1 o nomi basati sulla data come 202604.

Canonicalizzazione: gestire le modifiche ai messaggi

I messaggi email vengono frequentemente modificati durante il transito - vengono aggiunti o rimossi spazi bianchi, le intestazioni vengono riscritte e le interruzioni di riga possono cambiare. La canonicalizzazione definisce come i processi di firma e verifica normalizzano il messaggio prima dell’hashing, così che modifiche minori non compromettano la firma.

Esistono due modalità di canonicalizzazione, applicate in modo indipendente alle intestazioni e al corpo:

  • simple - Quasi nessuna tolleranza alle modifiche. Le intestazioni devono corrispondere esattamente (eccetto per gli spazi bianchi finali). Il corpo è normalizzato solo per le righe vuote finali. Usala quando controlli l’intero percorso di consegna e nessun intermediario modificherà il messaggio.
  • relaxed - Più tollerante. I nomi delle intestazioni sono convertiti in minuscolo, gli spazi bianchi sono normalizzati e gli spazi multipli sono ridotti a uno. Nel corpo, gli spazi bianchi finali vengono rimossi da ogni riga. Usala per la maggior parte delle implementazioni reali.

L’impostazione c=relaxed/relaxed (relaxed sia per intestazioni che per corpo) è la configurazione più comune e consigliata.

Allineamento DKIM

L’allineamento DKIM è un concetto DMARC che determina se il dominio nella firma DKIM (valore d=) corrisponde al dominio nell’intestazione From visibile. Questo è cruciale perché DMARC richiede che almeno uno tra SPF e DKIM sia valido e allineato.

Allineamento relaxed

I domini organizzativi devono corrispondere, ma i sottodomini sono ammessi. Ad esempio:

  • From: user@example.com con d=mail.example.com - Supera l’allineamento relaxed (stesso dominio organizzativo)
  • From: user@example.com con d=example.com - Supera l’allineamento relaxed

Allineamento strict

I domini devono corrispondere esattamente:

  • From: user@example.com con d=example.com - Supera l’allineamento strict
  • From: user@example.com con d=mail.example.com - Fallisce l’allineamento strict

Guida dettagliata: Padroneggiare l’allineamento DKIM: chiavi, firme e perché le email falliscono la verifica

Rotazione delle chiavi DKIM

Le chiavi private DKIM dovrebbero essere ruotate periodicamente per limitare i danni in caso di compromissione di una chiave. Il processo di rotazione prevede:

  1. Generare una nuova coppia di chiavi con un nuovo selettore
  2. Pubblicare la nuova chiave pubblica nel DNS
  3. Configurare il server mittente per firmare con la nuova chiave privata
  4. Attendere la propagazione DNS e verificare le firme con la nuova chiave
  5. Rimuovere la vecchia chiave pubblica dal DNS dopo un periodo di transizione

Con quale frequenza ruotarle? Non esiste uno standard universale, ma le raccomandazioni comuni vanno da ogni 6 mesi a ogni anno. Gli ambienti ad alta sicurezza possono ruotarle più frequentemente.

Guida dettagliata: Quando dovresti ruotare le tue chiavi DKIM?

Perché DKIM fallisce

La verifica DKIM può fallire per diversi motivi:

Modifica del messaggio durante il transito

Se un’intestazione firmata o il corpo del messaggio vengono modificati dopo la firma, l’hash non corrisponderà e la verifica fallirà. I responsabili comuni includono:

  • Mailing list che aggiungono footer o modificano la riga dell’oggetto
  • Gateway email che riscrivono le intestazioni per conformità o scansione di sicurezza
  • Servizi di inoltro che alterano le intestazioni dei messaggi

Problemi DNS

  • Il record della chiave pubblica DKIM non esiste o è irraggiungibile
  • Il selettore nella firma non corrisponde ad alcuna chiave pubblicata
  • Ritardi di propagazione DNS dopo una rotazione delle chiavi

Errori di configurazione

  • La chiave privata non corrisponde alla chiave pubblica pubblicata
  • L’algoritmo di firma specificato nella firma non corrisponde al tipo di chiave
  • Le intestazioni elencate nel tag h= non erano incluse nel calcolo effettivo della firma

Guide dettagliate:

DKIM vs SPF: complementari, non concorrenti

DKIM e SPF servono a scopi diversi e hanno punti di forza diversi:

CaratteristicaSPFDKIM
Cosa verificaIndirizzo IP del server mittenteIntegrità e origine del messaggio
Come funzionaLookup DNS degli IP autorizzatiVerifica della firma crittografica
Sopravvive all’inoltroNo - l’inoltro cambia l’IP mittenteSì - la firma viaggia con il messaggio
Protegge l’integrità del contenutoNoSì - rileva la manomissione
Tipo di record DNSTXT sul dominioTXT all’indirizzo selector._domainkey.domain
Base dell’allineamento DMARCDominio Return-PathDominio d= nella firma

Poiché SPF si rompe durante l’inoltro delle email (l’IP del server di inoltro non è nel record SPF del dominio originale), DKIM è spesso l’unico metodo di autenticazione che supera i controlli per i messaggi inoltrati. Questo rende l’allineamento DKIM essenziale per i domini che usano mailing list, regole di inoltro o qualsiasi infrastruttura di relay.

Guide dettagliate:

DKIM per la posta inoltrata e in relay

Uno dei vantaggi pratici più importanti di DKIM rispetto a SPF è il suo comportamento durante l’inoltro delle email. Quando un messaggio viene inoltrato attraverso un server intermediario (una mailing list, una regola di inoltro automatico o un servizio di relay), SPF si rompe perché l’indirizzo IP del server di inoltro non è elencato nel record SPF del dominio originale. DKIM, al contrario, sopravvive all’inoltro finché il contenuto del messaggio non viene modificato. Se sei alle prime armi con questa configurazione, le FAQ di AutoSPF rispondono alle domande più comuni sulla configurazione.

Ecco perché DKIM è cruciale per la conformità DMARC in ambienti con:

  • Mailing list - Organizzazioni che partecipano a mailing list di settore o gruppi di distribuzione interni
  • Inoltro email - Utenti che inoltrano email da un provider all’altro (ad esempio, inoltrare un indirizzo universitario a Gmail)
  • Hosting condiviso - Ambienti in cui la posta passa attraverso server di relay condivisi
  • Gateway email - Appliance di sicurezza che inoltrano la posta senza modificarne il contenuto

Tuttavia, DKIM si romperà se l’intermediario modifica le porzioni firmate del messaggio. Le modifiche comuni che rompono DKIM includono l’aggiunta di footer, la riscrittura della riga dell’oggetto o la rimozione degli allegati. Software per mailing list come Mailman e LISTSERV spesso aggiungono intestazioni e footer di lista, che possono rompere le firme DKIM basate sul corpo.

La soluzione è configurare DKIM con la canonicalizzazione c=relaxed/relaxed (che tollera piccole modifiche agli spazi bianchi) e assicurarsi che qualsiasi software per mailing list che gestisci sia configurato per preservare le firme DKIM ove possibile.

Schemi comuni di configurazione DKIM

Configurazioni di infrastruttura email diverse richiedono approcci di configurazione DKIM diversi:

Provider singolo

Se tutta la tua posta passa attraverso un unico provider (ad esempio, Google Workspace), quel provider gestisce automaticamente la firma DKIM. Devi solo pubblicare nel tuo DNS la chiave pubblica che ti fornisce.

Più provider con selettori separati

Quando più servizi inviano email per tuo conto, ogni servizio ottiene la propria coppia di chiavi DKIM con un selettore univoco. Ad esempio:

  • google._domainkey.example.com - Chiave DKIM di Google Workspace
  • s1._domainkey.example.com - Chiave DKIM di SendGrid
  • k1._domainkey.example.com - Chiave DKIM di Mailchimp

Ogni servizio firma i messaggi con la propria chiave privata e i destinatari cercano la chiave pubblica corretta in base al selettore nell’intestazione DKIM-Signature.

Firma on-premise

Le organizzazioni che gestiscono i propri server di posta (Exchange, Postfix, Exim) devono generare le proprie coppie di chiavi, installare la chiave privata sul server di posta e pubblicare la chiave pubblica nel DNS. Puoi creare una coppia di chiavi con il nostro generatore DKIM gratuito. Questo ti dà il pieno controllo del processo di firma ma richiede di gestire la generazione, la rotazione e l’archiviazione delle chiavi.

DKIM e TLS: livelli di sicurezza diversi

DKIM e TLS (Transport Layer Security) contribuiscono entrambi alla sicurezza delle email ma operano a livelli diversi:

  • TLS cifra la connessione tra i server di posta durante la trasmissione, impedendo l’intercettazione durante il transito. Non verifica l’identità del mittente né protegge dalla falsificazione.
  • DKIM verifica l’identità del mittente e l’integrità del messaggio ma non cifra il contenuto del messaggio.

Entrambi sono necessari per una sicurezza email completa.

Guida dettagliata: TLS e DKIM: perché ti servono entrambi per una solida sicurezza delle email

Configurare DKIM per la tua piattaforma

La configurazione DKIM varia in base alla piattaforma email. Il processo generale è:

  1. Genera una coppia di chiavi DKIM (di solito lo fa la tua piattaforma email)
  2. Pubblica la chiave pubblica come record DNS TXT nella posizione corretta del selettore
  3. Abilita la firma DKIM sulla piattaforma di invio
  4. Verifica la configurazione con un Lookup DKIM

Per istruzioni specifiche per piattaforma, consulta queste guide:

DKIM nello stack di autenticazione

DKIM è uno dei tre protocolli che collaborano per autenticare le email:

  • SPF - Verifica che il server mittente sia autorizzato
  • DKIM - Verifica l’integrità del messaggio e fornisce una firma a livello di dominio (questa guida)
  • DMARC - Collega SPF e DKIM con requisiti di allineamento, definisce la policy di enforcement e abilita il reporting

DMARC richiede che almeno uno tra SPF e DKIM superi i controlli e sia allineato con il dominio dell’intestazione From. In pratica, configurare sia SPF che DKIM massimizza le tue possibilità di superare DMARC, perché se un metodo fallisce (ad esempio, SPF fallisce a causa dell’inoltro), l’altro può comunque fornire un risultato valido e allineato.

Guide dettagliate:

Strumenti diagnostici

Prossimi passi

  1. Verifica la tua attuale configurazione DKIM - Usa lo strumento di lookup DKIM per controllare se il tuo dominio ha chiavi DKIM valide pubblicate
  2. Controlla l’allineamento - Assicurati che il dominio d= nelle tue firme DKIM corrisponda al dominio della tua intestazione From
  3. Rivedi la robustezza delle chiavi - Conferma di usare chiavi RSA di almeno 2048 bit
  4. Pianifica la rotazione delle chiavi - Stabilisci un calendario di rotazione e documenta il processo
  5. Distribuisci DMARC - Se non l’hai già fatto, configura DMARC per applicare l’allineamento di SPF e DKIM e ricevere report aggregati
  6. Monitora con i report DMARC - Usa i report aggregati DMARC per identificare i fallimenti DKIM su tutti i server riceventi
Rated 5/5 on G2 · Trusted since 2018

Trusted by 50,000+ domains

"AutoSPF Flattens SPF Records Seamlessly & Keeps Changes Logged - I am quite pleased with the product"

It does what it promises to do, and does it very well. I appreciate that it keeps a log of changes made, which prevents many mistakes. A client's SPF record would have way too many lookups, but AutoSPF makes that problem go away. The length of the SPF record is typically not the issue; it's the amount of lookups in the record that are. AutoSPF "flattens" the record, automatically expanding the defined lookups to IP addresses or ranges. And it auto-updates the record when the un-flattened lookups change.
PJ

Peter J.

President · Small-Business (50 or fewer emp.)

"Helped us go beyond capacity"

AutoSPF did exactly as described, it helped us get past our 10 lookup limit. Afterwards, we hit another limit regarding overall capacity and when contacted, they quickly provided us with a new solution to eliminate capacity issues entirely going forward, so now we can add as many SPF records as needed. They also provided us with a personalized support video explaining their new method in its entirety using our instance as the example.
VU

Verified User

Financial Services · Mid-Market (51-1000 emp.)

"Great service and great support"

AutoSPF was easy to initially set up on our own and a great cost effective entry into spf flattening. Needed our first support assistance today and got great response including a video demonstrating the issue I was trying to solve, a quick fix, and more detailed followup.
GF

Greg F.

Mid-Market (51-1000 emp.)