I 6 errori DKIM e DMARC più comuni e come risolverli

SPF (Sender Policy Framework) è solo un pezzo del puzzle dell'autenticazione email. Puoi avere un record SPF perfetto e vedere comunque le tue email finire nello spam, essere rifiutate o non superare il controllo DMARC. Il motivo? DKIM (DomainKeys Identified Mail) e DMARC (Domain-based Message Authentication, Reporting, and Conformance) hanno proprie modalità di errore che mettono in difficoltà anche amministratori email esperti.

Vediamo segnalazioni continue su questo aspetto dalle organizzazioni che utilizzano Red Sift OnDMARC. Un team marketing configura lo SPF correttamente ma non abilita mai la firma DKIM. Un team IT pubblica un record DMARC con p=none e lo lascia invariato per un anno. Un mittente terzo firma le email con il proprio dominio invece che con il tuo, rompendo così l’allineamento. Non sono casi limite: sono la realtà quotidiana dell’autenticazione email nel 2026.

Con i nuovi requisiti di autenticazione email del 2026, SPF da solo non basta più a evitare problemi di recapito. Dove possibile, avere sia DKIM che SPF configurati è il modo migliore per ottenere tassi di consegna ottimali.

La tempistica nell’applicazione è urgente. Google e Yahoo hanno iniziato a richiedere SPF, DKIM e DMARC agli invianti massivi dal febbraio 2024 [1]. Microsoft ha seguito a maggio 2025, rifiutando le email non conformi con codice di errore 550 5.7.515 [2]. Non sono indicazioni blande: Gmail è passata da semplici avvisi educativi al rifiuto totale da novembre 2025, e Microsoft ha iniziato a respingere davvero le email invece di spostarle nello spam.

I numeri sull’adozione raccontano quanto la strada sia ancora lunga. Una ricerca su 5,5 milioni di domini ha rilevato che solo il 22,7% aveva un record DKIM rilevabile, rendendolo il protocollo di autenticazione email core meno diffuso [3]. E anche se l’adozione di DMARC cresce, il 69,6% dei domini manca ancora del record DMARC, e solo il 6% applica p=reject [3]. L’analisi di Red Sift su 73,3 milioni di domini mostra che solo il 2,5% ha attivato p=reject [4].

Nel frattempo, le perdite causate dal cybercrime continuano a salire. Il rapporto Internet Crime dell’FBI del 2025 segnala perdite totali per oltre $20,8 miliardi (+26% rispetto al 2024), con phishing e spoofing ancora in cima tra i crimini segnalati: 191.561 denunce [5]. Il business email compromise rappresenta oltre $3 miliardi di perdite su 24.768 incidenti [5]. Configurare correttamente SPF e DKIM abbinando l’applicazione DMARC piena è il modo per impedire agli attaccanti di impersonare il tuo dominio verso i clienti. Se DKIM è configurato su tutte le vere sorgenti mittenti, l’email forwarding non rompe l’autenticazione né causa problemi di recapito successivi.

Anche la pressione normativa è concreta. PCI DSS v4.0.1 impone DMARC a livello quarantine o reject per chi gestisce pagamenti [6]. CISA, NCSC UK, ASD Australia e CCCS Canada richiedono DMARC per i domini governativi. Per un riepilogo globale, vedi la nostra panoramica dei mandati DMARC internazionali. Anche le assicurazioni cyber lo richiedono sempre più spesso come condizione per la polizza.

Questi sono i sei errori DKIM e DMARC che vediamo più spesso e come risolverli.

Cosa si vede: I report DMARC o le intestazioni delle email mostrano dkim=fail (l’hash del corpo non corrisponde). La firma DKIM esiste, la chiave pubblica è su DNS, ma la verifica fallisce comunque.

Perché accade: DKIM funziona calcolando un hash del corpo dell’email al momento della firma (il tag bh= nell’header DKIM-Signature). Il server ricevente cerca la chiave pubblica associata al selettore usato per firmare e ricalcola l’hash. Se qualcosa cambia tra firma e recapito, gli hash non coincidono e DKIM fallisce.

I colpevoli tipici sono sistemi intermediari che modificano il messaggio dopo che il tuo server l’ha firmato:

• Email security gateway che riscrivono gli URL per il controllo dei link (Microsoft Defender, Barracuda e simili)
• Anti-spam che aggiungono o modificano header
• Software di mailing list che aggiunge footer, header di lista o link di disiscrizione, oppure riscrive il MailFrom SMTP e rimuove o sostituisce la firma DKIM originale
• Strumenti DLP (data loss prevention) che scansionano e a volte alterano i contenuti in uscita
• Inoltro automatico dove il server di forwarding modifica il corpo

