Come configurare DMARC: guida completa alla configurazione passo dopo passo (2026)

I provider di posta elettronica non considerano più la configurazione del DMARC una misura di sicurezza “facoltativa”. Con Gmail, Yahoo e Microsoft che applicano requisiti di autenticazione più rigorosi, le organizzazioni che non hanno implementato il DMARC rischiano il rifiuto permanente dei messaggi, un aumento degli attacchi di spoofing e problemi di conformità.

In questa guida imparerai come configurare DMARC partendo da zero, verificare la correttezza delle configurazioni SPF e DKIM, pubblicare un record DMARC conforme e passare gradualmente dalla modalità di monitoraggio all’applicazione completa delle regole. Tratteremo inoltre gli ultimi aggiornamenti della RFC 9989, gli errori di configurazione più comuni e alcuni consigli pratici per la risoluzione dei problemi, per aiutarti a implementare DMARC in tutta sicurezza.

Al termine di questa guida alla configurazione di DMARC, avrai a disposizione una tabella di marcia chiara per proteggere il tuo dominio dagli attacchi di spoofing, garantendo al contempo che le e-mail legittime continuino a raggiungere la casella di posta in arrivo.

Conformità 2026: l'applicazione delle norme è già in vigore

Gmail e Yahoo (novembre 2025): è entrata in vigore l'applicazione definitiva del rifiuto 5xx per i mittenti che inviano messaggi in massa (oltre 5.000 e-mail al giorno). I messaggi non conformi vengono respinti in modo definitivo, non solo filtrati.

Microsoft Outlook (maggio 2025): applicazione delle politiche SPF, DKIM e DMARC attiva. I messaggi non conformi saranno soggetti a rinvio o rifiuto.

PCI DSS v4.0 (marzo 2025): controlli anti-phishing obbligatori per tutti i soggetti che trattano dati relativi alle carte di pagamento.

• CISA BOD 18-01: Tutte le agenzie federali statunitensi devono implementare DMARC con la politica p=reject.
• Per i requisiti completi, consultare: Requisiti DMARC globali e regionali

Che cos’è il DMARC e come funziona?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) è un protocollo di autenticazione della posta elettronica che consente ai proprietari dei domini di indicare ai server di posta destinatari come gestire i messaggi che non superano i controlli di autenticazione SPF e DKIM. In parole povere, impedisce a terzi di falsificare il proprio dominio e indica ai destinatari come gestire gli impostori.

DMARC si basa su due protocolli esistenti, SPF e DKIM. Insieme, questi tre protocolli costituiscono le fondamenta della moderna sicurezza della posta elettronica.

DMARC, SPF e DKIM: come funzionano insieme

L'SPF (Sender Policy Framework) autorizza i server di posta che sono autorizzati a inviare e-mail dal proprio dominio. Si tratta di un record DNS che specifica: «Solo questi indirizzi IP possono inviare e-mail che dichiarano di provenire da example.com».

Il protocollo DKIM (DomainKeys Identified Mail) applica una firma crittografica alle tue e-mail. Ciò dimostra che il messaggio proviene da te e non è stato modificato durante il trasferimento. La firma viene verificata tramite una chiave pubblica pubblicata nel tuo DNS.

DMARC li mette in relazione tra loro. In sostanza dice: «Ecco la mia politica. Se un’e-mail dichiara di provenire dal mio dominio, deve superare la verifica di allineamento SPF o DKIM. Se non la supera, ecco cosa voglio che facciate: nessuna azione (solo monitoraggio), quarantena (inviare nella cartella spam) o rifiuto (bloccare completamente)».

Scopri di più su DMARC, SPF e DKIM nella nostra guida completa.

Cosa succede quando un'e-mail non supera il controllo DMARC?

Quando un destinatario riceve un'e-mail che dichiara di provenire dal tuo dominio, la verifica in base alla tua politica DMARC. Il risultato dipende dalla tua politica:

• p=none (monitoraggio): l'e-mail viene inviata indipendentemente dal risultato. Si riceve un rapporto che indica quali operazioni sono andate a buon fine e quali hanno dato esito negativo.
• p=quarantena: le e-mail non valide vengono inviate alla cartella spam/posta indesiderata. Le e-mail legittime continuano ad arrivare.
• p=reject: le e-mail non valide vengono respinte immediatamente. Il mittente riceve un messaggio di errore.

