Guida a DMARC: Una guida completa all’implementazione, alla configurazione e al monitoraggio

Nota sulla fonte e sull’accuratezza

Questa guida si basa principalmente sulle specifiche dei protocolli stessi: RFC 7489, RFC 7208, RFC 6376, RFC 8301, RFC 8463, RFC 8601, RFC 8617, RFC 8461, RFC 8460, RFC 7960, oltre a RFC 8553 e RFC 8616, che aggiornano o influenzano la RFC 7489 – integrando inoltre la documentazione operativa attuale di Microsoft, Google e Yahoo, e le informazioni attuali. DMARCbis partecipa al gruppo di lavoro DMARC dell’IETF. DMARC è un protocollo di consulenza sulle politiche: esprime la preferenza del proprietario del dominio, ma il sistema di ricezione delle e-mail decide cosa fare con un messaggio non valido. Il comportamento dei fornitori può cambiare, a volte senza preavviso. Gli esempi di DNS in questo articolo utilizzano nomi di placeholder di esempio riservati. Sostituisci ogni dominio di policy, dominio di report, selettore e record di autorizzazione per i report esterni con valori controllati dalla tua organizzazione o dal processore di report. Prima di applicare qualsiasi configurazione descritta qui a un dominio di produzione, validala tramite un test in ambiente di staging — tipicamente p=none con reportistica aggregata – e non pubblicare mai p=reject fino a quando i report aggregati non confermeranno che le vostre fonti di posta legittime sono coerenti.

Introduzione: perché SMTP consente la falsificazione

SMTP, originariamente definito nella RFC 821 (1982) e aggiornato nella RFC 5321, è stato progettato per una piccola rete di ricerca in cui tutti i partecipanti si fidano reciprocamente. Non effettua alcuna autenticazione del mittente a livello di protocollo. Un server di posta in entrata può presentare qualsiasi valore desiderato nel comando `MAIL FROM` e qualsiasi indirizzo desiderato nell’intestazione `From:`. L’MTA ricevente non dispone di un meccanismo integrato per verificarli.

In realtà, un’e-mail ha tre “identità” “da”, e confonderle è alla radice della maggior parte delle falsificazioni:

• Il mittente dell’e-mail (chiamato anche MAIL FROM, Return-Path o secondo la specifica RFC 5321, “MailFrom”). Questo è l’indirizzo utilizzato durante la transazione SMTP e dove vengono reindirizzate le e-mail non recapitate. Il destinatario di solito non lo vede mai.
• L’intestazione: Da (RFC 5322.Da). Questo è il campo visibile. From: la linea che i client di posta visualizzano all’utente.
• Il dominio per la firma DKIM (la d= tag all’interno dell’intestazione DKIM-Signature). Si tratta del dominio che ha firmato il messaggio, e potrebbe differire sia dagli indirizzi indicati sopra.

Un messaggio di phishing può mettere billing@bank.example.com visibile From: mentre si utilizza bounce@attacker.example.net come mittente dell’e-mail. SPF, nel processo di verifica MAIL FROM rilevante per DMARC, convalida il mittente dell’e-mail piuttosto che il nome visualizzato “From”. SPF può anche valutare HELO/EHLO, ma questo non è l’identità visibile all’utente. DKIM, da solo, convalida solo il dominio che ha firmato il messaggio. Nessuno dei due protegge l’identità che l’utente effettivamente vede nel proprio client di posta, a meno che l’identità autenticata corrisponda al dominio visualizzato “From” in base a DMARC.

DMARC è stato definito in RFC 7489 nel marzo 2015 con lo status informativo, pubblicato tramite il flusso di pubblicazione indipendente dell’RFC Editor, piuttosto che come output di un gruppo di lavoro IETF. DMARCbis è la revisione del protocollo DMARC del gruppo di lavoro IETF, una prima specifica del flusso IETF per DMARC, e non una “promozione” di un documento IETF esistente. DMARC collega i risultati di SPF e DKIM al dominio “From” visibile attraverso un concetto chiamato allineamento, e consente al proprietario del dominio di pubblicare una policy nel DNS che indica ai destinatari cosa fare quando nessuno dei meccanismi allineati ha successo. DMARC non è uno strato anti-phishing magico: non fa nulla per i domini simili, gli attacchi con caratteri simili o i messaggi inviati da account compromessi che autenticano normalmente, e non garantisce il posizionamento nella casella di posta. Ciò che DMARC fornisce è la validazione che l’uso del dominio “From” visibile è stato autorizzato per un messaggio di successo, oltre a un canale di feedback in modo che i proprietari di dominio possano vedere chi sta inviando email per loro conto. Non è una decisione che il contenuto del messaggio, l’intento del mittente o l’account della casella di posta siano affidabili.

Ruoli di SPF, DKIM e DMARC

I tre protocolli sono correlati ma indipendenti. Ognuno risponde a una domanda diversa.

SPF può valutare sia le identità HELO/EHLO che MAIL FROM. DMARC utilizza il risultato di SPF per l’identità MAIL FROM secondo la RFC5321. Se MAIL FROM è vuota, SPF definisce l’identità MAIL FROM verificata come derivata da HELO. postmaster@<helo-domain> identità; questo si riferisce al caso del messaggio di “bounce”, e non all’utilizzo separato di DMARC con risultati HELO arbitrari.

DKIM normalmente protegge le intestazioni firmate selezionate e l’hash del corpo, ma la copertura esatta dipende dalla firma. L’uso raro di DKIM l= L’etichetta “lunghezza del corpo” può essere utilizzata per identificare intenzionalmente solo la prima parte del corpo, pertanto, la formulazione più sicura da utilizzare è quella di ispezionare l’effettivo DKIM-Signature e la decisione del destinatario piuttosto che presumere che ogni byte di un messaggio ricevuto fosse stato firmato.

Un messaggio può superare SPF e comunque fallire DMARC. Se l’indirizzo del mittente è bounce.esp-mailer.example ma l’intestazione “From” visibile è noreply@example.com, SPF autentica l’identità errata dal punto di vista di DMARC. Lo stesso vale per DKIM: una firma con d=esp-mailer.example verifica in modo crittografico, ma il dominio di firma non corrisponde al dominio “From” visibile, quindi DKIM fallisce.

L’intestazione Authentication-Results, definita in RFC 8601, è lo strumento principale per la risoluzione dei problemi. I server di posta che eseguono l’autenticazione scrivono comunemente una di queste intestazioni nel messaggio recapitato, riassumendo i risultati di SPF, DKIM e DMARC e le identità utilizzate per calcolarli. Quando un messaggio viene considerato spam o viene rifiutato, questa intestazione è solitamente la fonte della risposta. Durante la risoluzione dei problemi, fidarsi solo dell’intestazione Authentication-Results aggiunta dal proprio MTA di confine o dal sistema di ricezione finale che si sta analizzando: le intestazioni “Authentication-Results” provenienti da hop upstream non attendibili possono essere false o obsolete, e RFC 8601 §5 descrive perché i sistemi di confine dovrebbero rimuovere o ignorare i campi “Authentication-Results” upstream non autenticati.

Come funziona DMARC passo dopo passo

In linguaggio semplice: il destinatario cerca il dominio “From” visibile nel DNS, trova una politica DMARC se esiste, verifica se SPF o DKIM hanno avuto successo in modo tale da collegarsi al dominio “From” visibile, e quindi applica la politica pubblicata se nessuno dei due meccanismi è riuscito.

La valutazione tecnica, secondo RFC 7489 §6, procede approssimativamente come segue:

1. Il destinatario estrae il dominio dall’intestazione “From” di RFC 5322.
2. Il destinatario interroga _dmarc.<domain> per un record TXT. Se non viene trovato, interroga lo stesso nome nel dominio organizzativo (derivato in RFC 7489 utilizzando la Public Suffix List). In DMARCbis, il fallback della PSL viene sostituito da una DNS Tree Walk limitata; il comportamento della PSL di RFC 7489 rimane la realtà implementata in molti destinatari fino alla pubblicazione e all’adozione di DMARCbis.
3. Il destinatario valuta SPF sull’indirizzo del mittente dell’enveloppe e registra il risultato.
4. Il destinatario valuta ogni firma DKIM nel messaggio e registra il risultato.
5. Il destinatario verifica la corrispondenza di SPF: il dominio del mittente nell’intestazione corrisponde al dominio “From”, in modalità aspf?
6. Il destinatario verifica la corrispondenza di DKIM: verifica se qualsiasi firma verificata corrisponda a d= il valore deve corrispondere al dominio “From”, in conformità con la politica. adkim modalità?
7. DMARC passa se SPF o DKIM, entrambi correttamente configurati, passano.
8. Se DMARC fallisce, il destinatario consulta la politica definita (p= o sp= per i sottodomini).
9. Il destinatario può applicare none, quarantine o reject, opzionalmente campionando con pct.
10. La politica locale sul destinatario (sistemi di reputazione, liste di approvazione, fiducia ARC, filtraggio dei contenuti) può sovrascrivere o integrare la gestione richiesta.

Il passaggio 10 è fondamentale e spesso viene frainteso. La policy DMARC è una richiesta, non un comando. Il destinatario può rispettarla, ignorarla, inviare comunque il messaggio nello spam o applicare ulteriori punteggi basati sull’apprendimento automatico. Microsoft 365, Google Workspace e i grandi provider di posta per privati applicano proprie policy locali oltre a DMARC. DMARCbis §5.4 rafforza questo approccio indicando che i destinatari di posta NON DOVREBBERO (SHOULD NOT) rifiutare messaggi in arrivo esclusivamente per la presenza di una policy p=reject pubblicata. I successivi paragrafi sulla gestione da parte del destinatario e sulla conformità impongono una regola più rigorosa: i destinatari di posta NON DEVONO (MUST NOT) rifiutare messaggi in arrivo esclusivamente per una policy p=reject pubblicata. In assenza di altre informazioni e analisi, ci si aspetta che trattino i messaggi che non superano la verifica come se si applicasse p=quarantine.

Allineamento rilassato vs. stretto

L’allineamento è ciò che distingue DMARC da SPF e DKIM. Esistono due modalità, controllate separatamente per SPF (aspf) e DKIM (adkim). La modalità predefinita per entrambe è “rilassata”.

• Un allineamento rilassato richiede che i due domini condividano lo stesso dominio organizzativo. mail.example.com è conforme a example.com.
• Un allineamento preciso richiede una corrispondenza esatta del dominio. mail.example.com non è compatibileexample.com.

Considera un messaggio con From: billing@example.com e queste possibili identità di autenticazione:

Un allineamento rigoroso può essere appropriato occasionalmente per i domini transazionali ad alto valore (posta per dirigenti, notifiche di pagamento), ma in genere interrompe la posta legittima quando un ESP o un relay si autentica con un sottodominio o il proprio dominio. Iniziare con un allineamento rilassato e stringere solo dopo aver ricevuto segnalazioni che la vostra infrastruttura di invio è in grado di supportarlo.

Scenari di successo e fallimento per DMARC

DMARC richiede almeno un’autenticazione allineata che abbia successo. SPF e DKIM non devono necessariamente avere successo secondo il protocollo DMARC, ma un’autenticazione non allineata non aiuta DMARC. I requisiti specifici del fornitore possono essere più rigorosi; i requisiti di Microsoft per l’invio di posta di massa ai consumatori, discussi di seguito, richiedono che sia SPF che DKIM abbiano successo e almeno un meccanismo allineato per la validazione di DMARC.

Lettura degli header “Authentication-Results”

Durante la risoluzione dei problemi, consultare l’header del destinatario: Authentication-Results. Un messaggio che supera il controllo SPF ma fallisce quello di DMARC (a causa della mancata conformità di SPF) potrebbe apparire così:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.example.com;
  dkim=pass header.d=example.com;
  dmarc=pass header.from=example.com

Un messaggio che supera il controllo SPF ma fallisce il controllo DMARC perché SPF non è correttamente configurato, potrebbe apparire così:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=esp-mailer.example;
  dkim=fail header.d=example.com;
  dmarc=fail header.from=example.com

La sintassi esatta varia a seconda del destinatario, ma la domanda operativa è generalmente la stessa: quale dominio ha superato l’autenticazione e corrisponde al dominio “From” visualizzato?

Politiche DMARC

L’etichetta `p=` indica cosa il proprietario del dominio desidera che i destinatari facciano con le email che falliscono il controllo DMARC. Sono definite tre opzioni nella RFC 7489:

• `p=none` — monitoraggio solo. Il proprietario del dominio non richiede l’applicazione basata su DMARC; i destinatari continuano ad applicare i propri filtri anti-spam, anti-abuso, di reputazione e di policy. Se `rua` è impostato, i destinatari partecipanti possono inviare rapporti aggregati.
• p=quarantine — destinatari dovrebbe considerare le email non recapitate come sospette. In pratica, questo di solito significa indirizzarle alla cartella dello spam o delle email indesiderate, ma il trattamento specifico è definito dal destinatario.
• `p=reject` — il proprietario del dominio richiede il rifiuto delle email fallite, tipicamente durante la transazione SMTP. La gestione finale dipende comunque dalla policy del destinatario.

Due etichette aggiuntive definiscono la policy:

• pct= controlla il campionamento per l’applicazione della policy: specifica a quale percentuale dei messaggi che non superano la verifica applicare la policy richiesta. Secondo RFC 7489 §6.6.4, i messaggi esclusi dalla percentuale selezionata vengono trattati secondo la policy immediatamente meno restrittiva: p=reject diventa p=quarantine, p=quarantine diventa p=none e p=none rimane invariato. Pertanto p=reject; pct=10 significa «applicare reject al 10% dei messaggi che non superano la verifica e trattare il restante 90% come se si applicasse p=quarantine». Per p=quarantine; pct<100, RFC 7489 §6.6.4 indica ai destinatari di classificare normalmente i messaggi non selezionati secondo le proprie regole locali: in pratica, DMARC non impone un trattamento diverso. Restano attivi i normali filtri del destinatario per spam, reputazione e contenuto. I report aggregati comprendono il traffico valutato indipendentemente da pct; pct non determina il campionamento dei report.
• `sp=` imposta la policy per i sottodomini che non pubblicano il proprio record DMARC. In assenza, i sottodomini ereditano il valore `p` del dominio padre.

La policy del destinatario locale può sovrascrivere qualsiasi di queste. I destinatari possono comunque utilizzare sistemi di reputazione, logica di “trusted-forwarder”, liste di approvazione, liste di blocco, filtraggio dei contenuti e modelli di rilevamento di abusi prima di prendere una decisione finale di consegna. La policy pubblicata è la preferenza espressa del proprietario del dominio, non una garanzia del comportamento universale dei destinatari.

Progressione sicura della policy

Passare direttamente a `p=reject` su un dominio di produzione è un modo ad alto rischio per interrompere le email legittime. L’implementazione sicura è metodica:

1. Pubblica p=none con rua che punta a una casella di posta o a un servizio di analisi. Non modificare nulla di altro.
2. Raccogli report aggregati per almeno due o quattro settimane. Identifica ogni indirizzo IP e piattaforma che invia per tuo conto. Per i domini di posta utente che potrebbero ancora essere considerati per p=reject, DMARCbis raccomanda almeno un mese con p=none, seguito da un periodo altrettanto lungo con p=quarantine, prima di confrontare i risultati e decidere se p=reject è accettabile.
3. Inventaria gli mittenti legittimi. Confronta i dati del report. Qualsiasi mittente legittimo che non rispetta le regole deve essere corretto prima dell’applicazione.
4. Correggi le impostazioni SPF, configura DKIM su ogni piattaforma che lo supporta e assicurati che il dominio di firma o il percorso di ritorno producano la corrispondenza con il tuo indirizzo “From” visibile.
5. Passa a p=quarantine con un basso pct (10-25%). Monitora i report.
6. Aumenta pct gradualmente man mano che gli errori provenienti da fonti legittime rimangono invariati.
7. Passa a p=reject solo quando i report aggregati mostrano che praticamente tutto il volume legittimo è correttamente configurato e funziona, e solo se l’utilizzo del dominio può tollerare i rischi associati al reindirizzamento e alle liste di posta.
8. Continua a monitorare costantemente. Nuovi strumenti SaaS, modifiche dei fornitori e l’uso di tecnologie IT non autorizzate introdurranno nuove fonti di invio nel tempo.

Non presumere che Microsoft 365, Google Workspace, il tuo servizio di posta elettronica, il tuo CRM, la tua piattaforma di fatturazione o il tuo helpdesk siano automaticamente configurati correttamente. Non lo sono. Ognuno deve essere configurato per firmare o inviare in modo tale da garantire la corrispondenza con il dominio “From” che intendi utilizzare.

Per domini dedicati a transazioni, fatturazione, avvisi di sicurezza e reindirizzamento, p=reject è spesso lo stato finale maturo corretto una volta che i report sono puliti. Per i domini di posta utente generici in cui i dipendenti pubblicano su liste di posta o si affidano a percorsi di reindirizzamento, p=quarantine potrebbe essere la politica finale più sicura. Considera p=reject come una decisione di rischio, non come un badge di maturità universale.

In base alle attuali linee guida RFC 7489, un messaggio può superare il controllo DMARC utilizzando sia SPF allineato che DKIM allineato. Tuttavia, per i domini che scelgono p=reject, la bozza di DMARCbis aggiunge indicazioni più rigorose: tali domini NON devono fare affidamento esclusivamente su SPF per superare il controllo DMARC e DEVONO utilizzare firme DKIM valide, poiché SPF è fragile in relazione a forwarding e flussi di posta indiretti. Fino alla pubblicazione e all’adozione diffusa di DMARCbis da parte dei destinatari, considerate queste indicazioni come linee guida operative in fase di sviluppo, piuttosto che come un cambiamento nel comportamento definito da RFC 7489.

Cosa non risolve DMARC

DMARC è efficace contro la contraffazione diretta del dominio “From” visibile, ma non rappresenta un controllo completo della sicurezza delle email. Non risolve:

• Account utente compromessi che inviano email autenticate da infrastrutture legittime.
• Dominio simili o affini come examp1e.com o example-billing.com.
• Contraffazione del nome visualizzato, in cui l’attaccante utilizza un dominio diverso ma un nome di mittente fuorviante.
• Allegati o URL dannosi in messaggi che autenticano correttamente.
• Posizionamento nella casella di posta, reputazione del mittente, segnalazioni di spam o filtraggio dei contenuti.
• Compromissione dell’email aziendale da domini legittimi gestiti da attaccanti.

Checklist di prontezza pratica prima di creare un record DMARC

• Inventaria ogni sistema che invia email utilizzando il tuo dominio: piattaforma di posta principale, ESP di marketing, CRM, ERP, help desk, API transazionali, piattaforma di fatturazione, avvisi di monitoraggio e qualsiasi server di applicazioni che emette notifiche.
• Verifica la sintassi del record SPF corrente e conferma che il numero di query DNS sia ben al di sotto del limite di 10 definito dalla RFC 7208.
• Verifica che esista esattamente un record TXT SPF per dominio. La presenza di più record TXT SPF con lo stesso nome rende il risultato SPF permerror, il che impedisce a SPF di contribuire a un passaggio DMARC. Un messaggio può comunque superare il controllo DMARC se il DKIM passa.
• Verifica che la firma DKIM sia abilitata su tutte le piattaforme che la supportano, e verifica che i record della chiave pubblica siano risolvibili.
• Verificare l’allineamento nei messaggi di test provenienti da ciascuna piattaforma di invio utilizzando uno strumento che espone l’intestazione Authentication-Results.
• Rivedere i percorsi di inoltro (elenco di posta, inoltri basati su ruolo/account, gateway di terze parti) per l’impatto discusso di seguito.
• Decidere dove verranno inviate le report aggregate: una casella di posta interna può essere sufficiente per uno o due domini, ma la maggior parte dei team operativi utilizza un servizio di analisi.
• Verificare l’accesso DNS e un TTL appropriato (un intervallo di 300 a 3600 secondi è ragionevole durante l’implementazione).
• Preparare un piano di ripristino: conservare il valore precedente del record TXT in modo da poterlo ripristinare rapidamente.
• Documentare ogni modifica in un sistema di gestione della configurazione o in un manuale operativo per audit e continuità.

Creazione del record TXT DMARC

Il record DMARC è un record TXT pubblicato all’hostname speciale _dmarc.<your-domain>. Non viene posizionato alla radice del dominio. Il valore del record è una sequenza di tag separati da punto e virgola, iniziando con v=DMARC1.

Per un dominio che invia email di produzione e non ha mai applicato DMARC, la modalità di monitoraggio è il punto di partenza normale:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Lo stesso in modalità di monitoraggio, ma indirizzando i report a un fornitore di analisi esterno. Il secondo record deve essere pubblicato dal dominio di destinazione dei report per autorizzare la ricezione dei report per example.com:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example-dmarc-vendor.example"
example.com._report._dmarc.example-dmarc-vendor.example. 3600 IN TXT "v=DMARC1"

Una fase intermedia, applicando la quarantena a un quarto delle email fallite con un allineamento esplicitamente rilassato:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Una configurazione di rifiuto rigorosa per un dominio dedicato, transazionale, di sicurezza, inattivo o strettamente controllato, il cui mittente legittimo è noto, firmato con DKIM, allineato e per il cui proprietario sono accettati i rischi di inoltro e di elenco di posta:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Utilizzando adkim=s o aspf=s, solo le corrispondenze esatte del dominio vengono validate. Un messaggio che utilizza From: billing@example.com non otterrà una validazione SPF rigorosa da MAIL FROM bounce.example.com e non otterrà una validazione DKIM rigorosa da d=mail.example.com. Utilizzare solo la validazione rigorosa dopo che le intestazioni del destinatario reali e i report aggregati confermano che le identità esatte del dominio corrispondono.

Isolare il dominio principale con un’impostazione predefinita di sottodominio più restrittiva (utile quando non ci si aspetta che i sottodomini inviino email):

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; rua=mailto:dmarc-reports@example.com"

Monitoraggio con destinazioni multiple per report aggregati. Ogni dominio organizzativo esterno deve avere il proprio record di autorizzazione:

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com,mailto:dmarc-vendor@example.net"
example.com._report._dmarc.example.net. 3600 IN TXT "v=DMARC1"

Importanti restrizioni e avvertenze:

• Se la destinazione del report si trova in un dominio organizzativo diverso dalla policy, il dominio di destinazione deve pubblicare un record di verifica esterna . Per i report inviati da dmarc@vendor.example a example.com, il record è example.com._report._dmarc.vendor.example con valore v=DMARC1. I servizi di analisi DMARC affidabili gestiscono questo automaticamente, ma verificate dopo l’onboarding.
• L’etichetta ri è un intervallo di reporting opzionale richiesto da RFC 7489. I destinatari possono ignorarlo e molti inviano report aggregati approssimativamente una volta ogni 24 ore, indipendentemente. Gli esempi omettono ri e rf perché sono opzionali e non vengono rispettati in modo operativo, non perché DMARCbis è già ampiamente implementato. Mantenere i record di produzione compatibili con RFC 7489 fino a quando DMARCbis non viene pubblicato e adottato dai destinatari.
• I report forensi (ruf) non sono ampiamente supportati e comportano implicazioni significative per la privacy perché possono contenere il contenuto completo dei messaggi. Trattarli come opzionali e inaffidabili per le operazioni.
• Non pubblicare mai più di un record TXT DMARC con lo stesso nome. In base alla policy di scoperta di RFC 7489, se rimangono più di un record di policy DMARC dopo l’analisi, la scoperta della policy DMARC termina e il destinatario gestisce il messaggio come se non fosse stato trovato alcun record di policy DMARC.
• Non posizionare il record alla radice (example.com). Deve trovarsi in _dmarc.example.com.

Propagazione DNS, TTL e verifica

La TTL (Time To Live) DNS determina per quanto tempo un resolver ricorsivo memorizza un record. Una TTL di 3600 (un’ora) è ragionevole per un record DMARC in stato di stabilità; durante un’implementazione attiva, ridurre la TTL a 300 consente di annullare rapidamente una modifica. La TTL è la durata della cache, non una garanzia di propagazione: le cache che già contengono il vecchio record continueranno a utilizzarlo fino a quando la sua copia non scade.

Comandi di verifica:

dig TXT _dmarc.example.com

nslookup -type=TXT _dmarc.example.com

Per ottenere un quadro completo, di solito è necessario verificare SPF e DKIM contemporaneamente. Controllare il record SPF nel documento RFC5321 effettivo, nel dominio utilizzato per ogni flusso di invio, e non solo nel dominio “From” visibile, e verificare ogni coppia di selettori/dominio DKIM utilizzati dalle vostre piattaforme di posta elettronica:

dig TXT example.com
dig TXT bounce.example.com
dig TXT selector1._domainkey.example.com
dig TXT selector2._domainkey.mail.example.com

Strumenti di terze parti come Google Admin Toolbox, MxToolbox, dmarcian, EasyDMARC e altri sono utili per la verifica della sintassi e la visualizzazione, ma sono strumenti diagnostici, non autorità di protocollo. In caso di problema di consegna a un destinatario specifico, l’header del destinatario stesso (Authentication-Results) è di solito la prova più rilevante, a condizione che si stia leggendo un header inserito da quel destinatario e non da un intermediario non attendibile.

Analisi completa della sintassi DMARC

Errori comuni da segnalare: omettere v=DMARC1 come primo tag, utilizzare una sintassi di tag non valida, inserire il record al livello superiore anziché sotto _dmarc, pubblicare più record TXT con lo stesso nome e fare affidamento su ruf per la visibilità, quando molti destinatari non invieranno affatto report forensi.

Report aggregati vs. report forensi

I report aggregati (RUA) sono report in formato XML, comunemente forniti come allegati compressi, come file gzip o zip. Rappresentano il principale meccanismo operativo per comprendere cosa sta succedendo alle email che utilizzano il tuo dominio. Un singolo report contiene i metadati del report, un riepilogo della policy applicata e uno o più <record> blocchi. Ogni <record> descrive il traffico proveniente da un singolo indirizzo IP, tra cui:

• L’indirizzo IP sorgente e il numero di messaggi per il periodo di reporting.
• L’azione intrapresa dal destinatario (none, quarantine o reject).
• I risultati di autenticazione DKIM e SPF.
• Il dominio “From” valutato.
• I risultati di autenticazione DKIM e SPF pass/fail dopo l’elaborazione di allineamento, oltre ai risultati di autenticazione grezzi, se riportati.

Nell’XML sottostante, i valori sotto policy_evaluated riflettono la valutazione del meccanismo di allineamento di DMARC per quella riga; i valori sotto auth_results riflettono i risultati di autenticazione grezzi SPF/DKIM riportati dal destinatario. Pertanto, un SPF pass non allineato può legittimamente apparire come <spf>fail</spf> sotto policy_evaluated, mentre appare come <result>pass</result> sotto auth_results.

Un record aggregato esemplificativo, ridotto:

<feedback>
  <report_metadata>
    <org_name>receiver.example</org_name>
    <email>dmarc-noreply@receiver.example</email>
    <report_id>20260512-abc123</report_id>
    <date_range>
      <begin>1778544000</begin>
      <end>1778630400</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <pct>25</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.45</source_ip>
      <count>127</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.esp.example</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

I dati sopra riportati sono esemplificativi e non descrivono alcuna organizzazione reale.

La copertura RUA è utile, ma non globale. Solo i destinatari partecipanti inviano report aggregati; alcuni destinatari sopprimono o aggregano i dettagli in modo diverso, e la consegna dei report può fallire. Considera i RUA come la principale fonte di telemetria operativa per DMARC, non come un censimento completo di tutti i messaggi inviati con il tuo dominio.

L’analisi manuale dei report aggregati funziona per un singolo dominio con un numero limitato di mittenti. Oltre a ciò, indirizza i report a un parser, un servizio di reporting DMARC gestito o a un pipeline SIEM che possa normalizzare l’XML e preservare le tendenze storiche. È possibile impostare avvisi su segnali come:

• Un nuovo indirizzo IP sorgente che supera una soglia di volume.
• Un improvviso aumento degli errori DMARC da una fonte precedentemente correttamente configurata – tipicamente un segno precoce di una configurazione errata dopo un cambiamento del fornitore.
• Una nuova header_from sottodominio che non è mai apparso prima.
• Un cambiamento nel numero di transazioni dopo un cambiamento DNS o della piattaforma.

I report di errore (RUF) sono separati, per messaggio e contengono i dati del messaggio, inclusi potenzialmente gli header completi. Molti destinatari non li inviano. Alcuni, invece, richiedono ulteriori autorizzazioni. Possono essere utili in scenari di indagine specifici, ma non dovrebbero essere la base di una strategia di monitoraggio.

Considerazioni per Microsoft 365 e Google Workspace

Entrambe le piattaforme ospitano grandi quantità di email aziendali, ma nessuna di esse fornisce automaticamente una configurazione DMARC funzionante. Ognuna richiede una configurazione esplicita per ogni dominio personalizzato.

Microsoft 365. Servizi informatici di Microsoft documentazione ufficiale di configurazione DMARC descrive il flusso di lavoro: SPF viene pubblicato presso il vostro registrar di dominio (solitamente includendo spf.protection.outlook.com); DKIM è abilitato per dominio tramite la pagina DKIM di Microsoft Defender, che consente di creare record di selezione basati su CNAME che pubblicate presso il vostro provider DNS; il record TXT di DMARC viene creato a _dmarc.<domain>. In base alle regole di scoperta di policy definite in RFC 7489, un record DMARC del dominio principale si applica ai sottodomini che non pubblicano il proprio record DMARC, e Microsoft documenta questo comportamento di ereditarietà per i domini Microsoft 365. Si prega di notare la gestione speciale per il tenant. *.onmicrosoft.com per i domini e per i domini “inattivi”: entrambi devono essere protetti con i propri record DMARC, che puntano a un indirizzo di destinazione reale, anche se non si inviano email da essi, per rendere visibili le tentativi di falsificazione.

Microsoft 365 da solo non rappresenta una configurazione completa di sicurezza per le email. La configurazione di amministrazione di Microsoft 365, le regole di flusso delle email, le politiche delle caselle di posta e Defender for Office 365 coprono i lati di ricezione e di applicazione delle politiche; l’allineamento DMARC per l’invio dipende da ciò che il vostro dominio pubblica nel DNS e da come ogni mittente di terze parti è configurato.