Questa è una delle situazioni più difficili da diagnosticare perché la firma è valida: la chiave corrisponde, il selettore è giusto, il record DNS c’è. Il problema è che il corpo è cambiato dopo la firma.

Come risolvere:

Principio base: la firma DKIM deve avvenire come ultimo passo prima che il messaggio lasci la tua infrastruttura. Se qualcosa lo modifica dopo, la firma si rompe.

• Riordina il percorso della posta. Se hai un security gateway che riscrive gli URL, assicurati che la firma DKIM venga applicata dopo questa modifica, non prima. Spesso significa configurare il gateway per firmare per conto del tuo dominio invece di lasciar fare tutto al tuo mail server.
• Usa la canonicalizzazione c=relaxed/relaxed. DKIM supporta due modalità: simple e relaxed. Relaxed gestisce meglio piccole differenze negli spazi e nella formattazione. Imposta header e body entrambi in relaxed (c=relaxed/relaxed) per ridurre i falsi errori.
• Individua il sistema che modifica. Confronta l’hash DKIM originale (bh=) con quello calcolato al ricevimento: se sono diversi, qualcosa nell’inoltro ha alterato il corpo. Ripercorri il flusso dai mittenti ai gateway e filtri per trovare il responsabile.
• Per mailing list e forwarding, conta su DKIM \+ ARC. Le mailing list modificano sempre i messaggi: è il loro lavoro. Non si può evitarlo. ARC (Authenticated Received Chain) conserva i risultati autenticazione anche dopo i forward; Google e Microsoft lo valutano nelle decisioni di recapito. Tu, in uscita, assicurati che DKIM sia sempre abilitato così il recapito diretto supera i controlli. Usa Red Sift Investigate per verificare che i tuoi messaggi superino gli hash check ancora prima del forwarding. Per approfondire come il forwarding impatta l’autenticazione, leggi la nostra guida a SPF, DKIM e DMARC.

Cosa si vede: L’header mostra dkim=fail (nessuna chiave) o dkim=permerror. Il server ricevente non trova o non riesce a interpretare la chiave pubblica DKIM.

Perché accade: DKIM si basa su una chiave pubblica pubblicata in DNS in una posizione specifica: selector._domainkey.yourdomain.com. Se il destinatario non trova o legge questo record, la verifica fallisce sempre. È il problema DKIM più diffuso e nasce per vari motivi:

• Il record DNS non è mai stato creato. Qualcuno abilita la DKIM nel servizio email ma non aggiunge la relativa chiave pubblica su DNS. Google Workspace, ad esempio, obbliga a generare la chiave in Admin Console e poi copiarla come record TXT o CNAME in DNS. Se salti il passaggio DNS, la firma c’è ma la verifica fallirà sempre.
• Il record è nella zona DNS sbagliata. Se gestisci DNS su più servizi (registrar, Cloudflare, provider hosting), il record può essere stato inserito nella zona inattiva. Il server ricerca nel DNS autoritativo e non trova nulla.
• Chiavi 2048-bit troncate. Le chiavi pubbliche DKIM RSA da 2048 bit sono lunghe, spesso oltre il limite di 255 caratteri per singola stringa TXT su DNS. Se il tuo provider tronca la chiave senza suddividerla in più stringhe quotate, la verifica fallisce.
• Mismatch del selettore. Il tag s= nell’header DKIM-Signature indica quale selettore DNS usare. Se il selettore nel record non corrisponde, la ricerca non produce risultati. Succede spesso quando un ESP ruota i selettori e il nuovo non viene pubblicato.

Come risolvere:

Individua il selettore vedendo l’header DKIM-Signature in una tua email inviata (su Gmail, vai su “Visualizza originale”). Trova il tag s=: quello è il selettore. Poi, cerca il record DNS manualmente o usa il Domain Analyzer di Red Sift OnDMARC.

Inserisci dominio e selettore e vedrai il record DKIM completo e le eventuali anomalie.

dig TXT selector._domainkey.yourdomain.com +short

Se non ritorna niente, il record manca. Se ottieni una chiave parziale, è troncata.

