Errore DKIM: cosa significa ogni errore e come risolverlo

Il DomainKeys Identified Mail (DKIM) è uno dei pilastri fondamentali dell'autenticazione delle e-mail. Aggiungendo una firma crittografica ai messaggi in uscita, il DKIM consente ai server di posta in ricezione di verificare che un'e-mail sia stata effettivamente autorizzata dal proprietario del dominio e che il suo contenuto non sia stato manomesso durante il transito.

Tuttavia, quando un server ricevente esamina un’e-mail in arrivo e rileva lo stato “dkim=fail” nell’intestazione, l’autenticazione fallisce. Un errore DKIM segnala ai gateway riceventi, come Google Workspace, Microsoft 365 o Apple Mail, che il corpo del messaggio è stato modificato dopo aver lasciato il mittente, che non è stato possibile recuperare la chiave pubblica dal DNS oppure che la firma crittografica stessa non è valida.

A seconda della politica DMARC del tuo dominio e delle impostazioni di sicurezza del destinatario, gli errori DKIM possono far sì che le email aziendali legittime finiscano nelle cartelle dello spam o vengano respinte del tutto. Questa guida funge da riferimento esplicito ai messaggi di errore per aiutarti a individuare la stringa esatta dell'errore nelle intestazioni delle tue email, a identificarne la causa principale e a risolvere rapidamente il problema.

Motivi comuni di fallimento del DKIM

Sebbene gli errori di convalida DKIM derivino in ultima analisi da una discrepanza nell'hash o da un errore nel recupero della chiave, le cause operative concrete rientrano solitamente in diverse categorie prevedibili. Il confronto incrociato tra queste cause sottostanti e la stringa di errore specifica presente nelle intestazioni delle vostre e-mail vi indicherà direttamente la soluzione.

1. Modifiche ai messaggi da parte dei gateway di posta elettronica e dei dispositivi di sicurezza

La causa più frequente di errore DKIM negli ambienti aziendali è rappresentata da un servizio intermedio che modifica il contenuto del messaggio dopo che la firma DKIM è già stata applicata. I dispositivi di sicurezza, i gateway in uscita, i filtri antispam e gli strumenti di prevenzione della perdita di dati (DLP) spesso alterano i messaggi in uscita aggiungendo piè di pagina aziendali, inserendo link di tracciamento, ricodificando i set di caratteri o modificando i confini MIME. 

Se la firma viene apposta sul server di posta principale prima che i messaggi passino attraverso questi dispositivi, l'hash del corpo del messaggio calcolato dal destinatario non corrisponderà alla firma originale, generando un errore dkim=fail (hash del corpo del messaggio non verificato).

2. Mailing list e inoltro automatico delle e-mail

Quando un’e-mail viene inviata a una mailing list o inoltrata automaticamente tramite agenti di trasferimento della posta (MTA) intermedi, il server di inoltro spesso modifica le intestazioni del messaggio (come “Oggetto” o “A”) oppure aggiunge piè di pagina relativi alla gestione della mailing list (come link per annullare l’iscrizione o dichiarazioni di non responsabilità relative alla lista). Poiché la firma crittografica copre questi elementi, qualsiasi modifica apportata dopo la firma invalida il controllo di verifica. 

Sebbene i protocolli moderni come l’Authenticated Received Chain (ARC) aiutino i server di inoltro a preservare lo stato di autenticazione, i controlli DKIM non elaborati sui messaggi inoltrati spesso falliscono.

3. Record TXT DNS mancanti, configurati in modo errato o troncati

I server di posta in arrivo devono recuperare la tua chiave pubblica da uno specifico record DNS TXT situato all'indirizzo selector._domainkey.yourdomain.com. Se questo record DNS manca, è pubblicato con un nome di selettore errato o subisce un ritardo dovuto alla propagazione DNS, il destinatario non è in grado di recuperare la chiave, generando un errore dkim=fail (nessuna chiave per la firma).