Prima di configurare DMARC: prerequisiti e inventario dei mittenti

Molte organizzazioni si affrettano a implementare il DMARC e passano rapidamente alla politica "p=reject", solo per scoprire che vengono bloccati mittenti legittimi (CRM, ESP, helpdesk, piattaforme di automazione del marketing). Questa sezione illustra il processo di verifica necessario per evitare questo errore che comporta costi elevati.

Passaggio 1: Verifica che il record SPF sia pubblicato per il tuo dominio

Affinché DMARC funzioni, il tuo dominio deve disporre di un record SPF valido nel DNS.

1. Utilizza il nostro SPF Checker per verificare che il tuo record SPF esista.

2. Verifica che per il tuo dominio esista esattamente un solo record TXT SPF. La presenza di due record SPF rende l'SPF inefficace, poiché i destinatari ignoreranno entrambi.

3. Il record dovrebbe essere simile al seguente: v=spf1 include:sendgrid.net include:mailchimp.com ~all

Se il record SPF non è stato pubblicato o se sono presenti due record in conflitto, risolvi il problema prima di procedere. Utilizza il nostro strumento gratuito per creare subito il tuo record SPF.

Fase 2: Verifica il limite di ricerca SPF 10

SPF consente un massimo di 10 ricerche DNS per ogni valutazione del messaggio. Ogni mittente di terze parti che autorizzi (tramite include:) consuma da 1 a 3 di queste ricerche. Il superamento del limite comporta il fallimento della verifica SPF per alcuni mittenti.

1. Utilizza il nostro SPF Checker per verificare il numero di ricerche relative al tuo record SPF

2. Conta le ricerche DNS necessarie. Se ti avvicini o superi il numero di 10, verrà visualizzato un errore.

3. Se si supera il limite, ottimizzare il record per raggruppare le ricerche sostituendo le istruzioni `include:` con indirizzi IP espliciti. Si tratta di un ostacolo comune per le grandi organizzazioni con molti mittenti di terze parti.

Fase 3: Verificare che DKIM sia configurato per tutti i mittenti

DKIM è richiesto da Google, Yahoo e Microsoft per i mittenti che effettuano invii in massa; non è facoltativo.

1. Per il tuo dominio principale: utilizza il nostro DKIM Checker gratuito per verificare che il tuo record DKIM sia stato pubblicato.

2. Per ogni mittente di terze parti (Salesforce, HubSpot, Klaviyo, ecc.): verificare che abbia abilitato la firma DKIM e pubblicato la propria chiave pubblica come record DNS. In genere, ciò richiede di chiedere al fornitore di “abilitare il DKIM personalizzato per il proprio dominio”.

3. Ogni mittente dovrebbe disporre di un selettore DKIM univoco (ad esempio, k1._domainkey.example.com, sendgrid._domainkey.example.com).

Se DKIM non è presente, configuralo subito prima di passare all'applicazione di DMARC. Utilizza il nostro strumento gratuito per generare un record DKIM per il tuo dominio.

Fase 4: Inventario di tutti i mittenti di e-mail di terze parti

Crea un elenco di tutti i servizi che inviano e-mail dal tuo dominio:

• ESP (SendGrid, Mailchimp, Klaviyo, ecc.)
• CRM (Salesforce, HubSpot, Pipedrive, ecc.)
• Sistemi di assistenza e supporto (Zendesk, Freshdesk, ecc.)
• Automazione del marketing (Marketo, Pardot, ActiveCampaign, ecc.)
• Piattaforme di posta elettronica transazionale (Auth0, Stripe, AWS SES, ecc.)
• Server o applicazioni interne che inviano notifiche
• Servizi di inoltro o gestori di mailing list

Per ogni mittente, verificare:

1. Superano il controllo di allineamento SPF (incluso nel tuo record SPF)
2. Superano il controllo di allineamento DKIM (firma DKIM abilitata per il tuo dominio)
3. Sono configurati per utilizzare il tuo dominio nell'intestazione "Da:"

Utilizza il nostro strumento di analisi dei report DMARC per individuare i mittenti non autorizzati.

Passaggio 5: Verificare se esiste già un record DMARC

Utilizza il nostro strumento di verifica DMARC per verificare se il tuo dominio dispone già di un record DMARC.