• Se il record manca: Accedi alla console di amministrazione e copia la chiave pubblica dal setup DKIM. Inseriscila nella zona DNS attiva come record TXT su selector._domainkey.yourdomain.com.
• Se le chiavi sono troncate: Spezza la chiave in stringhe quotate da 255 caratteri nello stesso record TXT. La maggior parte dei provider moderni gestisce questa suddivisione automaticamente se usi il CNAME per DKIM.
• Se il selettore non corrisponde: Verifica che il nome selettore del servizio email corrisponda a quello in DNS. Se l’ESP lo ha cambiato, aggiorna il DNS.
• Dove possibile, usa DKIM via CNAME. Molti ESP offrono la delega CNAME: punti il selettore a loro, e saranno loro a ruotare chiavi e mantenere i record.

Cosa si vede: DKIM ha funzionato per mesi e poi improvvisamente fallisce. Gli header mostrano dkim=fail ma apparentemente non ci sono cambiamenti su DNS o configurazioni da parte tua.

Perché accade: Le chiavi DKIM non sono permanenti: vanno ruotate periodicamente per la sicurezza e quando la rotazione va male, l’autenticazione si rompe in silenzio.

Tre scenari frequenti:

• L’ESP ruota le chiavi a tua insaputa. Se usi DKIM su TXT DNS, l’ESP può cambiare in qualsiasi momento la sua chiave privata di firma. Se genera una nuova chiave privata e non aggiorni la pubblica su DNS, la verifica fallirà: nulla è cambiato dalla tua parte, ma le email non passano più.
• Chiavi da 1024 bit rifiutate o segnalate. NIST raccomanda almeno 2048 bit per DKIM RSA e ormai tutti seguono questa indicazione [7]. Alcuni destinatari segnalano o rifiutano firme da 1024 bit. Se DKIM è configurato da anni e non hai aggiornato, potresti incorrere in problemi.
• Scadenza tag x= attivata. Le firme DKIM possono avere il tag opzionale x= con la scadenza della firma. Se l’email viene ritardata (es. in coda SMTP) e arriva dopo la scadenza, la verifica fallisce anche se il resto è corretto.

Come risolvere:

• Passa alle chiavi da 2048 bit. Se stai ancora usando 1024 bit, passa a 2048. In Microsoft 365 usa il comando PowerShell Rotate-DkimSigningConfig per aumentare la lunghezza delle chiavi. In Google Workspace crea una nuova chiave da 2048 bit in Console Admin \> App \> Google Workspace \> Gmail \> Autentica email. La guida alla configurazione dei protocolli email spiega i dettagli di gestione delle chiavi DKIM.
• Usa DKIM via CNAME per non dover gestire rotazione. Se deleghi DKIM tramite CNAME all’ESP, sarà lui ad aggiornare le chiavi e tu non devi toccare il DNS. Red Sift OnDMARC semplifica ulteriormente, gestendo tutte le configurazioni DKIM in un’unica piattaforma.
• Ruota le chiavi a intervalli regolari. La best practice (M3AAWG) è ruotare ogni 6-12 mesi con chiavi da 2048 bit. Usa nomi di selettore che contengano la data (es. jan2026) per capire velocemente quando è stata creata la chiave.
• Evita o imposta tag x= generosi. Se usi il tag di scadenza, assicurati che sia ampio abbastanza da coprire eventuali ritardi. Molti preferiscono non impostare x= per evitare questo possibile fallimento.

Cosa si vede: La verifica DKIM va a buon fine (dkim=pass) ma DMARC fallisce. I report DMARC mostrano DKIM superato ma allineamento non riuscito.

Perché accade: Questo è il più frequente errore DKIM sui DMARC, soprattutto tra chi usa servizi di terze parti.

DMARC non controlla solo che DKIM superi il test, ma anche l’allineamento: il dominio del tag d= di DKIM deve coincidere (o essere sottodominio) del dominio From visibile. Se una piattaforma terza firma con il suo dominio, DKIM passa ma DMARC fallisce in allineamento.

Come succede concretamente:

• Usi SendGrid per l’email marketing da marketing@yourdomain.com.
• SendGrid firma l’email di default con d=sendgrid.net.
• Il server ricevente verifica DKIM: la firma è valida su SendGrid, quindi dkim=pass.
• Poi DMARC verifica l’allineamento: sendgrid.net corrisponde con yourdomain.com?
• No. Allineamento fallito. Se anche SPF non allinea (cosa frequente coi terzi), DMARC fallisce del tutto.

Succede con quasi tutti gli ESP, CRM e SaaS che inviano email: Mailchimp, HubSpot, Salesforce, Zendesk, Freshdesk, Intercom... tutti firmano col proprio dominio se non configuri DKIM personalizzato.