Microsoft ha inoltre annunciato requisiti specifici per chi invia messaggi ai suoi servizi di posta per utenti privati (Outlook.com, Hotmail.com, Live.com e msn.com). Secondo il suo annuncio del 2025 e la documentazione Microsoft sul codice NDR 550 5.7.515, i domini che inviano 5.000 o più messaggi al giorno a tali servizi devono pubblicare record SPF e DKIM, superare entrambe le verifiche, pubblicare DMARC con almeno p=none e avere almeno un meccanismo di autenticazione allineato a DMARC. Si tratta di un requisito più rigoroso rispetto a DMARC di base, per il quale è sufficiente superare una verifica di autenticazione allineata. I messaggi ad alto volume non conformi possono essere rifiutati con una risposta SMTP del tipo 550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.

Google Workspace. La documentazione di Google sulla configurazione di DMARC e le sue linee guida per i mittenti di email descrivono come attivare DKIM nella console di amministrazione, che genera un record TXT da pubblicare per il selettore, autorizzare Google Workspace in SPF mediante include:_spf.google.com e pubblicare un record DMARC in _dmarc. Occorre ricordare che l’allineamento SPF dipende comunque dall’allineamento tra il dominio del mittente della busta e quello visibile nel campo From. I requisiti di Google per i mittenti di massa si applicano specificamente a chi invia messaggi ad account Gmail personali: chi raggiunge circa 5.000 o più messaggi in 24 ore verso tali account è considerato un mittente di massa e deve autenticare e allineare i messaggi, pubblicare DMARC, consentire la disiscrizione con un clic per le email di marketing e promozionali e mantenere tassi di spam accettabili. Google ha dichiarato che il conteggio comprende lo stesso dominio principale e i suoi sottodomini. Questa è una regola di classificazione del provider Google, non l’algoritmo DMARC per individuare il dominio organizzativo; inoltre, la classificazione come mittente di massa non scade automaticamente dopo essere stata assegnata. Il semplice invio da Workspace non soddisfa questi requisiti: il dominio deve essere configurato.

Yahoo. Servizi di Yahoo Migliori pratiche per mittenti descrivere aspettative simili: implementare SPF e DKIM, pubblicare una politica DMARC valida con almeno p=none, e assicurarsi che il dominio “From” sia in linea con il dominio SPF o DKIM. Yahoo e Google hanno annunciato requisiti comuni per gli invianti di massa nel 2024; per ottenere i valori attuali e le regole esatte, consultare direttamente la documentazione di Yahoo, piuttosto che affidarsi a riassunti di terze parti. Yahoo ha inoltre descritto la sua classificazione degli invianti di massa come basata su modelli, piuttosto che legata a un singolo conteggio di messaggi quotidiani pubblici. Domande frequenti del mittente aggiunge una specifica condizione relativa a DKIM specifica per il provider: se un messaggio contiene più firme DKIM allineate con DMARC e non tutte passano, Yahoo non garantisce che il messaggio supererà il controllo DMARC.

Per qualsiasi di queste piattaforme, i domini e i sottodomini personalizzati devono essere registrati individualmente. L’invio di massa di domini (marketing, fatturazione, transazionale) deve essere inventariato e autenticato separatamente dalle caselle di posta degli utenti aziendali. DMARC non sostituisce la sicurezza della casella di posta: MFA (idealmente MFA resistente al phishing come FIDO2 o WebAuthn passkeys), Accesso Condizionale, conservazione dei log per indagini forensi, monitoraggio delle regole di inoltro della casella di posta create dagli attaccanti e un processo di risposta agli incidenti per gli account compromessi sono tutti controlli complementari che DMARC non sostituisce.

Problemi comuni di DMARC e soluzioni

Inoltro di email

L’inoltro è la classica fonte di problemi per DMARC. Quando un destinatario inoltra un messaggio (tramite un inoltro lato server, una mailing list o un account di ruolo), l’indirizzo IP di connessione al passaggio successivo è l’inoltratore, non il mittente autorizzato. SPF, valutato su questa nuova transazione SMTP, fallisce. DKIM potrebbe sopravvivere se l’inoltratore non modifica il corpo del messaggio o le intestazioni firmate; spesso fallisce se il messaggio viene modificato (ad esempio, tramite l’iniezione di un piè di pagina da una mailing list).

Esistono due mitigazioni. Lo Schema di Riscrizione del Mittente (SRS) riscrive il mittente dell’enveloppe in modo che SPF possa passare attraverso l’inoltratore; SRS non ha alcun effetto su DKIM e non affronta l’allineamento di DMARC per il mittente visibile. La Catena di Ricezione Autenticata (ARC), definita in RFC 8617, consente a ciascun intermediario di attestare in modo crittografico i risultati di autenticazione originali, in modo che un destinatario finale possa fidarsi della decisione dell’inoltratore, anche se SPF e DKIM non passano più direttamente.

RFC 8617 è sperimentale, non fa parte dello standard. Esiste anche un dibattito attivo nell’IETF sullo stato a lungo termine di ARC, in particolare draft-ietf-dmarc-arc-to-historic (“Riassegnare ARC come Storico”), che ha sostituito le precedenti versioni individuali draft-adams-arc-experiment-conclusion. La bozza attuale del gruppo di lavoro raccomanda che ARC non debba più essere implementato o utilizzato tra mittenti e destinatari diversi. Il supporto del destinatario è disomogeneo, la fiducia è per singolo mittente e ARC non dovrebbe essere considerato come una soluzione generale per l’inoltro arbitrario di email. RFC 7960 descrive in dettaglio l’inoltro e altri problemi di interoperabilità.

Fornitori di Email Marketing (ESPs)

La maggior parte degli ESP utilizza per impostazione predefinita la firma delle email in uscita con il proprio dominio e utilizza un percorso di ritorno condiviso. Entrambi falliscono l’allineamento di DMARC con il tuo mittente. Per risolvere questo problema, è necessario:

• Configurare un percorso di ritorno personalizzato (dominio di risposta) su un sottodominio di cui disponi, con i dati SPF o CNAME forniti dall’ESP.
• Configurare un dominio di firma DKIM personalizzato in modo che l’ESP firmi con d= un dominio che corrisponda organizzativamente al tuo mittente.
• Opzionalmente, configurare un dominio di tracciamento personalizzato.
• Inviare campagne di test e ispezionare l’intestazione Authentication-Results al destinatario prima di applicare le regole.

Una pratica comune è quella di mantenere le comunicazioni di marketing su un sottodominio dedicato (news.example.com, marketing.example.com), in modo che la loro reputazione sia isolata da quella delle comunicazioni aziendali.

Piattaforme CRM, ERP, fatturazione, gestione dei ticket e helpdesk

Queste piattaforme sono la componente “oscura” dell’autenticazione delle email. Spesso inviano notifiche transazionali, fatture e risposte dei clienti utilizzando il tuo dominio nel campo “From” – a volte tramite la propria infrastruttura, a volte tramite relay SMTP, a volte da indirizzi IP condivisi. Per ciascuna di esse:

• Verificare che il fornitore abbia documentato i passaggi di configurazione per l’inclusione di SPF e la firma DKIM.
• Valutare l’impatto sul numero di richieste SPF prima di aggiungere le istruzioni – ogni direttiva include: può consumare ricorsivamente il budget di 10 richieste.
• Verificare che i messaggi di uscita reali producano SPF o DKIM correttamente configurati.
• Se un fornitore non può firmare con il tuo dominio, reindirizzare il suo traffico tramite un sottodominio in modo che un errore in quel punto non comprometta la reputazione del tuo dominio principale.

