Il DMARC (Domain-based Message Authentication, Reporting and Conformance) è uno standard di autenticazione che aiuta a proteggere il dominio utilizzato come mittente delle email da spoofing, phishing e altri utilizzi non autorizzati.
DMARC utilizza i controlli SPF e DKIM e verifica che il dominio autenticato sia allineato con quello che il destinatario vede nel campo From. Permette inoltre di indicare ai provider come gestire i messaggi che non superano questi controlli.
In questo articolo vediamo quali configurazioni verificare prima di attivare DMARC, come creare il record DNS e come scegliere la policy più adatta.
Prima di configurare il DMARC
DMARC utilizza i risultati di SPF e DKIM, che devono quindi essere correttamente configurati sui sistemi utilizzati per inviare email con il dominio.
In particolare:
- SPF permette di verificare che il server che ha inviato il messaggio sia autorizzato a utilizzare il dominio.
- DKIM permette di verificare, tramite una firma digitale, che il messaggio provenga da un sistema autorizzato e non sia stato alterato durante il trasferimento.
DMARC aggiunge un ulteriore controllo: verifica che almeno uno dei domini autenticati tramite SPF o DKIM sia allineato con il dominio visibile nel campo From.
Prima di configurare DMARC, assicurati quindi che SPF e DKIM siano correttamente configurati per i tuoi flussi di invio.
Come funziona l'allineamento DMARC
Consideriamo un'email inviata da:
newsletter@example.com
Il dominio utilizzato nel campo From è example.com. DMARC verifica che questo dominio sia allineato con quello utilizzato da SPF o DKIM.
Allineamento SPF
Per SPF, DMARC confronta il dominio nel campo From con quello utilizzato nel Return-Path, sul quale viene effettuato il controllo SPF.
Ad esempio:
From
newsletter@example.com
Return-Path
bounce@example.com
Se SPF è valido e i domini risultano allineati, il controllo SPF può essere utilizzato per superare DMARC.
Un controllo SPF può infatti essere valido senza essere necessariamente allineato ai fini DMARC.
In magnews, l'allineamento SPF non è soddisfatto di default, perché il Return-Path utilizzato per l'invio appartiene a un dominio tecnico di magnews.
Se vuoi ottenere anche l'allineamento SPF, puoi configurare un dominio mittente tecnico personalizzato, allineato al tuo dominio mittente e configurato secondo le indicazioni fornite dalla piattaforma.
Scopri come configurare un dominio mittente tecnico.
Allineamento DKIM
Per DKIM, DMARC confronta il dominio visibile nel campo From con quello indicato nella firma DKIM tramite il parametro d=.
Ad esempio:
From
newsletter@example.com
Firma DKIM
d=example.com
Se la firma DKIM è valida e il dominio è allineato, il controllo può essere utilizzato per superare DMARC.
In magnews puoi ottenere l'allineamento DKIM definendo il dominio utilizzato nel campo From come dominio mittente e configurando il record DKIM indicato dalla piattaforma.
Una volta completata la configurazione, magnews firma i messaggi utilizzando un dominio DKIM allineato con il dominio mittente.
SPF e DKIM devono essere entrambi allineati?
No. Per superare DMARC è sufficiente che almeno uno tra SPF e DKIM superi il controllo e sia correttamente allineato con il dominio visibile nel campo From.
È comunque consigliabile configurare correttamente entrambi i meccanismi di autenticazione.
Crea il record DMARC
DMARC viene pubblicato nel DNS attraverso un record di tipo TXT.
Se il dominio utilizzato come mittente è:
example.com
il record DMARC deve essere pubblicato sull'host:
_dmarc.example.com
Una configurazione di base è:
v=DMARC1; p=none
I due tag indicano:
-
v=DMARC1: identifica la versione del protocollo DMARC. -
p=none: definisce la policy da applicare ai messaggi che non superano DMARC.
Pubblica quindi il valore scelto nel DNS del dominio come record TXT sull'host _dmarc.
Per ogni dominio deve essere presente un solo record DMARC. Se esiste già, modifica quello esistente invece di crearne un secondo.
Scegli la policy DMARC
Il parametro p indica ai provider come gestire i messaggi che non superano DMARC.
Può assumere tre valori:
nonequarantinereject
Le tre policy corrispondono a livelli progressivamente maggiori di protezione.
Per una nuova configurazione è normalmente consigliabile partire da p=none e passare a policy più restrittive solo dopo aver verificato tutti i flussi di invio legittimi.
Parti da p=none
La configurazione iniziale consigliata è:
v=DMARC1; p=none
Con p=none i provider eseguono il controllo DMARC, ma non chiedi loro di mettere in quarantena o rifiutare i messaggi che non lo superano.
Puoi quindi iniziare a monitorare i flussi senza rischiare di bloccare immediatamente email legittime.
p=none rappresenta principalmente una fase di monitoraggio e non necessariamente la configurazione finale.
Monitora i flussi di invio
Prima di rendere la policy più restrittiva, identifica tutti i sistemi che utilizzano il dominio per inviare email.
Oltre a magnews potrebbero esserci, ad esempio:
- Server di posta aziendale.
- CRM.
- Piattaforme e-commerce.
- Sistemi transazionali.
- Sistemi di ticketing.
- Altre piattaforme di marketing.
- Applicazioni o servizi esterni.
Una policy restrittiva può avere un impatto anche sulle email legittime provenienti da sistemi non correttamente autenticati o allineati.
Per facilitare il monitoraggio puoi aggiungere al record il tag rua, indicando un indirizzo a cui i provider possono inviare i report aggregati DMARC.
Ad esempio:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
I report permettono di individuare:
- Le sorgenti che utilizzano il dominio per l'invio.
- Eventuali problemi di autenticazione SPF o DKIM.
- Problemi di allineamento DMARC.
- Possibili utilizzi non autorizzati del dominio.
I report sono generalmente forniti in formato XML e possono essere numerosi. Può quindi essere utile utilizzare un indirizzo dedicato oppure un servizio specifico per raccoglierli e analizzarli, come quello offerto da DMARC Advisor.
Passa a p=quarantine
Quando il monitoraggio mostra che i flussi legittimi sono correttamente autenticati e allineati, puoi valutare:
v=DMARC1; p=quarantine
Con questa policy chiedi ai provider di trattare come sospetti i messaggi che non superano DMARC.
A seconda del provider, questi messaggi possono ad esempio essere recapitati nella cartella Spam.
p=quarantine rappresenta quindi uno step intermedio tra la fase di monitoraggio e la policy più restrittiva.
Continua anche in questa fase a verificare che i flussi legittimi non presentino problemi.
Passa a p=reject
Dopo aver verificato che tutti i sistemi autorizzati a utilizzare il dominio siano correttamente autenticati e allineati, puoi valutare:
v=DMARC1; p=reject
Con p=reject chiedi ai provider destinatari di rifiutare i messaggi che non superano DMARC.
È la policy che offre il maggiore livello di protezione contro l'utilizzo non autorizzato del dominio.
Non esiste un numero di giorni prestabilito per passare da una policy all'altra: dipende dalla complessità dell'infrastruttura di invio e dai risultati del monitoraggio.
Altri tag DMARC
Oltre a v, p e rua, un record DMARC può includere altri tag per configurazioni più avanzate.
Tra i più utilizzati:
-
sp: definisce una policy specifica per i sottodomini. -
adkim: definisce la modalità di allineamento DKIM. -
aspf: definisce la modalità di allineamento SPF.
Con adkim e aspf è possibile scegliere tra allineamento relaxed e strict.
Non è normalmente necessario specificare questi tag in una configurazione di base. Prima di utilizzarli, valuta il loro impatto sui diversi flussi di invio.
Verifica il record DMARC
Dopo aver pubblicato il record, verifica che sia raggiungibile dal DNS e che la sintassi sia corretta.
Verifica il DMARC in magnews
Se hai già definito il dominio come dominio mittente in magnews, puoi controllare la presenza e la validità del record DMARC:
- Dal Controllo deliverability disponibile nelle comunicazioni.
- Dalla sezione dei domini mittente in Impostazioni > Brand Protection.
Se magnews rileva un problema, controlla il record pubblicato nel DNS e verifica la presenza di eventuali errori di configurazione.
Verifica il DMARC con un tool esterno
Puoi verificare il record anche con strumenti esterni che interrogano direttamente il DNS.
Ad esempio, DMARC Advisor mette a disposizione un DMARC Check gratuito con cui verificare:
- Se il record DMARC è presente.
- Se la sintassi è valida.
- Quale policy è pubblicata:
p=none,p=quarantineop=reject.
Se devi modificare la policy o aggiungere altri tag, aggiorna sempre il record TXT esistente invece di crearne un secondo.
Domande frequenti
Posso configurare direttamente p=reject?
Sì, ma è consigliabile farlo solo se hai già verificato tutti i sistemi che utilizzano il dominio per inviare email.
Con p=reject, un messaggio legittimo che non supera DMARC potrebbe essere rifiutato dal provider destinatario.
Per una nuova configurazione è quindi preferibile partire da p=none, monitorare i flussi e aumentare gradualmente il livello di protezione.
Quanto tempo devo rimanere su p=none?
Non esiste una durata valida per tutti.
Il passaggio alla policy successiva dipende dai risultati del monitoraggio e dalla complessità dell'infrastruttura di invio.
Prima di procedere dovresti avere una buona visibilità delle sorgenti che utilizzano il dominio e aver verificato che tutti i flussi legittimi siano correttamente autenticati.
p=none protegge il dominio?
Con p=none attivi DMARC e puoi monitorare l'utilizzo del dominio, ma non chiedi ai provider di mettere in quarantena o rifiutare i messaggi che non superano il controllo.
Per aumentare la protezione contro spoofing e altri utilizzi non autorizzati puoi quindi valutare, dopo la fase di monitoraggio, il passaggio a p=quarantine e successivamente a p=reject.
SPF e DKIM devono superare entrambi il controllo?
No. Per superare DMARC è sufficiente che almeno uno tra SPF e DKIM sia valido e correttamente allineato con il dominio presente nel campo From.
È comunque consigliabile configurare correttamente entrambi.
DMARC sostituisce SPF e DKIM?
No.
DMARC utilizza i risultati di SPF e DKIM e aggiunge il controllo sull'allineamento con il dominio mittente. SPF, DKIM e DMARC sono quindi meccanismi complementari.
Posso avere più record DMARC?
No. Per uno stesso dominio deve essere presente un solo record DMARC valido.
Se devi aggiungere nuovi tag o modificare la policy, aggiorna il record TXT esistente anziché crearne un secondo.
Il DMARC è obbligatorio per i bulk sender?
I principali provider di posta, tra cui Gmail, Yahoo e Microsoft, richiedono ai bulk sender di configurare DMARC tra i requisiti di autenticazione.
Per soddisfare il requisito è ammessa anche una policy p=none, ma il messaggio deve superare correttamente il controllo DMARC.
È quindi importante configurare DMARC anche quando non vuoi ancora applicare una policy quarantine o reject.
Il DMARC migliora direttamente la deliverability?
No. La presenza di DMARC non garantisce che un messaggio venga recapitato nella Posta in arrivo.
DMARC è però uno dei requisiti di autenticazione richiesti dai principali provider ai bulk sender e deve quindi essere correttamente configurato per gli invii ad alto volume.
Una corretta autenticazione permette inoltre ai provider di verificare meglio l'identità del mittente e contribuisce a proteggere il dominio da utilizzi non autorizzati.
La deliverability dipende anche da altri fattori, come la reputazione del mittente, la qualità dei contatti, l'engagement, la frequenza di invio e le segnalazioni spam.