• Se viene visualizzato "p=none": il tuo dominio è in modalità di monitoraggio. Questa guida ti aiuta a passare in modo sicuro alla modalità di applicazione.
• Se noti tag obsoleti (pct=, rf=, ri=): questi non fanno più parte dello standard RFC 9989 e dovrebbero essere rimossi alla prossima modifica del record.
• Se non è stato trovato alcun record: si ricomincia da zero. Passare alla sezione successiva.

Come configurare DMARC: guida passo dopo passo

Passaggio 1: Generare un record DMARC

Utilizza il nostro strumento DMARC Generator per creare il tuo record iniziale.

Campi obbligatori:

• Dominio: il tuo dominio (ad es., example.com)
• Politica: iniziare con p=none (modalità di monitoraggio, nessuna applicazione)
• Indirizzo di destinazione dei report: indirizzo e-mail al quale desideri ricevere i report aggregati (ad es., [email protected])

Aggiunte consigliate:

• np=reject: protegge i sottodomini inesistenti dallo spoofing (novità introdotta nella RFC 9989, costo zero)
• Indirizzo RU: Destinazione del report aggregato (fondamentale per il monitoraggio)

Esempio di record iniziale:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Questo record indica ai destinatari: “Monitorate le e-mail provenienti dal mio dominio e inviatemi rapporti giornalieri, ma per il momento non bloccate nulla”.

Fase 2: Comprendere il proprio record DMARC prima della pubblicazione

Un record DMARC è una stringa composta da coppie tag-valore separate da punti e virgola. Sono obbligatori solo v= e p=; tutto il resto è facoltativo, ma consigliato. Prima di pubblicarlo, è importante comprendere la funzione di ciascun tag:

Tag richiesti

Tag	Descrizione e regole
v= (versione)	• Valore: Sempre v=DMARC1 • Deve essere il primo tag del record • Esiste un solo valore valido
p = (politica)	• Valori: none, quarantine, oppure reject • Indica ai destinatari come gestire le e-mail che non superano i controlli DMARC • Per le differenze, consultare la tabella delle condizioni riportata di seguito

Tag facoltativi

np= (politica sui sottodomini inesistente)

• Valori: nessuno, quarantena o rifiuto
• Applica una politica ai sottodomini che non dispongono di un record DMARC
• Protegge dallo spoofing di sottodomini casuali (ad es., random123.example.com)
• Raccomandazione: impostare np=reject per tutti i domini. Non comporta alcun costo e colma una lacuna in materia di spoofing.

rua= (indirizzo di riferimento per i rapporti aggregati)

• Formato: rua=mailto:[email protected]
• È possibile inserire più indirizzi separati da virgole: rua=mailto:[email protected],mailto:[email protected]
• I report aggregati sono riepiloghi in formato XML inviati quotidianamente dai destinatari
• Questo è fondamentale per il monitoraggio. Senza di esso, non si ha alcuna visibilità sul flusso di posta.

sp= (politica del sottodominio)

• Valori: nessuno, quarantena o rifiuto
• Applica una politica ai sottodomini che dispongono di un record DMARC
• Se non specificato, si ricorre alla politica principale (p=)
• Da utilizzare quando si desidera applicare regole più rigide ai sottodomini (ad es., mail.example.com)

fo= (opzioni di segnalazione dei guasti)

• Valori: 0 (impostazione predefinita), 1, d, s o combinazioni (0:1:d:s)
• Determina quando vengono inviati i rapporti forensi (di errore)
• fo=0: Generare i report solo se tutti i meccanismi di autenticazione falliscono
• fo=1: Genera report in caso di errore di qualsiasi meccanismo di autenticazione (messaggi più dettagliati, utile nella fase di configurazione)
• Viene solitamente utilizzato con il tag ruf= (vedi sotto)
• Raccomandazione: utilizzare fo=1 durante la configurazione iniziale per rilevare tutti gli errori; passare a fo=0 una volta che si è sicuri dell'allineamento

adkim= (modalità di allineamento DKIM)

• Valori: r (rilassato, predefinito) o s (rigoroso)
• Condizione di rilassamento: il dominio e il dominio con firma DKIM condividono lo stesso dominio organizzativo (ad esempio, mail.example.com e example.com coincidono)
• Rigoroso: i domini devono corrispondere esattamente
• Raccomandazione: iniziare con adkim=r (modalità "relaxed"). Passare alla modalità "strict" solo dopo aver assunto il controllo di tutte le fonti di firma.