Sottodomini

Il dominio aziendale è il dominio registrato immediatamente sotto un suffisso pubblico (come derivato dalla Public Suffix List secondo RFC 7489; DMARCbis introduce un meccanismo diverso – la “DNS Tree Walk” – descritto di seguito). Ogni sottodominio eredita la politica DMARC del suo genitore, a meno che non la pubblichi. sp= ti consente di impostare una politica predefinita diversa per i sottodomini. Un modello comune è:

• example.com – email per gli utenti aziendali, solitamente p=quarantine o p=reject a seconda della gestione del inoltro e delle liste di mailing.
• marketing.example.com – traffico ESP con il proprio record DMARC che corrisponde alle capacità di allineamento dell’ESP.
• billing.example.com – email transazionali, p=reject una volta stabilita.
• support.example.com— Risposte del helpdesk, configurate per allinearsi con il fornitore del helpdesk.

Dividere il traffico in questo modo evita danni alla reputazione e vi conferisce indipendenza in termini di policy per ogni caso d’uso.

Dominio inutilizzati e non attivi

Ogni dominio di cui un’organizzazione è proprietaria ma non utilizza per l’invio di email è un bersaglio per il phishing. Bloccare questi domini è una delle soluzioni di sicurezza più economiche, ma deve essere fatto in modo deliberato: i record riportati di seguito si applicano solo a un dominio che non invia né né e non riceve email. Non applicare questi record in modo indiscriminato a un dominio che effettivamente gestisce l’invio di email.

Per un dominio completamente inutilizzato, pubblicare tre record:

• Un record SPF nullo che dichiara che nessun host è autorizzato a inviare email per quel dominio.
• Un record MX nullo (per RFC 7505) dichiarando che il dominio non accetta email.
• Un record DMARC rigoroso in _dmarc con p=reject e una destinazione rua effettiva per rendere visibili i tentativi di spoofing. Se il dominio pubblica un null MX, non indirizzate rua allo stesso dominio: i report devono raggiungere una casella che possa effettivamente ricevere posta.

Esempio di DNS per un dominio inutilizzato:

example.com.                         3600 IN TXT "v=spf1 -all"
example.com.                         3600 IN MX  0 .
_dmarc.example.com.                  3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.org"
example.com._report._dmarc.example.org. 3600 IN TXT "v=DMARC1"

Se il dominio riceve email ma non le invia, omettere il record MX nullo e mantenere il record SPF nullo e il DMARC rigoroso, puntando rua a una casella di posta funzionante su quel dominio o a un processore di report esterno autorizzato. Se il dominio invia email, il modello per dominio inutilizzato non si applica: procedere con il rollout graduale. Puntare rua a una destinazione reale che accetta email è ciò che trasforma il blocco da passivo a attivamente monitorato: senza una destinazione di report, i tentativi di phishing contro i vostri domini bloccati rimangono invisibili. Nell’esempio sopra, example.org rappresenta un dominio di reportaggio separato, quindi è incluso il record di verifica della destinazione esterna.

Record SPF multipli

RFC 7208 §3.2 è esplicito: un dominio DEVE avere esattamente un record SPF. Più record TXT con lo stesso nome, ciascuno dei quali inizia con v=spf1, producono il risultato permerror: la verifica SPF non viene superata e, di conseguenza, fallisce anche l’allineamento SPF in DMARC. Riunite tutti i mittenti autorizzati in un unico record SPF, rispettando il limite di 10 ricerche DNS. Lo SPF flattening —la sostituzione dei meccanismi include: con intervalli IP espliciti generati da un servizio del fornitore— è un’opzione, ma introduce una dipendenza operativa: quando cambiano gli IP del fornitore, il record appiattito deve essere rigenerato, altrimenti la posta inizierà a non superare le verifiche senza segnali evidenti.

DKIM non funzionante

I modi tipici di fallimento del DKIM sono: assenza o record di chiave pubblica errato nel selettore; modifiche alle gateway di posta (footer antivirus, riscrittura dei link, riscrittura dei contenuti) che invalidano la firma; dominio di firma errato (quindi il messaggio ha tecnicamente una firma valida ma non è conforme); chiavi ruotate che non vengono propagate nel DNS; e chiavi scadute o revocate.

DKIM è specificato in RFC 6376, con RFC 8301 (Standards Track) che aggiorna la sua base crittografica: rsa-sha1 è vietato, la dimensione minima della chiave di firma RSA è di 1024 bit, e si raccomanda l’uso di RSA a 2048 bit per chiavi a lunga durata. RFC 8463 registra inoltre ed25519-sha256 come algoritmo DKIM supportato. Prima di utilizzare l’operazione Ed25519, verificare la compatibilità con la piattaforma di invio, i gateway intermedi e i destinatari. Una chiave pubblica RSA a 2048 bit supera il limite di 255 ottetti per una singola stringa di caratteri DNS e deve essere pubblicata come più stringhe quotate all’interno di un singolo record TXT; i verificatori concatenano le stringhe prima dell’analisi. Eseguire test dopo qualsiasi modifica al flusso di posta, in particolare dopo l’introduzione di un nuovo gateway, un prodotto anti-malware o una configurazione ibrida di Exchange.

Account compromessi

DMARC non fa nulla per impedire l’invio di e-mail autenticate legittime da una casella di posta compromessa. Se un attaccante ha le credenziali dell’utente e invia tramite Microsoft 365 o Google Workspace attraverso il percorso di uscita normale, il messaggio sarà correttamente allineato con SPF e DKIM. DMARC non è il controllo appropriato per questa minaccia. I controlli appropriati sono l’autenticazione a due fattori (MFA) resistente al phishing, le politiche di accesso condizionale che limitano dove e come gli utenti possono autenticarsi, l’assegnazione di ruoli con il minimo privilegio, la revisione periodica delle regole di inoltro della casella di posta e delle regole della casella di posta in arrivo (un meccanismo frequente di persistenza degli attaccanti), la conservazione dei log con avvisi sui modelli di invio anomali e un processo di risposta agli incidenti documentato.

DMARC come parte di un programma di sicurezza più ampio

DMARC è un controllo in un programma di sicurezza delle e-mail a più livelli: né sufficiente da solo, né un sostituto dei controlli per la casella di posta, i dispositivi, la rete e la risposta agli incidenti. Dal punto di vista della governance e dell’audit, i report aggregati di DMARC possono fornire prove utili della copertura dell’autenticazione delle e-mail, dell’inventario dei mittenti di terze parti e del monitoraggio continuo dei sistemi che inviano utilizzando il proprio dominio. Non esagerare con queste prove: i report DMARC mostrano le valutazioni di autenticazione dei destinatari partecipanti, non un censimento completo di tutte le attività di posta elettronica globali.

Questa prospettiva è utile quando si giustifica il lavoro a un stakeholder non tecnico, ma non dovrebbe essere esagerata. DMARC non fornisce protezione dei dati in transito (utilizzare TLS, MTA-STS e TLS-RPT per questo), non rileva il malware, non previene la compromissione dell’account e non blocca il phishing con domini simili. Combinarlo con la risoluzione delle vulnerabilità, la disciplina della gestione della configurazione per la pila di posta, il monitoraggio continuo dei fallimenti di autenticazione e la formazione degli utenti sulla riconoscibilità del phishing.

Scenario ipotetico di implementazione

Lo scenario di seguito è ipotetico e utilizza numeri illustrativi. Non si basa su alcuna organizzazione reale specifica.

