Come si verifica DKIM per le email applicative?

Tratta una verifica DKIM come quattro test distinti

Un lookup DNS da solo non è una verifica DKIM completa. Primo, conferma che il messaggio contenga un campo DKIM-Signature e identifica la firma che intendi testare. Secondo, recupera e analizza il record della chiave pubblica indicato da quella firma. Terzo, verifica che le intestazioni firmate e il body canonicalizzato corrispondano ancora alla firma crittografica. Quarto, stabilisci se un dominio di firma valido è allineato con il dominio From visibile ai fini di DMARC. Questi livelli rispondono a domande diverse. Un record pubblicato può non essere usato, un messaggio può fare riferimento a un selettore mancante, una firma può fallire dopo una modifica del contenuto e un esito crittografico positivo può restare non allineato con il dominio dell'autore. Registra ogni esito invece di mostrare un unico badge verde. Tieni separati anche gli stati di trasporto e della casella: accettazione da parte del provider, accettazione da parte del server ricevente e arrivo in inbox non sono risultati della verifica DKIM.

Parti dalla firma di un messaggio reale

Ottieni il messaggio raw da un destinatario controllato raggiunto tramite il normale percorso dell'applicazione. In ogni campo DKIM-Signature, annota il dominio di firma `d=`, il selettore `s=`, l'algoritmo `a=`, le modalità di canonicalizzazione `c=`, l'elenco delle intestazioni firmate `h=`, il body hash `bh=`, i dati della firma `b=` e i timestamp, se presenti. L'RFC 6376 definisce i tag del dominio di firma e del selettore e li usa per individuare la chiave pubblica. Non indovinare il selettore da una dashboard del provider e non interrogare `_domainkey` senza di esso. Un messaggio può contenere più firme apposte da un mittente, da un intermediario o da un sistema di mailing list, quindi conserva il risultato di ciascuna firma. Evita di incollare messaggi di produzione in strumenti di verifica pubblici: intestazioni e body raw possono esporre destinatari, identificatori dei messaggi, dettagli di instradamento, token di disiscrizione e contenuti dell'applicazione. Usa uno storage con accesso limitato e una copia diagnostica oscurata quando il contenuto completo non serve.

Interroga il selettore e il dominio di firma esatti

Costruisci il nome DNS a partire dalla firma come `<selector>._domainkey.<signing-domain>`. Se l'intestazione contiene `s=app2026` e `d=notify.example.test`, interroga il record TXT in `app2026._domainkey.notify.example.test`. Annota il nome originale, il resolver, la risposta, il TTL e l'eventuale catena di CNAME. Analizza il record tag-valore risultante invece di cercare un frammento di testo. Il record può dichiarare versione, tipo di chiave, restrizione di servizio, flag, algoritmi di hash e dati della chiave pubblica. Un valore vuoto della chiave pubblica revoca la chiave. Distingui tra NXDOMAIN, risposta vuota, contenuto malformato, algoritmo non supportato, chiave inutilizzabile ed errore transitorio del resolver. Ripeti un lookup modificato dopo la scadenza del TTL tramite un resolver indipendente, ma non dare per scontato che tutti i riceventi si siano aggiornati subito. Un esito DNS positivo dimostra solo che in quel momento è stato restituito un record: non dimostra che il messaggio testato superi la verifica né che il provider stia firmando il traffico attuale con quel selettore.

Verifica intestazioni, body hash e firma