Come risolvere:

Per ogni servizio che invia con il tuo dominio, configura la firma DKIM personalizzata in modo che il tag d= usi il tuo dominio:

• La maggior parte degli ESP (Mailchimp, SendGrid, HubSpot, ecc.): Cerca "Autenticazione dominio" o "DKIM personalizzato" nelle impostazioni. Ti daranno record CNAME o TXT da aggiungere su DNS. Una volta configurato, firmano con d=yourdomain.com invece che col loro.
• Google Workspace: DKIM usa di default il tuo dominio, ma va abilitato manualmente in Admin Console e pubblicato il record sul DNS.
• Microsoft 365: La firma DKIM personalizzata si abilita dal portale Defender 365. Microsoft fornisce due CNAME di selettore per dominio.

Dopo aver configurato DKIM personalizzato per ogni mittente, verifica la modalità di allineamento DMARC. Sono due (definite dal tag adkim=):

• Relaxed (adkim=r): Il dominio firmante DKIM può essere un sottodominio di quello From: mail.yourdomain.com allinea con yourdomain.com. È il default e consigliato.
• Strict (adkim=s): Il dominio deve corrispondere esattamente. Usa solo per necessità specifiche di sicurezza.

Red Sift OnDMARC mostra quali mittenti superano DKIM come verifica ma falliscono in allineamento, mostrandoti esattamente quale mismatch d= crea il problema. Per approfondire le interazioni tra DKIM, SPF e DMARC, leggi la nostra guida di confronto.

Cosa si vede: Hai il record DMARC, ricevi i report, ma la policy è p=none. Le email spoofate col tuo dominio vengono recapitate normalmente. Il dominio è “DMARC-enabled” ma non protetto.

Perché accade: Restare a p=none è il fallimento DMARC più diffuso, e non è un errore tecnico ma operativo.

Le organizzazioni pubblicano DMARC a p=none per raccogliere report aggregati: perfetto come primo passo. Ma poi non si passa mai all’enforcement. I motivi sono ben noti: i report sono grezzi XML difficili da leggere, il team non è sicuro dei mittenti leciti, nessuno vuole rischiare di bloccare emai valide, il progetto perde priorità. Passano mesi o anni e il record DMARC resta p=none, senza ostacolare gli attaccanti.

I numeri sono eloquenti: su 5,5 milioni di domini esaminati, il 17,6% ha DMARC a p=none [3]. L’analisi Red Sift su 73,3 milioni di domini conferma che solo il 14,9% ha iniziato il percorso DMARC e solo il 2,5% arriva a p=reject [4]. Quindi quasi tutti i domini con DMARC sono solo in modalità monitoraggio.

p=none è uno strumento reportistico, non una misura di sicurezza: invita i server riceventi a consegnare tutto (autenticato o meno) e solo a inviarti i report. Gli attaccanti possono spoofare il tuo dominio e i messaggi arrivano senza ostacoli.

Come risolvere:

Il percorso da p=none a p=reject è lineare se hai gli strumenti giusti. Ecco l’approccio consigliato con Red Sift OnDMARC:

1. Identifica tutti i mittenti leciti. Usa i report aggregati DMARC per costruire l’elenco di tutti i servizi che inviano con il tuo dominio. OnDMARC lo fa automaticamente, categorizzando e mostrando lo stato di autenticazione di ogni sender.
2. Sistemi l’autenticazione di ciascun mittente. Configura SPF e DKIM per ogni sorgente legittima. Almeno uno (idealmente entrambi) deve superare l’allineamento per ogni sender.
3. Passa a p=quarantine. Quando tutti i mittenti sono autenticati, cambia la policy a quarantine. In questo modo le email che falliscono finiscono nello spam, non in inbox. Controlla per una settimana o due e intercetta eventuali mittenti mancanti.
4. Passa a p=reject. Dopo aver verificato che nessuna email lecita viene quarantinata, passa a reject così blocchi tutte le email DMARC-fail.
5. Usa il tag pct= per applicazione graduale. Se hai timore ad abilitare da subito reject, usa pct=25 per attivare la policy solo sul 25% delle email che falliscono. Aumenta gradualmente (50%, 75%, 100%) man mano che prendi sicurezza.

Con la piattaforma giusta, in genere si arriva a p=reject in 6-8 settimane. Senza, molti non ci arrivano mai. La guida step-by-step all’enforcement DMARC spiega il processo completo.

