Controllo DKIM:
la tua chiave è abbastanza forte?

Digita il tuo dominio qui sopra — il selettore è facoltativo. Recuperiamo il record TXT a selector._domainkey.yourdomain (provando dieci selettori comuni se lo lasci vuoto), analizziamo ogni tag rispetto all'RFC 6376, poi convalidiamo la chiave stessa: il valore p= viene decodificato in base64, la struttura DER al suo interno viene percorsa campo per campo, e il modulo viene misurato e valutato — sotto i 1024 bit è debole, 1024 accettabile, 2048+ consigliato. Gratis, senza registrazione.

Il selettore è il nome davanti a ._domainkey — scelto da chi ha configurato la firma, invisibile a qualsiasi elenco DNS. Tre modi per trovare il tuo: apri un messaggio che hai inviato e leggi il tag s= nell'header DKIM-Signature («Mostra originale» in Gmail); incolla l'intero header in questo strumento e lo estraiamo per te; oppure lascia il selettore vuoto e proviamo i dieci valori predefiniti più comuni — google, selector1/2, k1/k2, s1/s2, default, dkim, mail. Trovare due selettori attivi è normale — è la rotazione che funziona.

Accettabile, datata, e da mettere in calendario per il pensionamento. Nessuno ha ancora fattorizzato pubblicamente RSA-1024 — ma il NIST l'ha vietata per le nuove firme già nel 2013, l'RFC 8301 dice ai firmatari DKIM che dovrebbero usare 2048, e i grandi provider di posta firmano già con 2048. Il 1024 non è l'emergenza — quella è il 512, fattorizzato nel 2012 su risorse cloud noleggiate. È la chiave che ruoti secondo il tuo calendario, invece che, prima o poi, secondo quello di un attaccante.

Modalità di test. L'RFC 6376 §3.6.1 impone ai verificatori di trattare la posta di un dominio in modalità di test esattamente come posta non firmata — anche quando la firma è verificata perfettamente. Esiste per poter testare il DKIM durante il rollout senza conseguenze. Il problema è che funziona fin troppo bene: niente si rompe finché resta attivo, quindi non viene mai rimosso. Il tuo dominio finisce così per firmare la posta per anni senza alcun beneficio. Se questo strumento ne trova uno, la correzione è cancellare quattro caratteri.

Revoca deliberata. L'RFC 6376 definisce un p= vuoto come «questa chiave pubblica è stata revocata». È la lapide corretta per un selettore che hai ritirato, ed è più chiara che eliminare il record, indistinguibile da un errore di battitura. Ne seguono due letture. Se ti sei allontanato da questo selettore e nulla firma più con esso, è prassi corretta: lascialo così. Se un mittente firma ancora con esso, ogni suo messaggio sta fallendo il DKIM in questo momento. Controlla i tuoi report DMARC alla ricerca di dkim=fail con questo selettore.

I verificatori devono supportare fino a 4096 bit (RFC 8301). Ma una chiave a 4096 bit produce un valore TXT abbastanza lungo da richiedere lo string-splitting, che alcune interfacce dei provider DNS gestiscono male. Non ti dà alcun vantaggio pratico di sicurezza rispetto a 2048 per una chiave che comunque dovresti ruotare, quindi 2048 è il punto di equilibrio. L'altra direzione è k=ed25519 (RFC 8463): chiavi minuscole da 32 byte, crittografia moderna. Il supporto dei verificatori non è ancora universale, quindi i deployment che la usano di solito firmano anche con RSA in parallelo. Questo strumento legge k= e ti dice quale hai pubblicato.

Da sola — no, e preferiamo dirlo chiaramente. Il DKIM dimostra due cose: che il messaggio non è stato alterato dopo la firma, e che il dominio d= se ne fa garante. Non dimostra che la riga From: vista dal destinatario corrisponda a quel dominio — un falsificatore può firmare in modo impeccabile con il proprio dominio mostrando comunque il tuo. Colmare quel divario è compito del DMARC (allineamento), e dire quali server possono inviare posta è compito dell'SPF. Lo stack che funziona è SPF + DKIM + DMARC. Questo strumento verifica che la parte DKIM sia reale — una chiave revocata o in modalità di test mina silenziosamente anche gli altri due.