Domande DMARC,
con risposte

DMARC (Domain-based Message Authentication, Reporting & Conformance) è un protocollo di autenticazione email che indica ai server di posta destinatari cosa fare quando i controlli SPF o DKIM falliscono. Impedisce agli aggressori di inviare email che sembrano provenire dal suo dominio, proteggendo il suo marchio e i destinatari da phishing e spoofing. DMARC è definito nella RFC 7489.

Sì. Se il suo dominio invia email - o anche se non ne invia - ha bisogno di DMARC. Senza di esso, chiunque può inviare email impersonando il suo dominio. Google e Yahoo ora richiedono almeno p=none per i domini che inviano oltre 5.000 messaggi al giorno. PCI DSS v4.0 richiede DMARC per i domini rivolti ai clienti. I domini che non inviano email dovrebbero pubblicare p=reject per prevenire l'impersonificazione.

Inizi assicurandosi che SPF e DKIM siano configurati per il suo dominio. Poi pubblichi un record DNS TXT su _dmarc.iltuodominio.com con p=none e un indirizzo di reportistica rua=. Monitori i rapporti aggregati per almeno 90 giorni, corregga l'autenticazione per tutti i mittenti legittimi, quindi passi progressivamente a p=quarantine e infine a p=reject. Utilizzi il nostro verificatore DMARC per validare il suo record.

La pubblicazione di un record DMARC in p=none richiede pochi minuti. Raggiungere l'applicazione completa in p=reject richiede generalmente da 9 a 18 mesi. Ogni fase (none, quarantine, reject) richiede un minimo di 90 giorni di monitoraggio per identificare tutte le fonti di invio legittime e correggere la loro autenticazione. Le organizzazioni con meno mittenti di terze parti possono procedere più velocemente.

Un record DMARC è un record DNS TXT pubblicato su _dmarc.iltuodominio.com. Un record tipico ha questo aspetto: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r. I tag v= e p= sono obbligatori; tutti gli altri sono facoltativi ma consigliati. Consulti la nostra pagina Che cos'è DMARC per una scomposizione completa di ogni tag.

SPF verifica che il server di invio sia autorizzato dal record DNS del dominio - controlla il mittente della busta (Return-Path). DKIM allega una firma crittografica per dimostrare che il messaggio non è stato alterato in transito. DMARC li collega: richiede che SPF o DKIM abbia successo E si allinei con il dominio visibile dell'intestazione From, quindi indica ai destinatari cosa fare quando l'autenticazione fallisce. Utilizzi il nostro verificatore SPF e la nostra ricerca DKIM per testare i suoi record.

No. Un dominio deve avere esattamente un record DMARC TXT su _dmarc.domain.com. Più record DMARC causano un errore PermError e i destinatari li ignorano tutti. Se deve inviare rapporti a più indirizzi, li elenchi separati da virgole nel tag rua=: rua=mailto:dmarc@example.com,mailto:reports@example.com.

L'allineamento DMARC significa che il dominio nell'intestazione visibile From deve corrispondere al dominio che ha superato SPF o DKIM. L'allineamento relaxed (predefinito) consente la corrispondenza di sottodominio - mail.example.com si allinea con example.com. L'allineamento strict richiede una corrispondenza esatta del dominio. L'allineamento impedisce agli aggressori di superare SPF con il proprio dominio mentre impersonano il suo nell'intestazione From.

La politica p=none istruisce i server destinatari a non intraprendere alcuna azione di applicazione sui messaggi che falliscono DMARC. I messaggi vengono recapitati normalmente indipendentemente dai risultati dell'autenticazione. Lo scopo è il monitoraggio: i destinatari continuano a inviare rapporti aggregati, offrendo al proprietario del dominio visibilità su tutte le fonti di invio. Inizi sempre con p=none prima di passare all'applicazione.