Inoltre, si verifica un problema specifico e ricorrente con le chiavi RSA a 2048 bit. Secondo la RFC 1035, una singola stringa all’interno di un record TXT del DNS è limitata a 255 byte. Una chiave RSA a 2048 bit codificata in base64 ha una lunghezza di circa 392 caratteri. Se il provider o l’amministratore DNS incolla una chiave a 2048 bit come singola stringa senza virgolette, gli strumenti di gestione DNS meno recenti potrebbero troncare il contenuto della chiave, generando una chiave pubblica incompleta nel DNS e causando un errore dkim=fail (firma non verificata).

4. Incompatibilità delle chiavi, rotazione delle chiavi non annunciata e migrazioni dei provider

Affinché la verifica DKIM vada a buon fine, la chiave privata utilizzata dal server di posta mittente per generare la firma deve corrispondere matematicamente alla chiave pubblica pubblicata nel proprio DNS. Si verifica una discrepanza crittografica se:

• Il server di posta responsabile della firma genera una nuova chiave privata, ma il record DNS non viene aggiornato contemporaneamente.
• Un fornitore di servizi di posta elettronica (ESP) effettua la rotazione delle proprie chiavi di firma senza aggiornare il record TXT pubblicato o il destinatario del record CNAME.
• Un dominio viene migrato su una nuova piattaforma di hosting, mentre il server di posta elettronica continua a effettuare la firma utilizzando un vecchio selettore o una coppia di chiavi non più in uso.

5. Errori di sintassi nei record DNS e impostazioni di canonizzazione rigorosa

Piccoli errori di formattazione nel record della chiave pubblica (come punti e virgola mancanti, spazi superflui all’interno del payload della chiave in base64 o nomi di tag errati) rendono la chiave pubblica non analizzabile dagli MTA destinatari. 

Allo stesso modo, se il server di firma utilizza la canonicalizzazione semplice per le intestazioni o il contenuto del corpo (c=simple/simple), anche minime conversioni delle terminazioni di riga (CRLF rispetto a LF) o modifiche agli spazi bianchi finali introdotte dai relè di transito comprometteranno la verifica.

Recensione Sintassi del record DKIM.

6. Non hai configurato DKIM per i tuoi fornitori di servizi di posta elettronica di terze parti

Se utilizzi diversi fornitori di servizi di posta elettronica di terze parti per inviare e-mail per conto della tua organizzazione, devi contattarli per ricevere istruzioni su come attivare il DKIM per le tue e-mail in uscita. Se utilizzi domini o sottodomini personalizzati registrati su questo servizio di terze parti per inviare e-mail ai tuoi clienti, assicurati di richiedere al tuo fornitore di gestire il DKIM per tuo conto.

Idealmente, se il tuo fornitore di servizi esterno ti sta aiutando a esternalizzare la gestione delle tue e-mail, dovrebbe configurare il tuo dominio pubblicando un record DKIM sul proprio DNS utilizzando un selettore DKIM che sia unico per te, senza che tu debba intervenire.

O, 

È possibile generare una coppia di chiavi DKIM e fornire la chiave privata al proprio provider di posta elettronica, pubblicando al contempo la chiave pubblica sul proprio DNS. 

Configurazioni errate possono causare il malfunzionamento del DKIM, pertanto è necessario comunicare apertamente con il proprio fornitore di servizi in merito alla configurazione del DKIM. configurazione DKIM. 

Nota: alcuni server di scambio di terze parti inseriscono piè di pagina formattati nel corpo del messaggio. Se tali server fungono da server intermedi in un processo di inoltro delle e-mail, il piè di pagina combinato può essere un fattore che contribuisce al fallimento del DKIM. 

7. Problemi di comunicazione con il server

In alcune situazioni, l'e-mail potrebbe essere inviata da un server su cui DKIM è disabilitato. In tali casi, DKIM non funzionerà per quell'e-mail, anche se gli altri server della tua infrastruttura sono configurati correttamente. È importante assicurarsi che tutte le parti coinvolte nella comunicazione abbiano DKIM correttamente attivato. 