La verifica DKIM segue le regole di canonicalizzazione dichiarate nella firma. Il verificatore canonicalizza il body, ne calcola l'hash e lo confronta con `bh=`. Canonicalizza inoltre le intestazioni firmate elencate in `h=`, include il campo DKIM-Signature come previsto e verifica `b=` con la chiave pubblica. Usa una libreria di verifica mantenuta o il risultato di autenticazione di un ricevente attendibile, invece di ricreare queste trasformazioni con operazioni sulle stringhe. Una mancata corrispondenza del body hash indica spesso che il body è cambiato dopo la firma, mentre un errore nella firma delle intestazioni può indicare una modifica di un'intestazione firmata, una chiave errata, dati di firma corrotti o un errore di implementazione. Annota quale fase è fallita. Controlla se campi importanti come From, Subject, Date e Message-ID sono stati firmati, ma non inventare una policy universale sulle intestazioni da firmare. La canonicalizzazione tollera modifiche di formattazione definite: non rende sicuri l'inserimento arbitrario di footer, la riscrittura del MIME, il danneggiamento dei fine riga o le modifiche durante il trasporto.

Leggi i risultati del ricevente entro il suo perimetro di fiducia

L'RFC 8601 definisce l'intestazione Authentication-Results e i risultati DKIM, tra cui none, pass, fail, policy, neutral, temperror e permerror. Un pass significa che il ricevente ha trovato una firma accettabile che ha superato i test di verifica. Un temperror può riflettere una condizione destinata a cambiare, come un errore temporaneo nel lookup della chiave; un permerror difficilmente avrà esito positivo a un tentativo successivo senza una correzione. Annota il servizio di autenticazione che riporta il risultato, il dominio di firma, il selettore e l'algoritmo, se forniti. Considera attendibili solo i risultati inseriti all'interno del perimetro documentato del sistema ricevente, perché un mittente può aggiungere un campo Authentication-Results contraffatto prima della trasmissione. Esamina il risultato attendibile più in alto relativo all'ambiente di ricezione finale e tieni conto dei passaggi intermedi. Se riceventi diversi non concordano, confronta l'esatta versione del messaggio, la vista DNS, il momento della valutazione, gli algoritmi supportati e la policy locale. Non trasformare `dkim=pass` nell'affermazione che il provider di posta abbia approvato il contenuto o lo abbia messo in inbox.

Verifica l'allineamento DMARC separatamente dal pass DKIM

Un pass DKIM autentica il dominio di firma in `d=`, ma non richiede che quel dominio coincida con il dominio From RFC 5322 visibile. L'RFC 9989 usa un identificatore autenticato con DKIM valido ai fini di DMARC solo quando è allineato con il dominio dell'autore secondo la modalità di allineamento strict o relaxed applicabile. Per esempio, un messaggio da `billing.example.test` firmato con `d=provider.test` può superare DKIM ma restare non allineato. Una firma valida da `d=example.test` può essere allineata in modalità relaxed, a seconda del calcolo del dominio organizzativo e della policy. Riporta tre campi: risultato DKIM, dominio di firma e decisione di allineamento. Un messaggio può anche superare DMARC tramite SPF allineato quando DKIM fallisce o non è allineato, quindi un pass DMARC non dimostra che quella specifica firma DKIM sia valida. Le attuali linee guida di Gmail per i mittenti includono requisiti di autenticazione e allineamento per il traffico interessato, ma soddisfarli non garantisce comunque l'accettazione da parte del server ricevente né l'arrivo in inbox.

Verifica gli algoritmi attuali e la rotazione delle chiavi

L'RFC 8301 aggiorna i requisiti crittografici di DKIM: i firmatari devono usare `rsa-sha256`, i verificatori devono supportarlo e `rsa-sha1` non deve essere usato. Richiede inoltre chiavi di firma RSA di almeno 1024 bit, spiegando perché chiavi più lunghe sono preferibili quando è operativamente possibile. Uno strumento di verifica dovrebbe identificare l'algoritmo e segnalare materiale obsoleto o inutilizzabile, senza affermare che la sola lunghezza della chiave renda affidabile un flusso di posta. I flussi dei provider sono diversi. Amazon SES documenta Easy DKIM con chiavi a 2048 bit per impostazione predefinita e avverte che cambiare metodo di firma senza un passaggio intermedio può creare un periodo in cui i messaggi non hanno firma DKIM. Pianifica la rotazione con due selettori validi o con il meccanismo di sovrapposizione documentato dal provider, conferma che i nuovi messaggi usino il nuovo selettore, conserva la vecchia chiave pubblica finché può ancora arrivare posta in ritardo e rimuovila solo dopo il periodo di sovrapposizione. Non pubblicare mai la chiave privata di firma nel DNS, nei log, nei ticket o nei prompt.