La politica p=quarantine istruisce i server destinatari a indirizzare i messaggi non conformi nella cartella spam o posta indesiderata. Il messaggio esiste ancora - i destinatari possono trovarlo - ma è contrassegnato come sospetto. Questo è il passaggio di applicazione intermedio tra p=none (monitoraggio) e p=reject (blocco completo). Consulti la nostra guida Politica DMARC per la progressione completa.

La politica p=reject istruisce i server destinatari a rifiutare i messaggi non conformi a livello SMTP. Il destinatario non vede mai il messaggio e il server di invio riceve un bounce. Questa è la protezione DMARC più forte e l'obiettivo finale per ogni dominio. Raggiungere p=reject richiede un monitoraggio approfondito attraverso le fasi p=none e p=quarantine in anticipo.

Il tag pct= controlla quale percentuale di messaggi non conformi riceve l'azione di applicazione. Con pct=25, solo il 25% dei messaggi non conformi viene messo in quarantena o rifiutato - il resto viene trattato come p=none. Ciò consente un'implementazione graduale dell'applicazione. Inizi con pct=10, aumenti a 25, 50, quindi 100 nell'arco di diverse settimane. Se pct= viene omesso, il valore predefinito è 100.

Un rapporto aggregato (RUA) è un file XML inviato quotidianamente dai server di posta destinatari, che riassume i risultati di autenticazione di tutti i messaggi che dichiarano di provenire dal suo dominio. Indica quali indirizzi IP hanno inviato email, se SPF e DKIM hanno avuto successo e quale politica è stata applicata. I rapporti aggregati sono il fondamento del monitoraggio DMARC - forniscono i dati necessari per prendere decisioni di applicazione. DMARC Report converte questi file XML in dashboard visive.

Un rapporto forense (RUF) fornisce dettagli di errore per singolo messaggio - l'email specifica che ha fallito l'autenticazione, l'IP del mittente, l'incoerenza From/Return-Path e quale meccanismo ha fallito. I rapporti forensi sono utili per indagare sui tentativi di spoofing attivi, ma sono meno comunemente supportati dai destinatari rispetto ai rapporti aggregati. Alcuni destinatari non inviano affatto rapporti RUF per motivi di privacy.

I rapporti aggregati DMARC grezzi sono file XML difficili da leggere manualmente. Utilizzi un analizzatore di rapporti DMARC come DMARC Report per convertire l'XML in dashboard visive che mostrano lo stato di autenticazione dei mittenti, i risultati di allineamento e le azioni della politica. Lo strumento classifica automaticamente i mittenti per fornitore (Google Workspace, Microsoft 365, SendGrid, ecc.) e mette in evidenza gli errori che richiedono attenzione.

Motivi comuni: il suo record DMARC non include un tag rua=, l'indirizzo email rua= contiene un errore di battitura, oppure non è stato inviato un volume di email sufficiente per attivare i rapporti (i destinatari raggruppano generalmente i rapporti quotidianamente). Se rua= punta a un dominio diverso da quello autenticato, ha bisogno di un record DNS di verifica esterna. Preveda da 24 a 72 ore dopo la pubblicazione del suo record DMARC affinché i rapporti inizino ad arrivare. Utilizzi il nostro verificatore DMARC per validare la sintassi del suo record.

La maggior parte dei destinatari invia rapporti aggregati una volta ogni 24 ore, generalmente a mezzanotte UTC. Alcuni grandi destinatari come Google e Microsoft possono inviare più rapporti al giorno. Il volume di rapporti che riceve dipende da quanti destinatari diversi elaborano le email del suo dominio. I domini popolari possono ricevere centinaia di rapporti al giorno da decine di destinatari.

Il percorso da p=none a p=reject richiede generalmente da 9 a 18 mesi. Ogni fase richiede un minimo di 90 giorni: p=none per il monitoraggio e l'identificazione dei mittenti, p=quarantine per l'applicazione intermedia e p=reject per la protezione completa. Le organizzazioni con meno mittenti di terze parti e un'infrastruttura email più semplice possono procedere più velocemente, ma affrettare l'applicazione porta al blocco di email legittime.