8. Interruzione del servizio DNS / Tempo di inattività del DNS

Questo è un motivo comune per i fallimenti del DKIM. L'interruzione del DNS può essere dovuta a una serie di motivi, tra cui gli attacchi denial of service. Anche la manutenzione ordinaria del server dei nomi può essere la causa di un'interruzione del DNS. Durante questo periodo di tempo (solitamente breve), i server dei destinatari non possono eseguire query DNS. 

Poiché sappiamo che DKIM esiste nel vostro DNS come record TXT/CNAME, il client-server esegue una ricerca per interrogare il DNS del mittente per la chiave pubblica durante l'autenticazione. Durante un'interruzione, questo non è ritenuto possibile e quindi può rompere DKIM. 

9. Utilizzo di OpenDKIM

OpenDKIM è un'implementazione open source di DKIM che può essere installata sul proprio server di posta per firmare e verificare le e-mail in uscita. Quando si utilizza una configurazione OpenDKIM self-hosted, il servizio comunica in genere con il server di posta tramite la porta 8891.

Per assicurarti che OpenDKIM funzioni correttamente, puoi utilizzare uno strumento di verifica delle porte online per controllare che la porta 8891 sia aperta e accessibile sul tuo server. Dovresti inoltre verificare che le autorizzazioni richieste siano configurate correttamente. Autorizzazioni errate possono impedire a OpenDKIM di accedere al proprio socket o di collegarsi ad esso correttamente.

Controlla la configurazione del server e la directory contenente il socket OpenDKIM per assicurarti che la directory esista e disponga dei diritti di proprietà e delle autorizzazioni appropriate.

10. Verifica DKIM per errori di allineamento

Se hai DMARC configurato per il tuo dominio oltre a DKIM, durante il verifica DKIM, il valore del dominio nel campo d= della firma DKIM nell'intestazione dell'e-mail deve corrispondere al dominio presente nell'indirizzo del mittente. Può trattarsi di una corrispondenza rigorosa, in cui i due domini devono corrispondere esattamente, oppure di una corrispondenza flessibile, che consente una corrispondenza a livello organizzativo per superare il controllo. 

Un errore DKIM può verificarsi se il dominio indicato nell'intestazione della firma DKIM non corrisponde al dominio presente nell'intestazione "Da"; questo potrebbe essere un caso tipico di spoofing del dominio o di un attacco di impersonificazione. 

Spiegazione degli errori DKIM (in base al messaggio di errore)

Cerca qui sotto l'errore specifico che hai riscontrato per capire quale problema si è verificato sul server di destinazione e come risolverlo.