Cosa si vede: SPF e DKIM appaiono come pass negli header o nei report DMARC, ma DMARC fallisce comunque. Questo è uno degli errori più confondenti: sembra che funzioni tutto, invece qualcosa non va.

Perché accade: DMARC pretende l’allineamento, non solo il superamento delle verifiche. SPF e DKIM possono “passare” ma comunque fallire DMARC se i domini autenticati non corrispondono al From visibile.

Ci sono due controlli di allineamento indipendenti:

• Allineamento SPF: Il dominio presente in Return-Path (envelope-from) deve coincidere (o essere sottodominio) di From.
• Allineamento DKIM: Il dominio nel tag d= DKIM deve coincidere (o essere sottodominio) del dominio From.

DMARC passa se almeno uno dei due supera l’allineamento. Fallisce solo se li falliscono entrambi.

Ecco un esempio pratico.

• La tua azienda manda email ai clienti da support@yourdomain.com tramite Zendesk.
• Zendesk usa il suo dominio per Return-Path (@zendesk.com).
• SPF controlla il record Zendesk, trova l’IP mittente e passa SPF, ma il dominio è zendesk.com, non yourdomain.com.
• Allineamento fallito. Anche DKIM è firmato da d=zendesk.com. DKIM passa ma l’allineamento fallisce perché zendesk.com non corrisponde a yourdomain.com.
• Entrambi i protocolli superano la verifica ma falliscono l’allineamento. DMARC fallisce.

Succede praticamente con ogni mittente terzo non configurato correttamente in autenticazione custom.

Come risolvere:

Serve almeno che un protocollo superi sia la verifica che l’allineamento. Il modo più sicuro è sistemarli entrambi:

• Per l’allineamento DKIM: Configura la firma DKIM personalizzata su ogni mittente terzo, così che il d= sia il tuo dominio (vedi errore n. 4 sopra per i dettagli dei singoli provider).
• Per l’allineamento SPF: Configura ciascun mittente per usare il tuo dominio (o sottodominio) come Return-Path. Cambia secondo il provider: Salesforce richiede la disattivazione del bounce management, HubSpot e Marketo permettono il Return-Path custom.
• Usa il relaxed alignment come impostazione di default. Con aspf=r e adkim=r (default su DMARC), anche i sottodomini vengono considerati allineati. Se il Return-Path è bounce.yourdomain.com e il From è yourdomain.com, tutto passa con relaxed.

La verifica è semplice: controlla i report DMARC aggregati. Vedi sempre i risultati di autenticazione e allineamento per SPF e DKIM, così individui subito quale protocollo/sender sistemare.

Red Sift OnDMARC divide il tutto per mittente, mostrandoti subito quali servizi superano la verifica ma falliscono l’allineamento e dove c’è mismatch di dominio. Verifica lo stato attuale su Red Sift Investigate per vedere come sei messo con l’allineamento.

Quando analizzi i problemi, l’header Authentication-Results delle email ricevute ti racconta esattamente cos’è capitato. Ecco cosa cercare:

Per un monitoraggio continuo oltre ai singoli controlli sulle email, i report aggregati DMARC offrono una visione completa su tutte le fonti di invio. Red Sift OnDMARC trasforma i report XML grezzi in dashboard operative, e la nostra guida agli strumenti principali per l'autenticazione email illustra altre risorse utili per ogni fase dell'implementazione.

I fallimenti DKIM e DMARC seguono schemi prevedibili. Incongruenze dell'hash del corpo, record DNS mancanti, mancanza di rotazione delle chiavi, disallineamenti nell'allineamento, politiche bloccate e il divario tra superamento dell'autenticazione e superamento di DMARC. Ognuna di queste problematiche è diagnosticabile attraverso le intestazioni delle email e i report DMARC, e tutte sono risolvibili.

Il rischio maggiore non è la complessità. È l'inazione. Un record DMARC impostato a p=none offre visibilità ma nessuna protezione. Ogni giorno in cui il tuo dominio resta a p=none è un altro giorno in cui gli aggressori possono impersonarti senza conseguenze.

[1] Un aggiornamento sui requisiti per i mittenti massivi \- Google

[2] Rafforzare l'ecosistema email \- Microsoft Community Hub

[3] DKIM Fail: come correggere errori di allineamento e verifica \- DMARCguard

[4] SPF Flattening: il problema nascosto dell'infrastruttura email \- AutoSPF

[5] Rapporto Annuale IC3 2025

[6] PCI DSS v4.0.1 Sintesi delle modifiche

[7] RFC 6376 \- DomainKeys Identified Mail (DKIM) Signatures