Se un mittente legittimo fallisce DMARC in p=quarantine, la sua email finisce nello spam. In p=reject, viene bloccata completamente. Per correggere questo: consulti i rapporti aggregati per identificare il mittente non conforme, configuri il suo include SPF o la firma DKIM e verifichi che l'allineamento abbia successo. L'utilizzo del tag pct= per implementare gradualmente l'applicazione aiuta a individuare questi problemi prima che coinvolgano tutte le email.

La quarantena offre una protezione significativa - i messaggi contraffatti lasciano la casella di posta. Tuttavia, p=reject è l'obiettivo consigliato perché impedisce completamente il recapito. Alcuni framework di conformità (PCI DSS v4.0, CISA BOD 18-01 per le agenzie federali) richiedono specificamente p=reject. Inoltre, p=reject è necessario per qualificarsi per BIMI, che mostra il logo del suo marchio nei client di posta compatibili.

Sì. L'inoltro tradizionale delle email può interrompere l'allineamento SPF perché l'IP del server di inoltro non è nel record SPF del dominio originale. DKIM sopravvive generalmente all'inoltro perché la firma è allegata al messaggio stesso. Ecco perché l'allineamento DKIM è particolarmente importante per i domini i cui destinatari inoltrano email. ARC (Authenticated Received Chain) è un protocollo più recente progettato per risolvere questo problema, ma la sua adozione è ancora in crescita.

DMARC è richiesto da un numero crescente di standard e organizzazioni. Google e Yahoo richiedono almeno p=none per i mittenti di massa (oltre 5.000 messaggi/giorno). PCI DSS v4.0 richiede DMARC per i domini utilizzati nelle comunicazioni con i clienti (in vigore da marzo 2025). CISA BOD 18-01 impone p=reject per le agenzie federali statunitensi. Molte polizze di cyber-assicurazione e processi di approvvigionamento ora richiedono l'applicazione di DMARC.

Da febbraio 2024, Google e Yahoo richiedono a tutti i mittenti di massa (oltre 5.000 messaggi/giorno verso utenti Gmail/Yahoo) una politica DMARC di almeno p=none con un indirizzo rua= valido. Inoltre, i mittenti devono avere record SPF e DKIM configurati correttamente, includere intestazioni di disiscrizione con un clic nelle email di marketing e mantenere un tasso di reclami per spam inferiore allo 0,3%. I mittenti non conformi subiscono un rallentamento del recapito e rifiuti.

Sì. PCI DSS v4.0 (in vigore da marzo 2025) richiede alle organizzazioni che elaborano dati dei titolari di carte di implementare DMARC sui domini utilizzati nelle comunicazioni rivolte ai clienti. In particolare, il Requisito 5.4.1 stabilisce che i meccanismi anti-phishing devono includere l'autenticazione basata sul dominio (DMARC, SPF, DKIM). La maggior parte dei valutatori PCI si aspetta p=reject o p=quarantine per la conformità.

La Binding Operational Directive 18-01, emessa dalla Cybersecurity and Infrastructure Security Agency (CISA), richiede a tutte le agenzie del ramo esecutivo federale statunitense di implementare DMARC in p=reject. Questa direttiva ha aumentato notevolmente l'adozione di DMARC nel settore governativo ed è spesso citata come riferimento di buona pratica da altre organizzazioni e settori.

DMARC supporta la conformità HIPAA impedendo lo spoofing dei nomi di dominio del settore sanitario, riducendo il rischio di attacchi di phishing che potrebbero portare all'esposizione di Informazioni Sanitarie Protette (PHI). Sebbene HIPAA non nomini esplicitamente DMARC, la Security Rule richiede misure di protezione per le PHI elettroniche, e l'autenticazione email è considerata una misura ragionevole e appropriata. Noti che i rapporti forensi (RUF) possono contenere il contenuto dei messaggi, quindi le organizzazioni sanitarie dovrebbero utilizzare solo i rapporti aggregati (RUA) o assicurarsi che i rapporti forensi siano gestiti in conformità con HIPAA.