aspf= (modalità di allineamento SPF)

• Valori: r (rilassato, predefinito) o s (rigoroso)
• Caso semplice: il dominio e il dominio del Return-Path dell'SPF condividono lo stesso dominio organizzativo
• Rigoroso: i domini devono corrispondere esattamente
• Raccomandazione: iniziare con aspf=r. Passare alla modalità "strict" solo dopo aver assunto il controllo di tutte le fonti di invio.

t= (modalità di prova)

• Valori: y (modalità di prova attiva) oppure omesso (modalità di prova disattivata)
• Se impostato su t=y, indica ai ricevitori di applicare la tua politica al livello immediatamente inferiore
• p = quarantena; t = y si comporta come se p = nessuna per i destinatari
• p=rifiuto; t=sì si comporta come p=quarantena per i destinatari
• Questo è il sostituto del tag pct=, ormai obsoleto
• Da utilizzare quando si passa a una politica più rigorosa: pubblicare con t=y, monitorare i rapporti, quindi rimuovere t=y per far rispettare la politica

ruf= (indirizzo del rapporto forense)

• Formato: ruf=mailto:[email protected]
• Invia copie in tempo reale dei messaggi che non superano l'autenticazione
• Nota importante: Google, Microsoft e Yahoo non inviano più rapporti forensi (ai sensi della RFC 9989). È possibile includere questo tag in tutta sicurezza, ma non genererà rapporti da parte dei principali destinatari.
• Da includere solo se si dispone di un sistema automatizzato per l'elaborazione dei rapporti forensi

Tag obsoleti e rimossi (RFC 9989)

Questi tag facevano parte della RFC 7489, ma non sono più inclusi nello standard. Non aggiungerli ai nuovi record. Se compaiono nei record esistenti, rimuovili alla prossima modifica del DNS.

pct=

• Veniva utilizzato per applicare una politica a una percentuale dei messaggi non riusciti
• Ha prodotto risultati non uniformi tra i vari ricevitori
• Sostituzione: utilizzare invece t=y per l'implementazione graduale
• Se è ancora presente nei vecchi record, verrà ignorato dai destinatari conformi alla RFC 9989

rf=

• Il tag relativo al formato del rapporto di errore (che ha sempre e solo assunto un unico valore: afrf)
• Rimosso perché la reportistica moderna utilizza un meccanismo diverso

ri=

• Era il tag dell'intervallo di report
• Rimosso poiché gli intervalli di segnalazione sono ora standardizzati

Passaggio 2: Accedi al tuo provider DNS

Accedi alla tua console di gestione DNS (GoDaddy, Cloudflare, Namecheap, cPanel, Route 53, ecc.).

Fase 3: Aggiungere il record DMARC tramite il provider DNS

Trova l'opzione per aggiungere un nuovo record TXT, copia e incolla il valore dallo strumento, quindi clicca sull'icona Salva.

La procedura è la stessa per tutti i provider: aggiungi un nuovo record TXT, imposta il nome su _dmarc, incolla il tuo record come valore e salva. I percorsi di navigazione specifici per ciascun provider e le insidie più comuni per ciascuno di essi sono riportati nella tabella sottostante.

Fase 5: Attendere la propagazione del DNS

La propagazione delle modifiche al DNS a livello globale può richiedere fino a 48 ore, ma la maggior parte dei provider DNS effettua la propagazione entro 1-2 ore. Per monitorare la propagazione in tempo reale, puoi utilizzare il nostro strumento di verifica della propagazione DNS. Basta inserire il tuo dominio e cercare il record TXT _dmarc.

Passaggio 6: Verifica che la configurazione DMARC sia attiva

Una volta completata la propagazione del DNS, verifica il tuo record utilizzando il nostro strumento DMARC Checker.

1. Inserisci il nome del tuo dominio
2. Fai clic su "Cerca"
3. Dovresti vedere il tuo record visualizzato con tutti i tag analizzati
4. Se lo strumento di verifica mostra il messaggio “Record DMARC trovato” in relazione alla tua politica, significa che sei attivo

Se vengono visualizzati degli errori o se il record non viene trovato dopo 48 ore, controlla la voce DNS per verificare la presenza di errori di sintassi e di configurazione.