Stato iniziale. Un’azienda di medie dimensioni utilizza Microsoft 365 per la posta elettronica aziendale. example.com. SPF è attivo, ma include nove fornitori; DKIM è abilitato solo nella configurazione predefinita. onmicrosoft.com dominio; non è presente alcun record DMARC. Le e-mail transazionali rivolte ai clienti provengono da una piattaforma SaaS per la fatturazione, inviate come example.com; le campagne di marketing vengono eseguite tramite un servizio di email marketing (ESP) example.com; le risposte del helpdesk vengono inviate tramite uno strumento di gestione dei ticket, inviando example.com.

Fase 1, settimane 1-2. L’ingegneria consente la firma DKIM per il dominio personalizzato in Microsoft 365 (registrazioni CNAME pubblicate, attivazione della firma una volta che le registrazioni sono risolte). v=DMARC1; p=none; rua=mailto:dmarc@example.com e inviare i report a un servizio di analisi DMARC. I primi report evidenziano quindici intervalli di indirizzi IP di invio distinti. La maggior parte sono quelli previsti (Microsoft 365, il provider di servizi, la piattaforma di fatturazione, lo strumento di ticketing). Tre sono diversi: due sono server on-premises obsoleti di cui nessuno aveva documentato, e uno è un ambiente di test per sviluppatori.

Fase 2, settimane 3–6. Vengono esaminati i mittenti non documentati. I server locali vengono migrati per inoltrare la posta tramite Microsoft 365 con l’autenticazione appropriata del connettore; l’ambiente di prova isolato viene spostato dal dominio di produzione a un sottodominio dedicato. L’ESP viene riconfigurato con un return-path personalizzato e un dominio personalizzato per la firma DKIM; la quota di traffico di marketing allineato passa dallo 0% a quasi la totalità. La piattaforma di fatturazione viene riconfigurata per DKIM con un’identità di firma allineata al dominio. Lo strumento di gestione dei ticket viene configurato allo stesso modo. SPF viene rivisto: vengono rimossi due include di fornitori non più utilizzati, portando il numero di ricerche a sette.

Fase 3, settimane 7-10. La politica viene spostata su v=DMARC1; p=quarantine; pct=10; rua=.... I report aggregati continuano ad essere esaminati settimanalmente. Dopo due settimane senza problemi, pct passa a 25, poi a 50, e infine a 100.

Fase 4, settimana 11+. Con report che dimostrano che la maggior parte del traffico legittimo è indirizzato attraverso almeno un meccanismo, e dopo aver verificato che il rischio associato al forwarding e alle mailing list del dominio è accettabile, la politica viene spostata in p=reject. Il traffico di marketing viene indirizzato su news.example.com, con il proprio record DMARC, in modo che eventuali modifiche future degli strumenti di marketing non disturbino la posta aziendale. Il monitoraggio continuo prosegue; il team aggiunge un avviso per qualsiasi nuovo indirizzo IP che superi una soglia giornaliera.

Lezioni. I maggiori rischi non erano tecnici, ma derivavano dall’esistenza di sistemi non documentati, che erano diventati visibili solo grazie a report aggregati. Senza la fase di monitoraggio, il passaggio all’applicazione delle regole avrebbe interrotto silenziosamente tali flussi. Nessuno dei percentuali o dei conteggi presentati in questo scenario dovrebbe essere interpretato come una garanzia di risultato; sono plausibili dal punto di vista operativo, ma specifici per questa situazione ipotetica.

Tendenze e standard correlati nel 2025-2026

Esistono diversi sviluppi degni di nota da tenere d’occhio a partire da maggio 2026.

DMARCbis. A partire dal 13 maggio 2026, bozza: IETF DMARC-DMARCBIS-41 è elencato da IETF Datatracker con lo stato IESG RFC Ed Queue e le dichiarazioni dell’editore RFC AUTH48, con lo stato desiderato Proposed Standard. Fino a quando non viene assegnato un numero RFC e il documento non viene pubblicato, trattarlo come un “Internet-Draft” in fase di elaborazione e verificare lo stato attuale su Datatracker. Lo scopo del documento è quello di rendere obsolete le RFC 7489 e 9091, qualora approvate. La modifica principale è che DMARCbis sostituisce la “Public Suffix List” come meccanismo per determinare il dominio organizzativo tramite una “DNS Tree Walk”, eliminando la dipendenza da un elenco esterno, manualmente mantenuto.

Proposte di implementazione di DMARCbis. DMARCbis suddivide il lavoro del protocollo in tre documenti: la specifica principale di DMARCbis, la generazione di report aggregati e la segnalazione di errori. A partire dal 13 maggio 2026, la bozza principale di DMARCbis è elencata da IETF Datatracker con lo stato IESG. RFC Ed Queue e le dichiarazioni dell’editore RFC AUTH48. Anche le bozze per la generazione di report aggregati e per la segnalazione di errori sono disponibili nella sezione RFC Editor come documenti separati del Working Group DMARC dell’IETF.bozza: IETF – Reporting aggregato DMARC e progetto IETF relativo alla segnalazione di errori DMARC), in conformità con lo stato IESG RFC Ed Queue e le dichiarazioni dell’editore RFC RFC-EDITOR. Fino a quando non saranno assegnati i numeri RFC e i documenti non saranno pubblicati, trattare tutti e tre come bozze in fase di transizione. Non ci si aspetta un cambiamento immediato del parser unicamente perché la reportistica aggregata è stata suddivisa in un documento complementare, ma gli operatori che elaborano i report dovrebbero monitorare la specifica RFC finale per la reportistica aggregata prima di considerare il comportamento del parser come definitivo.

Modifiche del tag DMARCbis. DMARCbis elimina anche tre tag RFC 7489 e ne introduce tre nuovi. pct viene sostituito da un flag di test binario t=: t=y richiede che i destinatari applichino la policy a un livello inferiore rispetto al valore specificato p / sp / np (quindi p=reject; t=y viene trattato come quarantine e p=quarantine; t=y come none); t=n (il valore predefinito) richiede che venga applicata la policy come è. L’esperienza operativa ha dimostrato che i valori intermedi pct venivano implementati in modo incoerente dai destinatari: in pratica, solo pct=0 e pct=100 erano affidabili, quindi il gruppo di lavoro ha abbandonato il campionamento basato sulla percentuale a favore di un segnale di test univoco. Anche ri e rf vengono rimossi, per motivi simili (i destinatari ignoravano ri e veniva definito solo un valore rf). Per quanto riguarda le aggiunte, np= dichiara una policy per sottodomini inesistenti (risposte NXDOMAIN), colmando una lacuna che consente agli attaccanti di falsificare sottodomini casuali; psd= formalizza il marker del Public Suffix Domain, originariamente introdotto in modo sperimentale in RFC 9091, in modo che registri come gov.uk possano pubblicare policy significative. I record esistenti v=DMARC1 rimangono validi: i destinatari di DMARCbis ignorano i tag sconosciuti e i destinatari di RFC 7489 ignorano quelli nuovi, ma le implementazioni di produzione dovrebbero rimanere compatibili con RFC 7489 fino a quando DMARCbis non viene pubblicato e adottato dai destinatari. Considerate t=, np= e psd= come elementi di transizione da monitorare e testare, non come il comportamento universale dei destinatari oggi.

