La verifica della firma DKIM dal terminale non si fa “guardando se l’email è arrivata”. Si controllano due punti distinti: la presenza del record DNS del selettore e la corrispondenza tra firma presente negli header e chiave pubblica pubblicata nel dominio. Se uno dei due manca, DKIM fallisce anche se il messaggio sembra normale nel client.
Il flusso corretto è semplice: estrai gli header completi di una mail firmata, individui il selettore DKIM, recuperi il record TXT dal DNS, poi verifichi la firma con uno strumento locale. Se il tuo obiettivo è diagnosticare un problema reale, questo ordine evita di perdere tempo su ipotesi generiche e ti porta subito al punto debole.
Prima distinzione: DNS, firma e risultato di verifica
DKIM non è un controllo unico. Ci sono almeno tre oggetti da osservare:
- il record DNS pubblicato dal dominio mittente;
- gli header
DKIM-Signaturepresenti nel messaggio; - l’esito del verifier, che può essere
pass,failopermerror.
Il record DNS contiene la chiave pubblica, non la privata. La firma invece è generata dal server di posta del mittente con la chiave privata. Se stai verificando una tua configurazione, il terminale ti serve per confermare che il selettore pubblicato e la firma inserita nel messaggio appartengano allo stesso dominio e alla stessa chiave.
Quando il controllo fallisce, il problema può stare in più punti: record mancante, selettore sbagliato, firma tronca da un gateway intermedio, canonicalizzazione incompatibile, body alterato da un filtro antispam o chiave ruotata senza aggiornare il DNS. Per questo conviene separare la parte DNS dalla parte di verifica del messaggio.
Recuperare gli header completi della mail
Per una verifica seria serve il messaggio completo, non solo il testo. Devi avere gli header originali, idealmente in formato raw. Se usi un client di posta, cerca l’opzione per mostrare il sorgente del messaggio o “header completi”. Se stai lavorando su un file salvato, deve contenere la sezione iniziale con le righe DKIM-Signature, From, Subject, Date e gli altri campi.
Un esempio di estrazione da un file raw può essere questo:
grep -n '^DKIM-Signature:' -n message.emlSe il comando non restituisce nulla, la mail non è firmata con DKIM oppure gli header sono stati già alterati. In quel caso non hai abbastanza dati per una verifica locale e devi prima ottenere il sorgente completo del messaggio. Se il messaggio è stato inoltrato da più hop, attenzione: alcuni sistemi riscrivono gli header e possono rendere la prova non affidabile.
Leggere i campi DKIM-Signature che contano davvero
Dentro l’header DKIM-Signature ci sono alcuni tag fondamentali:
d=: dominio che firma;s=: selettore;bh=: hash del body;b=: firma vera e propria;h=: lista degli header coperti dalla firma;c=: canonicalizzazione usata.
Se vuoi capire rapidamente dove cercare nel DNS, i valori d e s sono quelli decisivi. Per esempio, con d=example.com e s=mail2024, il record da interrogare sarà tipicamente mail2024._domainkey.example.com.
Un errore classico è controllare il dominio del mittente visibile al destinatario e non quello realmente firmato. In ambienti con relay o piattaforme esterne, il dominio firmante può essere diverso dal dominio del messaggio “From”. Per questo i campi da leggere sono quelli del blocco DKIM, non solo l’intestazione visibile nel client.
Verificare il record DKIM dal terminale
Il primo controllo è DNS. Devi interrogare il selettore pubblicato e vedere se il TXT contiene una chiave coerente. Con dig:
dig +short TXT mail2024._domainkey.example.comAtteso: una o più stringhe TXT che includano un valore del tipo v=DKIM1 e p= con la chiave pubblica. Se il risultato è vuoto, il record non è visibile dal resolver che stai usando, oppure il selettore è sbagliato, oppure c’è un problema di propagazione DNS.
Per avere un controllo più preciso, conviene interrogare direttamente un nameserver autoritativo o usare +trace:
dig +trace mail2024._domainkey.example.com TXTSe il record esiste ma il valore è spezzato male, mancano virgolette o la chiave è stata copiata in modo incompleto, il verifier fallirà anche se il dominio risponde. In caso di dubbio, controlla il record nel pannello DNS e confrontalo con il valore atteso dal tuo MTA o dal provider che firma.
Un controllo utile è anche verificare il TTL e i nameserver delegati:
dig +short NS example.com
dig +nocmd mail2024._domainkey.example.com TXT +noall +answerSe gestisci più ambienti, questo passaggio evita di leggere il record nel posto sbagliato. Non è raro trovare chiavi aggiornate in un pannello ma non ancora propagate sul DNS pubblico.
Verificare davvero la firma con opendkim-testmsg
Se vuoi una verifica locale della firma sul messaggio raw, lo strumento più pratico su Linux è spesso opendkim-testmsg. Legge il messaggio completo e controlla la firma contro il DNS. Su molte distribuzioni fa parte del pacchetto opendkim-tools.
# Debian/Ubuntu
sudo apt update
sudo apt install opendkim-tools
# RHEL/CentOS/Alma/Rocky
sudo dnf install opendkim-toolsUna volta installato, puoi lanciare la verifica su un file raw:
opendkim-testmsg < message.emlOutput atteso in caso positivo: una riga con DKIM-Signature field verified o equivalente. Se fallisce, il tool di solito indica se il problema è DNS, body hash, signature invalid o permerror. Quelle etichette sono già una guida di troubleshooting: non limitarti a leggere “fail”, leggi il motivo.
Se il comando non trova il record, verifica che il resolver usato dal sistema sia corretto e raggiunga il DNS pubblico. In ambienti con split DNS o cache locale, il test può essere falsato. In quel caso ripeti la query con un resolver esplicito:
dig @1.1.1.1 +short TXT mail2024._domainkey.example.com
dig @8.8.8.8 +short TXT mail2024._domainkey.example.comConfrontare header e record con un controllo manuale
La verifica automatica è comoda, ma un controllo manuale ti aiuta a capire il perché di un fail. Estrai i campi principali dal messaggio:
grep -i '^DKIM-Signature:' message.emlPoi confronta il selettore con il record DNS:
dig +short TXT <selettore>._domainkey.<dominio>Controlla che il dominio firmante sia quello atteso e che la chiave pubblica non sia stata ruotata nel frattempo. Se il messaggio è stato firmato prima della rotazione e il DNS contiene solo la nuova chiave, la verifica di vecchie mail può fallire. Questo non è un bug del verifier: è una conseguenza della gestione chiavi.
Per i casi in cui la firma risulta formalmente presente ma il body hash non combacia, il problema spesso sta in un passaggio di trasporto che ha modificato il contenuto: newline convertite, footer aggiunto, antivirus che riscrive allegati, gateway che normalizza il testo. Qui conviene confrontare il messaggio prima e dopo il passaggio sospetto.
Verifiche utili con swaks e test controllati
Se vuoi fare un test controllato del tuo dominio, swaks è comodo per inviare una mail di prova e osservare l’intero percorso. Non ti dice da solo se DKIM passa sul destinatario finale, ma ti aiuta a produrre un messaggio consistente e a isolare il problema.
swaks --to test@example.net --from probe@example.com --server mail.example.com --header "Subject: DKIM test" --body "Verifica DKIM"Se il tuo MTA firma in uscita, salva anche una copia del messaggio generato lato server. Confrontare il raw prima dell’invio e quello ricevuto è spesso il modo più rapido per capire se la firma si rompe sul server mittente o lungo la catena di trasporto.
In ambienti con Postfix e OpenDKIM, i punti da controllare sono il socket di milter, i log del servizio e il record DNS del selettore. Esempio di log utile:
journalctl -u opendkim -n 100 --no-pager
journalctl -u postfix -n 100 --no-pagerAtteso: nessun errore sul caricamento della chiave, nessun “key not found”, nessun fallimento di connessione al socket. Se i log mostrano solo firma applicata ma il destinatario vede fail, il sospetto sale sugli intermediari o sul DNS pubblico non allineato.
Problemi tipici e come leggerli dal terminale
Alcuni errori ricorrono spesso e si riconoscono subito:
- Record assente:
dignon restituisce TXT; il selettore non è pubblicato o è sbagliato. - Chiave non coerente: il record esiste ma la firma fallisce; possibile rotazione non allineata.
- Body alterato: il verifier segnala hash mismatch; un relay ha modificato il contenuto.
- Header alterati: il campo
b=o gli header firmati non corrispondono più al raw originale. - Problema DNS locale: il resolver del server vede un record diverso dal DNS pubblico.
Per ridurre il tempo di diagnosi, non fermarti al primo “fail”. Leggi il messaggio completo del verifier e risali al punto esatto: record, selettore, hash del body o firma degli header. È molto più produttivo di un controllo generico sul pannello DNS.
Come verificare DMARC e SPF senza confonderli con DKIM
DKIM spesso viene confuso con SPF e DMARC, ma sono controlli diversi. SPF verifica quali server possono inviare per un dominio; DKIM verifica l’integrità e l’autenticità del messaggio firmato; DMARC usa SPF e DKIM per decidere la policy. Se DKIM fallisce, non significa automaticamente che la consegna fallirà: dipende da SPF, DMARC e dal comportamento del destinatario.
Da terminale puoi controllare anche questi record, per avere il quadro completo:
dig +short TXT example.com
dig +short TXT _dmarc.example.comQuesto non sostituisce la verifica DKIM, ma ti dice se il dominio è configurato in modo coerente con l’infrastruttura di posta. Se DKIM passa e DMARC fallisce, il problema può essere nell’allineamento del dominio From con il dominio firmante o con SPF.
Checklist rapida da terminale
Quando devi fare un controllo veloce, questa sequenza copre quasi tutti i casi utili:
# 1. Trova il selettore e il dominio firmante negli header
grep -i '^DKIM-Signature:' message.eml
# 2. Interroga il record DNS
dig +short TXT selector._domainkey.example.com
# 3. Verifica il messaggio raw
opendkim-testmsg < message.eml
# 4. Se il DNS locale è sospetto, prova resolver pubblici
dig @1.1.1.1 +short TXT selector._domainkey.example.com
dig @8.8.8.8 +short TXT selector._domainkey.example.comSe uno di questi passaggi fallisce, hai già il punto d’ingresso del problema. Se tutti passano ma il destinatario continua a vedere fail, il messaggio viene probabilmente alterato dopo la tua verifica oppure il provider ricevente applica un controllo più severo su canonicalizzazione, lunghezze o header duplicati.
Quando la verifica non basta: prova end-to-end
In produzione, la verifica davvero utile è end-to-end. Non basta che il record esista: devi vedere una mail inviata dal tuo sistema, ricevuta da un destinatario esterno, con header completi e risultato di autenticazione leggibile. Se hai accesso al server ricevente, i log o il report di autenticazione sono ancora più chiari.
Se il tuo obiettivo è chiudere un incidente, la priorità è questa: capire se il fallimento nasce nella firma in uscita, nel DNS, o nella modifica del messaggio lungo il percorso. Solo dopo ha senso intervenire sulla configurazione del selettore, sulla rotazione della chiave o sulle regole del gateway di posta.
In pratica, il terminale ti dà tre risposte affidabili: il record esiste, la mail è firmata, la firma verifica con quella chiave. Se una di queste manca, il problema è quasi sempre già visibile senza strumenti pesanti. Se tutte e tre tornano ma la delivery resta anomala, allora serve guardare il tratto di rete o il sistema intermedio che altera il messaggio.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.