Configurazione di DMARC secondo la RFC 9989 – Cosa è cambiato nel 2026

Nel maggio 2026, l'IETF ha pubblicato l'RFC 9989, che sostituisce l'RFC 7489 come standard ufficiale DMARC. I record v=DMARC1 esistenti rimangono pienamente validi, pertanto non è necessaria alcuna migrazione urgente. Tuttavia, tre modifiche interessano chiunque configuri DMARC oggi.

Cosa comporta la RFC 9989 per la tua configurazione DMARC

1. pct= è ora deprecato

Il tag `pct=` veniva utilizzato per applicare una politica a una percentuale dei messaggi non riusciti. Produceva risultati incoerenti tra i diversi destinatari e non fa più parte dello standard.

Azione: rimuovere "pct=" da tutti i nuovi record. Se i record più vecchi lo contengono, rimuoverlo alla prossima modifica del DNS. I destinatari lo ignoreranno, ma crea confusione.

2. np= è nuovo

Il tag np= (politica sui sottodomini inesistenti) consente di proteggere i sottodomini che non esistono. Gli autori degli attacchi possono simulare sottodomini casuali (ad esempio, random123.example.com) per eludere i controlli DMARC. Impostando np=reject si colma questa lacuna senza alcun costo.

Azione: è facoltativa, ma puoi scegliere di aggiungerla a tutti i nuovi record.

3. t=y è il nuovo modo di attuare i cambiamenti politici

Il tag `t=y` indica ai ricevitori di applicare la politica un livello più in basso rispetto a quello dichiarato. Ciò consente di testare una politica più rigorosa prima di procedere alla sua applicazione definitiva.

• p = quarantena; t = y si comporta come se p = nessuna (i destinatari non mettono in quarantena; effettuano la consegna e inviano un rapporto)
• p=rifiuto; t=y si comporta come p=quarantena (i destinatari mettono in quarantena invece di rifiutare)

Azione: quando si passa da p=none a p=quarantine o p=reject, utilizzare prima t=y. Monitorare i rapporti per 1-2 settimane. Una volta acquisita la certezza, rimuovere t=y per applicare l'impostazione.

Come utilizzare t=y per un'implementazione graduale

Ecco il flusso di lavoro esatto:

1. Situazione attuale:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

2. Quando sei pronto a testare la quarantena, pubblica:

v=DMARC1; p=quarantena; t=sì; np=rifiuto; sp=quarantena; rua=mailto:[email protected]

I destinatari lo interpretano come p=nessuno, consegnano tutto e ne danno comunicazione. Si osserva la situazione per 1–2 settimane.

3. Verificare che nessuna e-mail legittima sia stata interessata dal problema, quindi rimuovere "t=y" per applicare la modifica:

v=DMARC1; p=quarantena; np=rifiuto; sp=quarantena; rua=mailto:[email protected]

4. Ora i messaggi indesiderati finiscono nella cartella dello spam, mentre quelli legittimi non subiscono alcuna modifica.

5. Quando sei pronto a testare la politica di rifiuto, pubblica:

v=DMARC1; p=reject; t=y; np=reject; sp=reject; rua=mailto:[email protected]

6. I destinatari considerano questa situazione come una quarantena. È necessario osservare la situazione per 1–2 settimane.

7. Esecuzione finale: Rimuovere t=y:

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

8. Il rifiuto totale è ora attivo.

Se in una qualsiasi fase si verifica un errore: rimuovere t=y, tornare indietro di un livello di policy, correggere il mittente che ha generato l'errore, quindi procedere nuovamente.

Come migliorare in modo sicuro la propria politica DMARC

La maggior parte degli errori DMARC si verifica perché le organizzazioni passano direttamente al parametro `p=reject` senza prima verificare il proprio flusso di posta. La posta legittima viene bloccata, gli utenti si lamentano e il proprietario del dominio, preso dal panico, torna indietro. Questa sezione illustra l'approccio corretto: un'implementazione in tre fasi che utilizza report aggregati per rafforzare la fiducia prima di ogni passo.

Nota: la RFC 9989 stabilisce esplicitamente che i destinatari devono trattare "p=reject" come "p=quarantine" nei flussi di posta indiretti (inoltro, mailing list). Per i domini i cui utenti partecipano a mailing list, "p=quarantine" rappresenta la politica di applicazione permanente più sicura. Per i domini puramente transazionali o dedicati esclusivamente al marketing, privi di caselle di posta degli utenti, è appropriato utilizzare "p=reject".