dkim=fail (l'hash del corpo del messaggio non è stato verificato)

L'errore "dkim=fail" (hash del corpo non verificato) indica che la chiave pubblica è stata recuperata correttamente dal DNS e che l'intestazione della firma complessiva è stata formattata correttamente, ma l'hash crittografico del corpo del messaggio calcolato dal destinatario non corrisponde al valore dell'hash memorizzato nel tag "bh=" della firma.

In parole povere, il corpo dell'e-mail è stato modificato dopo che il server di invio lo aveva firmato.

Cause principali:

• I gateway di sicurezza in uscita, gli strumenti di esclusione di responsabilità o i plugin CRM aggiungevano note legali, piè di pagina promozionali o pixel di tracciamento dopo la fase di firma.
• I relay intermedi hanno modificato le interruzioni di riga, i set di caratteri o gli spazi bianchi durante il transito.
• Il software di inoltro delle e-mail o delle mailing list ha modificato il contenuto del messaggio.

Come risolvere il problema:

1. Riorganizza il flusso della posta in uscita in modo che la firma DKIM venga eseguita come fase assolutamente finale prima che il messaggio lasci la tua infrastruttura di rete, assicurandoti che tutti i piè di pagina e i link di tracciamento siano stati inseriti prima della firma.
2. Assicurati che il tuo server di posta utilizzi la canonicalizzazione del corpo del messaggio in modalità "relaxed" (c=relaxed/relaxed o c=relaxed/simple), che tollera piccole variazioni relative agli spazi bianchi e alle terminazioni di riga durante il transito.
3. Se nelle intestazioni DKIM è presente un tag l= (lunghezza), rimuovilo. Il tag l= limita la porzione del corpo del messaggio sottoposta a firma e crea vulnerabilità di sicurezza, senza riuscire a risolvere i problemi legati alla modifica del corpo del messaggio.

dkim=fail (nessuna chiave per la firma)

L'errore "dkim=fail" (nessuna chiave per la firma) si verifica quando il server ricevente estrae il dominio (d=) e il selettore (s=) dall'intestazione DKIM-Signature dell'e-mail e tenta di interrogare il DNS all'indirizzo s=._domainkey.d=, ma non riesce a recuperare un record di chiave pubblica valido.

Questo errore circoscrive il problema specificatamente alla configurazione DNS o a disallineamenti dei selettori.

Cause principali:

• Il nome del selettore specificato dall'applicazione mittente non corrisponde al prefisso del selettore pubblicato nel DNS.
• Il record TXT o CNAME non è mai stato pubblicato sul server DNS autorevole.
• Il record DKIM è stato pubblicato di recente e non si è ancora diffuso completamente tra i resolver DNS globali.
• Il record della chiave pubblica è stato cancellato accidentalmente durante una migrazione del dominio o un'operazione di pulizia delle chiavi.

Come risolvere il problema:

1. Esaminare l'intestazione grezza dell'e-mail per individuare la stringa di selezione esatta nel tag "s=".
2. Verifica che esista un record DNS TXT o CNAME all’indirizzo selector._domainkey.yourdomain.com (per istruzioni su come individuare le stringhe di selezione, consulta la nostra guida dettagliata su come trovare il proprio selettore DKIM).
3. Verificare che il record DNS includa i tag obbligatori v=DKIM1; e k=rsa; (o k=ed25519;) insieme al payload della chiave pubblica p=.

dkim=fail (la firma non è stata verificata)

A differenza di un errore di hash del corpo del messaggio, l'errore "dkim=fail" (firma non verificata) indica che la valutazione crittografica della stringa di firma principale (il tag "b=") non è andata a buon fine. Il destinatario ha recuperato una chiave pubblica dal DNS, ma tale chiave non è riuscita a decrittografare e verificare il payload della firma dell'intestazione.

Questo errore indica chiaramente la presenza di una coppia di chiavi non valida o di campi di intestazione modificati.

Cause principali:

• Discrepanza nella coppia di chiavi: La chiave privata utilizzata dal server mittente per firmare il messaggio non corrisponde alla chiave pubblica pubblicata nel DNS sotto quel selettore.
• Chiave DNS troncata: Una chiave da 2048 bit è stata pubblicata in modo errato come singola stringa di oltre 255 byte, causando il troncamento dei dati della chiave pubblica da parte del server DNS.
• Modifica delle intestazioni: un server di posta intermedio o un gateway ha modificato le intestazioni incluse esplicitamente nel tag h= della firma (come From, To, Subject o Date) dopo la generazione della firma.

Come risolvere il problema:

1. Verifica che il tuo record della chiave pubblica a 2048 bit nel DNS sia stato suddiviso correttamente in più stringhe racchiuse tra virgolette, ciascuna di lunghezza inferiore a 255 byte.
2. Verifica che la tua chiave privata sul server di posta corrisponda alla chiave pubblica pubblicata. In caso di dubbi, genera una nuova coppia di chiavi, aggiorna il DNS e verifica la corrispondenza.
3. Assicurarsi che i dispositivi di sicurezza intermedi non modifichino i campi dell'intestazione firmata durante il transito.

Errore non grave DKIM

Nell'autenticazione delle e-mail, il “soft fail” non è uno stato nativo del protocollo DKIM. Mentre l’SPF definisce esplicitamente un risultato SoftFail (~all), la RFC 6376 definisce i risultati DKIM esclusivamente come "pass", "fail", "policy", "neutral", "temperror" o "permerror".

Quando gli amministratori o gli strumenti di sicurezza della posta elettronica segnalano un “soft fail DKIM”, in genere si riferiscono a uno dei due seguenti scenari:

1. Valutazione DMARC con p=none: Un messaggio non supera l'autenticazione DKIM, ma poiché la politica DMARC del proprietario del dominio è impostata in modalità di monitoraggio (p=none), il provider di posta elettronica ricevente consegna l'e-mail nella posta in arrivo contrassegnando lo stato della valutazione interna come "soft failure".
2. Classificazione specifica per gateway: I gateway di sicurezza della posta (come Cisco Secure Email o Mimecast) a volte generano etichette diagnostiche interne come “soft fail” quando un’e-mail non supera il controllo DKIM, ma supera quello SPF con un corretto allineamento DMARC, il che significa che la consegna del messaggio nel suo complesso è consentita.

Se nei log si riscontra un'etichetta “soft fail”, considerarla come un errore DKIM standard e controllare le intestazioni per individuare la stringa di errore RFC sottostante (hash del corpo non verificato o nessuna chiave per la firma).

Altri errori DKIM che potresti riscontrare

I server di posta in ricezione possono inoltre riportare i seguenti codici diagnostici DKIM standardizzati nelle intestazioni "Authentication-Results":

DKIM non supera il test, mentre SPF lo supera (e altri risultati contrastanti)

Quando si esaminano i rapporti sulla deliverability delle e-mail, capita spesso di riscontrare casi in cui i risultati relativi ai protocolli sono in conflitto tra loro. Comprendere in che modo i gateway di ricezione valutano queste combinazioni è fondamentale per la risoluzione dei problemi.

In base alle specifiche DMARC (RFC 7489), un’e-mail supera la convalida DMARC complessiva purché almeno uno protocollo sottostante (SPF o DKIM) restituisca lo stato PASS e sia correttamente allineato con il dominio indicato nell’intestazione visibile “Da:”.

Ecco come si risolvono le combinazioni di protocolli più comuni durante la consegna:

Perché il mio messaggio è stato bloccato a causa del DKIM?

Se l'SPF viene superato ma il tuo messaggio viene comunque bloccato o contrassegnato come spam a causa di un errore DKIM, si verifica una delle due seguenti situazioni:

1. SPF non allineato: Il controllo SPF è stato superato per un dominio di un server di terze parti (ad es. mail.mcsv.net), ma non corrispondeva al dominio effettivo dell'intestazione From:. Poiché l'allineamento SPF non è andato a buon fine e il controllo DKIM ha dato esito negativo, anche il controllo DMARC ha dato esito negativo.
2. Rigorosa applicazione delle politiche da parte dei provider: I principali destinatari, come Google e Microsoft, applicano rigide politiche di sicurezza nei confronti dei mittenti che inviano messaggi in massa. Se un'e-mail presenta errori strutturali di autenticazione insieme a segnali elevati di reclami per spam, gli algoritmi dei destinatari potrebbero bloccare il messaggio indipendentemente dal fatto che abbia superato parzialmente i controlli.

Per capire in che modo l'applicazione delle politiche influisca sulle e-mail non conformi, consulta la nostra guida su cosa sia una politica DMARC e verifica il tuo dominio utilizzando il nostro strumento gratuito di verifica dei record DMARC.

Come interpretare i risultati DKIM nelle intestazioni delle e-mail

Per identificare il messaggio di errore specifico, è necessario visualizzare le intestazioni Internet non elaborate di un’e-mail di prova recapitata.

Passaggio 1: Accedere alle intestazioni in formato grezzo nel proprio client di posta elettronica

• Gmail: Apri il messaggio, clicca sui tre puntini verticali accanto al pulsante "Rispondi" e seleziona "Mostra originale".
• Microsoft Outlook (Web): Apri il messaggio, fai clic sui tre puntini nella barra delle azioni, seleziona "Visualizza" e fai clic su "Visualizza dettagli del messaggio".
• Apple Mail: Apri l'e-mail, fai clic su "Visualizza" nella barra dei menu in alto, passa con il mouse su "Messaggio" e seleziona "Codice sorgente".

Fase 2: Individuare l'intestazione "Authentication-Results"

Scorri il testo grezzo dell'intestazione per individuare il blocco “Authentication-Results”. Cerca la voce “dkim=”.

Una tipica voce di intestazione che indica un errore si presenta così:

Risultati dell'autenticazione: mx.google.com;
dkim=fallito (l'hash del corpo del messaggio non è stato verificato) [email protected] header.s=s1 header.b=W8xKz2L;
spf=pass (google.com: il dominio [email protected] indica 192.0.2.1 come mittente autorizzato) [email protected];
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Tag di intestazione principali da controllare:

• dkim=: Visualizza lo stato di verifica immediato (superato, fallito, errore permanente, ecc.) seguito dalla stringa di errore esplicita tra parentesi.
• header.i=: Mostra l'identità/il dominio che ha firmato l'e-mail.
• header.s=: Identifica il selettore esatto utilizzato per recuperare la chiave pubblica dal DNS.
• header.d=: Indica il dominio dell'organizzazione che si assume la responsabilità della firma.

L'analisi manuale delle intestazioni grezze delle e-mail può risultare complessa, dispendiosa in termini di tempo e, nel complesso, scomoda. È possibile saltare questi passaggi utilizzando il nostro strumento gratuito di analisi delle intestazioni e-mail per ottenere immediatamente informazioni di facile comprensione sui risultati delle autenticazioni SPF, DKIM e DMARC. 

Come risolvere gli errori DKIM e impedire che si ripetano

Segui questa procedura sistematica di correzione per risolvere i problemi relativi al DKIM nell'intera infrastruttura di invio:

1. Verificare la validità della chiave pubblica nel DNS

Utilizza uno strumento di ricerca online come il nostro Ricerca record DKIM per verificare la chiave pubblica pubblicata all'indirizzo selector._domainkey.yourdomain.com.

• Assicurati che non ci siano errori di sintassi, refusi o doppi punti e virgola.
• Verificare che la suddivisione della chiave sia corretta: se si utilizza una chiave a 2048 bit, assicurarsi che l’editor DNS abbia suddiviso il payload in segmenti di stringa racchiusi tra virgolette di lunghezza inferiore a 255 caratteri (ad esempio, “v=DKIM1; k=rsa; p=part1…” “part2…”). Non creare mai record TXT separati per lo stesso selettore.

2. Spostare la firma DKIM all'ultimo hop in uscita

Se la vostra organizzazione instrada le e-mail attraverso gateway di sicurezza secondari, strumenti di disclaimer o soluzioni CRM, assicuratevi che la firma DKIM avvenga dopo che tali strumenti abbiano apportato le loro modifiche. Se un dispositivo deve modificare il contenuto, configuratelo in modo che esegua la fase finale di firma DKIM per conto del vostro dominio.

3. Aggiornare le impostazioni di canonicalizzazione

Modifica le impostazioni di canonicalizzazione del tuo server di posta impostandole su "relaxed/relaxed" (oppure "c=relaxed/relaxed" nell'intestazione DKIM). In questo modo si indica ai server di posta destinatari di normalizzare gli spazi bianchi, gli spazi finali e la formattazione dei campi dell'intestazione prima di ricalcolare l'hash, evitando così falsi errori di verifica causati da lievi modifiche durante il trasporto.

4. Garantire l'allineamento delle coppie di chiavi durante le rotazioni

Quando si effettuano rotazioni delle chiavi DKIM, pubblicare sempre prima la nuova chiave pubblica nel DNS con un nuovo nome di selettore. Attendere dalle 24 alle 48 ore affinché la propagazione del DNS avvenga prima di configurare il server di posta per firmare i messaggi con la nuova chiave privata. Una volta completata la migrazione, lasciare il vecchio record della chiave pubblica nel DNS per diversi giorni, in modo che i messaggi in transito o in coda firmati con il vecchio selettore possano comunque essere verificati.

Si noti che abbiamo illustrato alcuni messaggi di errore DKIM più comuni e le loro probabili cause, fornendo al contempo una possibile soluzione. Tuttavia, potrebbero verificarsi errori dovuti a varie ragioni sottostanti specifiche del proprio dominio e dei propri server, che non sono state trattate in questo articolo. 

È necessario acquisire una conoscenza approfondita dei protocolli di autenticazione prima di implementarli nella propria organizzazione o di applicare le relative politiche. Un errore DKIM, un errore SPF o una convalida DMARC non riuscita possono influire sulla deliverability delle e-mail. 

Domande frequenti

Cosa significa “il body hash non è stato verificato”?

"Body hash non verificato" significa che la chiave pubblica è stata trovata nel DNS e che il formato dell'intestazione era valido, ma il contenuto del messaggio è stato modificato dopo la firma. Poiché il corpo del messaggio è stato modificato durante il transito (a causa di dichiarazioni di non responsabilità, gateway di sicurezza, ricodifica o inoltro), l'hash calcolato dal destinatario non corrispondeva all'hash originale registrato nel tag bh= della firma.

Come posso risolvere un errore DKIM?

Per risolvere un errore DKIM, individua la stringa di errore esatta nell’intestazione “Authentication-Results” della tua email. Se l’errore è dovuto alla mancanza di una chiave (nessuna chiave per la firma), pubblica o correggi il record TXT della chiave pubblica nel DNS sotto il selettore corretto. Se l’errore è una mancata corrispondenza dell’hash del corpo del messaggio (l’hash del corpo non è stato verificato), modifica il flusso di posta in modo che la firma DKIM avvenga come fase finale dopo l’aggiunta di tutti i piè di pagina e i link, e imposta la canonicalizzazione su relaxed/relaxed.

Cosa significa “violazione DKIM”?

Il termine “violazione DKIM” è utilizzato da alcuni gateway di sicurezza della posta elettronica per indicare che un’e-mail in arrivo non ha superato i controlli di convalida DKIM. Ciò implica solitamente che la firma crittografica non fosse valida, che il messaggio sia stato manomesso durante il transito oppure che il mittente abbia tentato di firmare l’e-mail utilizzando un dominio non corrispondente all’indirizzo del mittente visibile.

Un errore DKIM significa che la mia e-mail non verrà recapitata?

Non necessariamente. Se il tuo dominio dispone di un record SPF valido che supera la verifica con un corretto allineamento DMARC, l’e-mail supererà comunque la verifica DMARC complessiva e, nella maggior parte dei casi, arriverà nella posta in arrivo. Tuttavia, affidarsi esclusivamente all’SPF rende vulnerabile la deliverability quando le e-mail vengono inoltrate. Inoltre, se il DMARC fallisce su entrambi i protocolli e la politica del tuo dominio è impostata su p=quarantine o p=reject, l’e-mail non conforme verrà recapitata nella cartella dello spam o respinta del tutto.

• Informazioni su
• Ultimi messaggi

Maitham Al Lawati

Esperto di sicurezza informatica, amministratore delegato di PowerDMARC

Maitham è un imprenditore tecnologico, esperto di sicurezza informatica, CEO e fondatore di PowerDMARC con oltre 15 anni di esperienza nel settore. Maitham ha conseguito un MBA presso l'Università di Manchester e varie certificazioni professionali, tra cui CISSP, CISM, CRISC e ISC2 CCSP.

Ultimi messaggi di Maitham Al Lawati (vedi tutti)

• Errore DKIM: cosa significa ogni errore e come risolverlo - 13 settembre 2026
• Metodi di autenticazione delle e-mail: come SPF, DKIM e DMARC proteggono il tuo dominio - 9 agosto 2026
• Che cos’è una politica DMARC? Nessuna, Quarantena e Rifiuto - 27 luglio 2026