DKIM fail indica che il destinatario non ha potuto convalidare una firma DKIM. Il risultato richiede un'indagine, ma non stabilisce da solo l'affidabilità del messaggio né il suo arrivo nella posta in entrata. Per coordinare SPF, DKIM, DMARC, percorsi e caselle, inizia dalla guida alla posta aziendale.
Il messaggio sembra normale in uscita, ma Gmail, Microsoft o Yahoo segnala dkim=fail. Questo può influire sui filtri o sull'accettazione, insieme ad altri segnali. Occorre capire se l'errore riguarda DNS, sistema di invio o un dispositivo che modifica la posta durante il transito.
Affronta il problema come un incidente di autenticazione: leggi il risultato, identifica la categoria, controlla selettore e chiave e verifica cosa è successo dopo la firma. Correggi il punto dimostrato, senza cambiare record alla cieca.
Cosa significa realmente DKIM fail?
Un esito DKIM negativo indica che la firma non è stata convalidata. Modifiche al contenuto possono produrre fail; una chiave assente o non valida può produrre permerror; un errore temporaneo di interrogazione DNS, temperror. Distingui questi esiti e verifica anche la corrispondenza tra chiave pubblica e privata.
La RFC 6376 definisce l'hash del corpo in bh= e la firma in b=. Se la verifica non riesce, la firma non passa. Non dimostra necessariamente una falsificazione: firma applicata troppo presto, chiave errata o modifiche successive sono altre possibili cause.
Pensa a DKIM come a un sigillo: se non può essere verificato, bisogna indagare il motivo. Un sigillo non valido non dimostra da solo che tutto il pacco sia malevolo.
Esamina prima Authentication-Results nel messaggio ricevuto. L'esempio seguente combina risultati illustrativi incoerenti come situazione normale: con SPF valido e allineato allo stesso dominio From, DMARC dovrebbe normalmente passare anche se DKIM fallisce.
Authentication-Results: mx.google.com;
dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
spf=pass smtp.mailfrom=example.com;
dmarc=fail header.from=example.comPrima di modificare il mittente, confronta la configurazione con i record DNS richiesti da TrekMail.
Quattro categorie comuni di errori DKIM
La diagnosi riguarda spesso hash del corpo, selettore o chiave, formato DNS e modifiche introdotte da inoltri o relay. Classificare prima il problema evita di cambiare chiavi quando la causa è altrove.
| Risultato di autenticazione | Possibile significato | Primo controllo |
|---|---|---|
dkim=fail (body hash did not verify) | Il corpo firmato non corrisponde dopo la canonicalizzazione | Relay in uscita, avvisi legali, link e canonicalizzazione |
dkim=fail (signature did not verify) | Chiavi diverse, intestazioni modificate o altro errore di firma | Selettore, rotazione recente, mittente e intestazioni firmate |
dkim=permerror (no key for signature) | Non è stata ottenuta una chiave pubblica utilizzabile | Nome del selettore, cache DNS e formato del record |
dkim=temperror | Errore temporaneo del DNS o del resolver | DNS autoritativo, TTL e disponibilità dei server |
La tabella orienta la prima analisi. Conferma poi la causa con i dati del messaggio e del DNS.
Tipo di errore 1: hash del corpo non corrispondente
L'hash ricalcolato sul corpo ricevuto, dopo la canonicalizzazione prevista dalla firma, non corrisponde all'hash firmato. Non è sempre un confronto byte per byte, e questo risultato non prova che il DNS sia corretto.
Secondo la RFC 6376, se l'hash ricalcolato non corrisponde a bh=, questa verifica fallisce in modo permanente. Controlla modifiche dopo la firma, configurazione del firmatario e integrità del campione analizzato.
Cause comuni:
- Microsoft 365, Exchange o un gateway aggiunge avvisi legali dopo la firma.
- Mimecast, Barracuda, Proofpoint o altri filtri riscrivono i link.
- Un relay modifica spazi o terminazioni di riga oltre quanto tollerato dalla canonicalizzazione.
- Un'applicazione firma prima che un gateway modifichi i delimitatori MIME o aggiunga avvisi come
[External].
Controlla c=. Il modo c=simple/simple tollera meno modifiche di quello rilassato. La canonicalizzazione rilassata del corpo nella RFC 6376 ignora gli spazi finali e raggruppa quelli ripetuti nelle righe. Aiuta con alcune variazioni di formato, non con modifiche sostanziali del contenuto.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=tm1; h=from:to:subject:date:mime-version;
bh=...; b=...Una miglioria architetturale è firmare alla fine del percorso che controlli, dopo piè di pagina, riscritture e regole di conformità. Riduce le modifiche interne successive, senza garantire che intermediari esterni preservino i dati firmati.
Se inoltri messaggi, consulta configurazione dell'inoltro della posta e inoltrare la posta del dominio a Gmail. Un percorso testato può comportarsi diversamente quando intervengono altri intermediari.
Tipo di errore 2: selettore o chiavi errati
La firma può indicare un selettore senza una chiave utilizzabile, oppure la pubblica nel DNS può non corrispondere alla privata del mittente. È un problema di configurazione; altri errori di firma possono derivare da intestazioni firmate modificate.
Individua dominio e selettore nella firma:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...Interroga esattamente quel selettore:
dig txt k1._domainkey.example.com +shortUna risposta vuota può dipendere da record assente, nome errato, cache o problemi di interrogazione. Verifica lo stato DNS prima di concludere. Se ottieni una chiave, confrontala con quella attesa dal mittente attuale. In migrazioni o ambienti misti, un altro sistema può continuare a usare una vecchia privata.
Può succedere con più mittenti per un dominio: applicazioni tramite SES, supporto tramite Microsoft 365 e campagne tramite un altro ESP. Una rotazione mal coordinata può produrre errori intermittenti.
Con l'invio gestito TrekMail, consulta Managed TrekMail SMTP e verifica dove viene applicata la firma nel percorso disponibile. Con Nano o un mittente esterno, consulta SMTP proprio (BYO): il servizio che invia effettivamente deve essere configurato per firmare.
Tipo di errore 3: pubblicazione errata delle chiavi lunghe
Una chiave da 2048 bit può essere pubblicata male se l'interfaccia gestisce impropriamente il TXT. Potresti ottenere permerror, un errore di formato o una chiave incompleta nella risposta.
La RFC 8301 richiede chiavi RSA di almeno 1024 bit e raccomanda almeno 2048 bit. Questa indicazione crittografica non garantisce compatibilità con tutti i pannelli DNS.
Verifica che le stringhe TXT appartengano a un solo record, senza troncamenti o virgolette errate. L'esempio illustra la struttura; i frammenti non costituiscono una chiave utilizzabile.
; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
"restOfThePublicKeyContinuesHere..."
)Interroga il DNS ed esamina tutte le stringhe, non solo il primo frammento:
dig txt k1._domainkey.example.com +shortControlla soprattutto dopo un cambio di fornitore DNS, uno spostamento di zona o una copia manuale dei record. Confronta la risposta completa con la chiave attesa.
Tipo di errore 4: inoltri, relay e mancato allineamento
Un intermediario può invalidare DKIM modificando dati firmati, mentre SPF può fallire con il nuovo percorso. DMARC fallisce se non rimane un'altra autenticazione valida e allineata; l'accettazione dipende anche dalla politica del destinatario.
Immagina un messaggio da example.com inviato a un'università che lo inoltra a Gmail. SPF può fallire perché il server di inoltro non è autorizzato dal dominio originale. DKIM può sopravvivere se i dati firmati restano intatti; un piè di pagina, link riscritto o modifica a un oggetto firmato può invalidarlo. DMARC fallisce se non esiste neppure un altro risultato valido e allineato.
Per i mittenti generici verso account Gmail personali, Google richiede SPF o DKIM; per quelli di grandi volumi, entrambi e DMARC, con l'allineamento applicabile. Inoltri e liste hanno particolarità; ARC può trasmettere risultati precedenti. Il destinatario decide se fidarsi di ARC, che non garantisce accettazione né ripara la firma originale.
Se inoltri posta, considera SRS e un percorso che preservi i dati firmati. Secondo la configurazione disponibile, TrekMail può usare SRS per validare SPF con il nuovo mittente della busta. SRS non ripristina l'allineamento con il From originale e non sostituisce DKIM.
Con molti alias, leggi inoltro degli alias e posta con dominio proprio. Il percorso effettivo di ogni messaggio conta più del numero di alias.
Dove controllare quando compare DKIM fail
Segui una procedura ripetibile: risultato di autenticazione, ricerca del selettore, percorso di firma e allineamento. Aiuta a distinguere errori DNS da modifiche successive senza cambiare la configurazione sbagliata.
- Apri il messaggio originale e trova
Authentication-Results. Annota il risultato DKIM esatto. - Individua
d=,s=ec=nell'intestazioneDKIM-Signature. - Interroga il selettore con
dige verifica il nomeselector._domainkey.example.com. - Conferma quale piattaforma firma realmente. Più mittenti possono produrre errori intermittenti.
- Verifica se un gateway, filtro o server di inoltro modifica il corpo o le intestazioni firmate.
- Controlla l'allineamento:
d=deve essere allineato al dominioFrom:visibile affinché DKIM contribuisca al superamento di DMARC, secondo il modo rilassato o rigoroso.
Un'altra precauzione: incollare frammenti in un verificatore esterno può generare falsi errori di hash. Analizza il messaggio originale completo o un file .eml esportato senza modifiche.
Correggere DKIM fail con un flusso coordinato TrekMail
Correggere DNS, relay e piè di pagina presso più fornitori richiede di capire chi firma e quando. Un flusso coordinato firma alla fine del percorso controllato, verifica il DNS e distingue invio gestito da SMTP proprio.
| Problema comune | Approccio coordinato |
|---|---|
| Più passaggi interni modificano messaggi già firmati | Firmare dopo le modifiche nell'ultimo gateway controllato |
| Rotazione manuale in strumenti diversi | Verificare gestione di firme e chiavi dello SMTP gestito disponibile |
| Modifiche DNS con SPF duplicati o selettori errati | Usare record coerenti e verificare ciascuno |
| Inoltri senza considerare SRS o ARC | Preservare l'autenticazione quando possibile e valutare i meccanismi applicabili |
TrekMail distingue Nano con SMTP proprio dai piani a pagamento con invio gestito, secondo le loro condizioni. A titolo indicativo, questi vengono pubblicizzati da $3.50 al mese. Per una firma di uscita gestita da TrekMail, conferma piano e percorso disponibili. Se firma la tua configurazione SES, SendGrid o Mailgun, diagnostica DKIM in quel servizio. I piani a pagamento possono offrire una prova di 14 giorni che richiede una carta. Consulta le condizioni vigenti nei prezzi TrekMail.
Con SMTP proprio, l'indagine riguarda spesso selettore, chiavi e modifiche del percorso esterno. Verifica i dati prima di attribuire il problema alla casella o a uno specifico fornitore.
Checklist finale per un incidente DKIM fail
Tratta DKIM fail come un errore specifico di verifica, non come una spiegazione universale della recapitabilità. Leggi il risultato, interroga il selettore ed esamina il percorso prima di modificare la configurazione.
Prima di cambiare la produzione:
- Leggi l'intestazione completa, non solo il riepilogo di un mancato recapito.
- Distingui hash del corpo, verifica della firma, permerror e temperror.
- Interroga il selettore esatto nel DNS.
- Verifica che la chiave sia completa e le stringhe formino il record corretto.
- Firma alla fine del percorso controllato se avvengono modifiche successive.
- Valuta
c=relaxed/relaxedper variazioni di formato compatibili, non modifiche sostanziali. - Controlla l'allineamento DMARC tra
d=e il dominioFrom:visibile.
Se l'errore persiste, indaga la causa invece di aspettare senza dati. Correggi punto di firma, selettore o intermediario responsabile e conferma il risultato con messaggi reali.