Fase 1: Monitoraggio (p = nessuno)

Durata: minimo 2-4 settimane. Più lunga in caso di ambienti di invio complessi (10 o più mittenti di terze parti).

Ecco come si presenta il tuo record:

v=DMARC1; p=none; np=reject; rua=mailto:[email protected]

Cosa fare:

1. Pubblicare il documento sopra riportato

2. Attendere che i destinatari inviino i rapporti aggregati (in genere l'invio inizia entro 24–48 ore)

3. Utilizza il nostro strumento di analisi dei report DMARC per esaminare i report giornalieri

4. Cerca:

• Tutte le fonti di invio note che compaiono nei rapporti
• Tassi di superamento dei controlli SPF e DKIM per ciascun mittente
• Eventuali mittenti sconosciuti che non riconosci
• Stato dell'allineamento (i tuoi mittenti superano o falliscono l'allineamento?)

Quando avanzare:

• Tutti i mittenti legittimi superano i controlli SPF o DKIM
• Nessuna fonte sconosciuta nei rapporti
• Hai raccolto dati coerenti per almeno 2 settimane
• Hai risolto i problemi relativi ai mittenti non funzionanti

Se non hai familiarità con i report DMARC, consulta la nostra guida su come leggere i report DMARC per una spiegazione semplice e chiara.

Fase 2: Quarantena (p = quarantena)

Durata: 1-2 settimane in modalità t=y (modalità di prova), poi a tempo indeterminato.

Fase A: Prova con t=y (simulazione)

Pubblica:

v=DMARC1; p=quarantena; t=sì; np=rifiuto; sp=quarantena; rua=mailto:[email protected]

Con t=y, i destinatari applicano la politica al livello immediatamente inferiore: la quarantena si comporta come se non fosse attiva. I messaggi non consegnati vengono comunque recapitati; si ricevono semplicemente dei rapporti che indicano quali messaggi sarebbero stati messi in quarantena.

Tieni sotto controllo la situazione per 1–2 settimane. Controlla i rapporti e verifica la tua casella di posta. Verifica la presenza di:

• Continua ad arrivare posta legittima
• Rapporti sugli errori che indicano quali mittenti sarebbero interessati
• Tassi normali di segnalazioni di spam

Fase B: Applicare (rimuovere t=y)

Quando ti senti sicuro, rimuovi t=y:

v=DMARC1; p=quarantena; np=rifiuto; sp=quarantena; rua=mailto:[email protected]

Ora le e-mail indesiderate finiscono nella cartella dello spam. Le e-mail legittime continuano ad arrivare normalmente.

Monitoraggio continuo:

• Esaminare settimanalmente i rapporti aggregati
• Controllare la cartella dello spam per individuare eventuali messaggi legittimi
• Se i mittenti legittimi iniziano a dare errori: passare immediatamente a p=none, risolvere il problema di allineamento, quindi riprendere l'avanzamento

Nota sui requisiti per il BIMI: se desideri utilizzare il BIMI (Brand Indicators for Message Identification) per visualizzare il tuo logo in Gmail, devi impostare p=quarantine o p=reject. L'impostazione p=none non è valida. Ciò rende ancora più urgente l'adozione di questa politica. Ecco come abilitare il BIMI per il tuo dominio.

Fase 3: Rifiuto (p = rifiuto)

Durata: 1-2 settimane con t=y, poi a tempo indeterminato.

Fase A: Prova con t=y (simulazione)

Pubblica:

v=DMARC1; p=reject; t=y; np=reject; sp=reject; rua=mailto:[email protected]

Con t=y, i destinatari considerano il "reject" come una forma di quarantena. I messaggi non recapitati finiscono nella cartella dello spam, non vengono respinti immediatamente. Monitorare la situazione per 1-2 settimane.

Fase B: Applicare (rimuovere t=y)

v=DMARC1; p=reject; np=reject; sp=reject; rua=mailto:[email protected]

Ora i messaggi non recapitabili vengono respinti immediatamente. Il mittente riceve un messaggio di errore.

Raccomandazioni politiche:

• Se il tuo dominio dispone di caselle di posta di utenti che fanno parte di mailing list (NAR, MLS, liste associative, ecc.), imposta p=quarantine come politica di applicazione.
• Se il tuo dominio è esclusivamente transazionale (SaaS, pagamenti, fintech, e-mail di marketing senza caselle di posta degli utenti): usa p=reject.

Risoluzione dei problemi relativi alla configurazione di DMARC: problemi comuni e soluzioni

Problema 1: “Nessun record DMARC trovato” durante il controllo

Perché succede: la propagazione del DNS non è ancora terminata, oppure hai digitato il nome host in modo errato.

Come risolvere il problema:

1. Attendere 24-72 ore dopo la pubblicazione
2. Verifica attentamente che il nome host sia esattamente _dmarc (e non _dmarc.tuodominio.com come in alcuni strumenti; verifica con il tuo provider specifico)
3. Utilizza il nostro strumento di verifica della propagazione DNS per controllare lo stato della propagazione
4. Prova di nuovo il nostro strumento di verifica DMARC

Problema 2: SPF e DKIM non allineati

Perché succede: il dominio nell'intestazione "Da:" non corrisponde al dominio autenticato tramite SPF o DKIM.

Esempio di errore:

• Da: l'intestazione riporta [email protected]
• Il dominio autenticato SPF è mail.otherdomain.com
• Il dominio di firma DKIM è newsletter.anotherdomain.com
• Risultato: nessun allineamento. DMARC non supera il controllo.

Come risolvere il problema:

1. Inizia con un allineamento rilassato (adkim=r; aspf=r) nel tuo record. Ciò consente la corrispondenza dei sottodomini.

2. Utilizza il nostro DKIM Checker per verificare il dominio di firma di ciascun mittente

3. Utilizza il nostro SPF Checker per verificare l'inclusione di ogni mittente nell'SPF

4. Per ogni mittente che non supera il controllo, chiedere al fornitore di configurare il dominio. Ad esempio:

• “Si prega di abilitare la firma DKIM per il dominio example.com (non un sottodominio)”
• “Si prega di utilizzare example.com come dominio nel campo Return-Path/envelope-from”

5. Una volta che tutti i mittenti superano il controllo con l'allineamento "relaxed", è possibile passare a quello "strict" (adkim=s; aspf=s), se lo si desidera

Problema 3: Fallimento dell'autenticazione da parte di un mittente terzo

Perché succede: una piattaforma ESP, CRM o di marketing invia e-mail dal tuo dominio, ma non è configurata nel tuo record SPF e/o non ha DKIM abilitato.

Come risolvere il problema:

In caso di errori SPF:

1. Recuperare l'include SPF del mittente dalla sua documentazione (ad es., include:sendgrid.net)

2. Aggiungilo al tuo record SPF: v=spf1 include:sendgrid.net include:mailchimp.com ~all

3. Prova il nostro SPF Checker

In caso di errori DKIM:

1. Chiedi al fornitore di abilitare il DKIM personalizzato per il tuo dominio

2. Pubblica la chiave pubblica DKIM fornita (di solito nel formato: selector._domainkey.yourdomain.com)

3. Verifica con il nostro DKIM Checker

Problema 4: Record SPF multipli o SPF che superano il limite di 10 ricerche

1. Più di un record SPF: la presenza di due record TXT SPF sullo stesso dominio compromette completamente il funzionamento dell'SPF e i destinatari ignoreranno entrambi.

Come risolvere il problema: unisci i tuoi record SPF in uno solo, poiché è possibile avere un solo record TXT SPF per dominio.

Esempio:

• Vecchio record 1: v=spf1 include:sendgrid.net ~all
• Vecchio record 2: v=spf1 include:mailchimp.com ~all
• Nuovo record unificato: v=spf1 include:sendgrid.net include:mailchimp.com ~all

2. Più di 10 ricerche DNS: ogni "include:" può richiedere da 1 a 3 ricerche DNS. Se si superano le 10, la verifica SPF fallisce per alcuni mittenti.

Come risolvere il problema: utilizza il nostro SPF in hosting per ottimizzare dinamicamente il tuo record. In questo modo, le istruzioni "include:" vengono sostituite con indirizzi IP espliciti, riducendo così il numero di ricerche.

Esempio:

• Prima (oltre 10 ricerche): v=spf1 include:sendgrid.net include:mailchimp.com include:klaviyo.com include:hubspot.com ~all
• Dopo l'ottimizzazione: v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ip4:9.10.11.12 ~all

Problema n. 5: la posta legittima finisce nella cartella dello spam dopo essere stata messa in quarantena

Perché succede: sei passato alla fase p=quarantena prima di verificare che tutti i mittenti legittimi superassero l'autenticazione.

Come risolvere il problema:

1. Torna immediatamente a p=none
2. Esamina i tuoi report aggregati per individuare quale mittente non sta funzionando correttamente
3. Correggere l'autenticazione (allineamento SPF o DKIM)
4. Ripassare a p=quarantena, ma eseguire il test con t=y e monitorare la situazione per 1-2 settimane prima di applicare la misura

Problema 6: Errori di sintassi nei record DMARC

Perché succede: errore di battitura nel record, punti e virgola mancanti o tag non supportati

Come risolvere il problema:

1. Verifica con il nostro DMARC Checker, poiché ti segnalerà eventuali errori di sintassi
2. Utilizza il nostro generatore DMARC per ricreare il record invece di modificarlo manualmente
3. Copia il record generato e incollalo nel tuo provider DNS

Parole finali

Configurare correttamente il DMARC non è più facoltativo. L’applicazione del rifiuto permanente da parte di Gmail, i requisiti di Yahoo e Microsoft, le raccomandazioni della versione 4.0 dello standard PCI DSS e la direttiva CISA BOD 18-01 rendono il DMARC una necessità ai fini della conformità.

Il percorso più sicuro e affidabile consiste nell’procedere con calma, verificare costantemente e applicare le misure in modo responsabile. Tuttavia, se desideri una gestione DMARC più rapida e semplice, con elaborazione automatizzata dei report, monitoraggio della conformità e assistenza continua, prendi in considerazione una piattaforma DMARC in hosting come PowerDMARC, che si occupa della configurazione, del ridimensionamento e dell’applicazione delle misure, permettendoti di concentrarti sulla sicurezza. Inizia oggi stesso la tua prova gratuita o prenota una demo per proteggere subito il tuo dominio.

Domande frequenti

Quanto tempo richiede la configurazione di DMARC?

La configurazione iniziale dei record DNS richiede pochi minuti. La propagazione del DNS può richiedere fino a 72 ore (di solito 1-2 ore). L'applicazione completa (raggiungere lo stato "p=reject" con certezza) richiede in genere 4-8 settimane, a seconda del numero di fonti di invio e della rapidità con cui vengono risolti i problemi di allineamento.

La configurazione di DMARC influisce sulla deliverability delle e-mail?

Quando p=none, l'impatto sulla deliverability è pari a zero, poiché la modalità di monitoraggio non prevede alcuna applicazione delle regole. Quando p=quarantine o p=reject, sono interessati solo i messaggi non autenticati e non conformi. I messaggi correttamente autenticati non subiscono alcun impatto e spesso registrano una migliore deliverability. DMARC può migliorare il posizionamento nella posta in arrivo a lungo termine, consolidando la reputazione del dominio presso i provider di posta elettronica.

Come si configura DMARC per più domini?

Quando si configura DMARC per più domini, è importante ricordare che ogni dominio deve avere il proprio record TXT DMARC all'indirizzo _dmarc.[dominio].

Esempio:

• Dominio 1: record TXT di _dmarc.example.com
• Dominio 2: record TXT di _dmarc.example.org

Per le organizzazioni che gestiscono numerosi domini, una piattaforma DMARC in hosting consente di gestire tutti i record da un'unica dashboard, facilitando il ridimensionamento.

Che cos'è l'allineamento DMARC?

Per "allineamento" si intende che il dominio nell'intestazione From: deve corrispondere al dominio autenticato tramite SPF o DKIM. L'allineamento flessibile (impostazione predefinita, adkim=r; aspf=r) consente corrispondenze a livello di dominio organizzativo, mentre l'allineamento rigoroso (adkim=s; aspf=s) richiede corrispondenze esatte.

• 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)

• Come configurare DMARC: guida completa alla configurazione passo dopo passo (2026) - 20 giugno 2026
• Come leggere i report DMARC: una guida completa a RUA e RUF - 10 giugno 2026
• Che cos’è il DMARC? Definizione, funzionamento e importanza - 28 aprile 2026