Requisiti per i mittenti di Gmail, Yahoo e Outlook. I requisiti di Google per i mittenti di massa si applicano a chi invia circa 5.000 o più messaggi in 24 ore ad account Gmail personali. Le domande frequenti sulle linee guida per i mittenti di Google indicano che i messaggi inviati dallo stesso dominio principale, inclusi i sottodomini, vengono conteggiati ai fini della soglia e che la classificazione come mittente di massa non scade automaticamente. Google richiede a questi mittenti di autenticare la posta con SPF e DKIM, pubblicare una policy DMARC, rispettare i requisiti di allineamento, consentire la disiscrizione con un clic per le email di marketing e promozionali e mantenere tassi di spam accettabili. Yahoo pubblica raccomandazioni analoghe: implementare SPF e DKIM, pubblicare una policy DMARC valida con almeno p=none e assicurarsi che il dominio nel campo From sia allineato al dominio SPF o DKIM. Nel 2025 Microsoft ha annunciato requisiti per l’invio ai servizi di posta per privati Outlook.com, Hotmail.com, Live.com e msn.com: i domini che inviano 5.000 o più messaggi al giorno a tali servizi devono pubblicare SPF e DKIM, superare entrambe le verifiche, pubblicare DMARC e allineare SPF e/o DKIM per la convalida DMARC. I messaggi non conformi possono ricevere rifiuti SMTP 550 5.7.515.

BIMI. Gli Indicatori di Marca per l’Identificazione dei Messaggi (BMID) sono attualmente Proposta IETF per Internet, non è una specifica RFC. Non rafforza l’autenticazione da solo – si basa sulle funzionalità SPF, DKIM e DMARC esistenti. La versione attuale richiede una politica DMARC robusta sia per il dominio dell’organizzazione che per il dominio “From”: p=rejectoppure p=quarantine con un’efficacia comprovata pct=100, e qualsiasi politica relativa ai sottodomini (sp) NON deve essere none. Come BIMI gestirà le richieste di DMARCbis t=y flag di test al posto di pct=0 non è ancora stato implementato nella bozza BIMI. I fornitori di servizi di posta elettronica decidono se e come visualizzare l’indicatore, e la visualizzazione del logo aziendale anche presso i principali fornitori richiede un Certificato di Marchio Verificato (VMC) o un Certificato di Marchio Comune (CMC), che rappresenta un costo e un processo separati dalla semplice configurazione DNS.

MTA-STS e TLS-RPT. RFC 8461 (MTA-STS) e RFC 8460 (SMTP TLS Reporting) proteggono le email durante il transito tra MTA, applicando TLS e segnalando eventuali errori. Sono indipendenti da DMARC, ma vengono comunemente implementati insieme ad esso, come parte di una strategia completa di sicurezza delle email.

Checklist per l’implementazione

• Identificate tutti gli mittenti legittimi utilizzando il vostro dominio nel campo “From”.
• Valutate la sintassi del vostro record SPF e il numero di query DNS; eliminate eventuali record TXT SPF duplicati.
• Abilitate DKIM su tutte le piattaforme di supporto, con un dominio di firma che corrisponda al vostro “From”.
• Verificate l’allineamento SPF e DKIM per messaggi rappresentativi da ciascuna piattaforma.
• Pubblicate _dmarc.<domain> con p=none e un vero rua destinatario.
• Bloccate i domini parcheggiati e inutilizzati con SPF a null, MX a null (se non ricevono email) e p=reject DMARC puntando a un vero destinatario.
• Raccogliete report aggregati per diverse settimane. Importateli in un parser o servizio.
• Analizzare ogni indirizzo IP di invio presente nei report. Risolvere eventuali incertezze prima di apportare qualsiasi modifica alle policy.
• Testare l’invio di email transazionali, dall’inizio alla fine, utilizzando Microsoft 365 o Google Workspace, ESP, CRM, fatturazione, helpdesk e qualsiasi altro sistema.
• Passate a p=quarantine con un valore basso di pct; monitorate e aumentate gradualmente.
• Passare a p=reject solo quando i report confermano che il traffico legittimo è pulito e che il rischio associato al forwarding/elenco di mailing del dominio è accettabile; in caso contrario, documentare p=quarantine come policy finale per quel dominio.
• Continuare a monitorare permanentemente. Rivedere periodicamente SPF, DKIM e DMARC dopo qualsiasi modifica al flusso di email, cambio di fornitore o aggiunta di dominio.
• Documentare la posizione DMARC come parte della valutazione della sicurezza e delle prove di conformità.

Conclusione

DMARC non è una semplice modifica DNS. È una pratica operativa iterativa: inventario, strumentazione con il monitoraggio, correzione dei problemi evidenziati dai report, applicazione graduale e monitoraggio continuo. Il punto di partenza è p=none con il monitoraggio; la destinazione matura dipende dalla funzione del dominio. I domini transazionali e di parcheggio dedicati spesso si trovano a p=reject, mentre i domini di posta elettronica generici possono rimanere più sicuri a p=quarantine quando l’utilizzo di elenchi di mailing o il forwarding è inevitabile. Evitare questo passaggio è il modo in cui si verificano interruzioni di posta legittime.

Se gestito in questo modo, DMARC è un controllo di alto valore. Riduce la possibilità di spoofing diretto del dominio “From” visibile, fornisce una visibilità continua sulla valutazione delle email da parte dei destinatari utilizzando il proprio dominio e produce prove utili per dimostrare la copertura di autenticazione, a condizione che i destinatari partecipino e che i limiti di invio dei report siano rispettati. Combinato con SPF, DKIM, MFA, Conditional Access, MTA-STS, TLS-RPT, conservazione dei log, formazione degli utenti, risposta agli incidenti e monitoraggio continuo, fa parte di un programma di sicurezza delle email difendibile. Da solo, non lo è. Configuralo di conseguenza.

Fonti

• RFC 7489 – Autenticazione, segnalazione e conformità basate sul dominio (DMARC), informativa
• RFC 7208 — Sender Policy Framework (SPF)
• RFC 6376 — Firme DomainKeys Identified Mail (DKIM)
• RFC 8301 – Aggiornamento degli algoritmi crittografici e dell’uso delle chiavi per DomainKeys Identified Mail (DKIM)
• RFC 8463 — Un nuovo metodo di firma crittografica per DomainKeys Identified Mail (DKIM)
• RFC 8601 — Campo dell’intestazione del messaggio per indicare lo stato di autenticazione
• RFC 8617 — Protocollo Authenticated Received Chain (ARC), sperimentale
• RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460 — Report TLS per SMTP
• RFC 7960 — Problemi di interoperabilità tra DMARC e flussi di posta indiretti (elenco di distribuzione, inoltri, gateway, intermediari)
• RFC 7505 — Record di risorsa “Null MX” per domini che non accettano posta
• RFC 8553 — Modifiche a DNS Attrleaf: correzione delle specifiche utilizzando nomi di nodi con underscore
• RFC 8616 — Autenticazione della posta elettronica internazionalizzata
• RFC 9091 — Estensione sperimentale di DMARC per domini di dominio pubblico
• IETF Datatracker — draft-ietf-dmarc-dmarcbis (DMARCbis, Internet-Draft)
• IETF Datatracker — draft-ietf-dmarc-aggregate-reporting
• IETF Datatracker — draft-ietf-dmarc-failure-reporting
• IETF Datatracker — draft-ietf-dmarc-arc-to-historic
• IETF Datatracker — draft-adams-arc-experiment-conclusion
• IETF Datatracker — Brand Indicators for Message Identification (BIMI), proposta internet
• Microsoft Learn — Usare DMARC per convalidare la posta: configurazione
• Microsoft Learn — Reporting DMARC per MOERA e domini secondari
• Microsoft Tech Community — Requisiti di Outlook per mittenti ad alto volume
• Microsoft Support — Risolvere l’errore NDR 550 5.7.515 in Outlook.com
• Google Workspace Admin Help — Prevenire il phishing e lo spam con DMARC
• Guida per amministratori di Google Workspace — Linee guida per i mittenti
• Guida per amministratori di Google Workspace — Domande frequenti sulle linee guida per i mittenti
• Yahoo Sender Hub — Buone pratiche e requisiti per i mittenti
• Yahoo Sender Hub — Domande frequenti dei mittenti