Diagnostica gli errori partendo dal messaggio

Quando una verifica fallisce, conserva il messaggio raw e il risultato del ricevente prima di modificare il DNS. Conferma che il messaggio sia stato prodotto davvero dall'applicazione e dal provider previsti. Se manca la firma, controlla se la firma era abilitata per quell'identità, regione, tenant o classe di messaggi. Se il lookup del selettore fallisce, confronta i valori esatti di `d=` e `s=`, la zona DNS, la destinazione del CNAME, il TTL e le rotazioni recenti. Se la chiave viene analizzata correttamente ma il body hash fallisce, controlla gateway, footer delle liste, riscritture del tracking, trasformazioni MIME, fine riga e prodotti di sicurezza che potrebbero modificare il contenuto dopo la firma. Se la firma crittografica fallisce con un body hash corrispondente, esamina modifiche alle intestazioni firmate, discrepanze della chiave e implementazione della firma. Se DKIM passa ma DMARC fallisce, testa l'allineamento invece di ripubblicare la stessa chiave. Ripeti il test tramite destinatari controllati dopo il TTL o la propagazione della configurazione, e registra le prove per ogni classe di messaggi invece di dichiarare sistemato l'intero dominio sulla base di un solo campione riuscito.

Conserva un registro verificabile dei controlli DKIM

Per ogni messaggio controllato, conserva un identificatore di correlazione non sensibile, il sistema di invio, l'account o workspace del provider, il dominio From visibile, il sistema ricevente, l'ora del messaggio e il risultato completo di ogni firma. Includi `d=`, `s=`, `a=`, canonicalizzazione, intestazioni firmate, nome della query DNS, ora della risposta DNS e TTL, stato del record della chiave, risultato del body hash, risultato della firma, valore Authentication-Results attendibile, decisione di allineamento DMARC e responsabile della correzione. Conserva i messaggi raw solo dove i controlli di accesso e conservazione sono adeguati. Aggiungi lo scenario di test: invio applicativo normale, migrazione del provider, rotazione della chiave, percorso tramite gateway o caso di inoltro. In questo modo le regressioni sono confrontabili e uno screenshot non diventa una prova permanente dopo che selettori o elaborazione dei messaggi sono cambiati. Ripeti la verifica dopo modifiche alla configurazione del provider, al DNS, al metodo di firma, all'instradamento o dopo l'introduzione di una nuova classe di messaggi. Una dashboard operativa dovrebbe mostrare esplicitamente gli stati sconosciuti e non disponibili, invece di trattarli silenziosamente come pass o fail.

Come si inserisce SendHQ nella verifica

SendHQ richiede un dominio From verificato e fornisce eventi di consegna. Per un controllo DKIM, invia un messaggio controllato tramite il percorso applicativo previsto, ispeziona la firma ricevuta, interroga i valori effettivi `d=` e `s=` e registra separatamente l'allineamento. Non dedurre un selettore, la lunghezza della chiave, l'algoritmo di firma, l'arrivo in inbox o una garanzia di consegna dalla sola documentazione del prodotto.

Domande frequenti

Fonti

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — RFC Editor
• RFC 8301: Aggiornamento dell'algoritmo crittografico e della dimensione della chiave per DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 8601: campo di intestazione Authentication-Results — RFC Editor
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) — RFC Editor
• Linee guida di Gmail per i mittenti email — Google
• Easy DKIM in Amazon SES — Amazon Web Services
• Contratto OpenAPI di SendHQ — SendHQ