Come leggere la politica DMARC di un'azienda in dieci secondi (e cosa non ti dice)

Una ricerca DNS ti dice cosa un'azienda ha chiesto ai server di posta del mondo di fare con la posta falsificata inviata a suo nome. Il record è pubblico, e il comando è una riga: dig +short TXT _dmarc.example.com. Quello che torna è una breve stringa di impostazioni, e dentro c'è un'istruzione — p=none, p=quarantine o p=reject — che dichiara la preferenza del proprietario del dominio quando un messaggio che usa quel dominio non supera l'autenticazione.

La specifica attuale, RFC 9989, pubblicata nel maggio 2026 come documento IETF Standards Track, ha sostituito la precedente RFC 7489. Definisce i tre valori quasi laconicamente:

• p=none — "Il proprietario del dominio non esprime alcuna preferenza."
• p=quarantine — "Il proprietario del dominio considera tale posta sospetta. È possibile che la posta sia valida, sebbene il mancato superamento dell'autenticazione crei una preoccupazione significativa."
• p=reject — "Il proprietario del dominio considera tutti questi mancati superamenti come una chiara indicazione che l'uso del nome di dominio non è valido."

Ripeti quelle parole, perché sono più deboli di quanto la maggior parte delle spiegazioni di DMARC ammetta. Una politica è una preferenza, pubblicata dal mittente affinché i destinatari la considerino. Non è un'istruzione che un destinatario è obbligato a eseguire. RFC 9989 lo dice in una frase: "La gestione finale di qualsiasi messaggio è sempre una questione di politica locale ed è lasciata alla discrezione del Mail Receiver." La stessa sezione aggiunge entrambi i lati della conseguenza — i destinatari "POSSONO scegliere di rifiutare o mettere in quarantena un messaggio anche se passa il controllo di convalida DMARC," e "NON DOVREBBERO rifiutare messaggi semplicemente a causa di una politica pubblicata di 'reject'," precisamente affinché la posta legittima inviata in modi che DMARC non può descrivere, e le mailing list, non vengono distrutte nel processo.

Allora cosa confessa effettivamente p=none? Meno di quanto solitamente viene accusato. Nei termini della specifica è Monitoring Mode: il proprietario del dominio sta raccogliendo rapporti aggregati e "non esprime alcuna preferenza di gestione per i messaggi che non superano la convalida DMARC," mentre un destinatario che implementa DMARC "può ancora" convalidare l'uso del dominio. Quello che non fa è disattivare nulla all'estremità ricevente. Il filtro anti-spam del tuo provider, il calcolo della reputazione, i controlli degli URL e l'analisi degli allegati sono macchinari separati che funzionano indipendentemente da ciò che il mittente ha pubblicato. Un messaggio falsificato che arriva a un dominio p=none non viene promosso al tuo inbox dal record; viene semplicemente consegnato al destinatario senza una preferenza dichiarata, e il destinatario decide.

L'altra metà del fraintendimento funziona al contrario. DMARC non legge la parte pericolosa di un'email di phishing. La sua stessa specifica elenca cosa è deliberatamente fuori portata, e "content analysis" è su quella lista, in quelle parole. Afferma anche che DMARC "non affronta l'uso di nomi di dominio visivamente simili o l'abuso del nome visualizzato human-readable RFC5322.From" — i due trucchi che caratterizzano la maggior parte della posta di brand impersonation. E sul valore di un pass: "un pass DMARC da solo non garantisce che la consegna al tuo inbox sarebbe sicura o desiderabile." Un messaggio correttamente autenticato da un dominio usa e getta passa DMARC correttamente. DMARC risponde a chi era autorizzato a usare il dominio nell'intestazione From:. Nient'altro.

Questo è dove le regole per i mittenti bulk del 2024 sono routinariamente riportate male, inclusa nella prima versione di questo articolo. Le linee guida per i mittenti di Google richiedono ai mittenti di 5.000 o più messaggi al giorno ai account Gmail di "Configurare l'autenticazione email DMARC per il tuo dominio di invio," e poi dicono, nello stesso respiro: "La tua politica di enforcement DMARC può essere impostata su none." Il Sender Hub di Yahoo, che deve essere letto separatamente piuttosto che assunto di copiare Google, dichiara il requisito come "Pubblica una politica DMARC valida con almeno p=none - DMARC deve passare," e non pubblica alcuna soglia di volume numerico. Entrambe le serie di requisiti sono entrate in vigore da febbraio 2024. Nessuna forza chiunque lontano da p=none. Quello che entrambe effettivamente forzano è l'autenticazione che si allinea: Google richiede che "il dominio nell'intestazione From: del mittente sia allineato con il dominio SPF o il dominio DKIM," e Yahoo dice che l'allineamento rilassato è accettabile. L'allineamento, non la severità, è il gate.

Il che lascia la vera ragione per cui i domini rimangono in modalità monitoraggio, ed è operazionale piuttosto che da vili. Il passaggio a quarantine o reject significa prima trovare ogni servizio che invia posta a tuo nome — buste paga, ticketing, marketing, un help desk che nessuno ha documentato — e autenticare ciascuno in modo che si allinei. Lo standard stesso riconosce i pericoli che rendono questo lento: i mittenti di terze parti non sono introdotti né esclusi da DMARC, l'inoltro e le mailing list possono rompere l'allineamento senza colpa del mittente, e la specifica punta i destinatari a RFC 7960 proprio per quei modi di guasto. Un'organizzazione che pubblica p=none e legge i suoi rapporti sta facendo il lavoro nell'ordine che la specifica descrive. Una che pubblica p=none e ignora i rapporti non lo fa. Da fuori, il record da solo non può dirvi quale dei due state guardando.

Non hai bisogno di un terminale per cercare. Strumenti di ricerca gratuiti — il domain checker di dmarcian, il DMARC check di MXToolbox — recuperano il record e stampano la politica per te. Fallo per la tua banca, il tuo provider di buste paga, la compagnia aerea su cui voli. Leggi semplicemente la risposta per quello che è: una dichiarazione di intenti dal proprietario del dominio, un input tra molti in una decisione che il tuo provider di posta prende da solo, su un tipo specifico di falsificazione. Questo è un'cosa genuinamente utile da poter leggere in dieci secondi. Non è un verdetto su se il prossimo messaggio che pretende di provenire da quel brand è sicuro.

Correzione, 20 ottobre 2026. Una versione precedente di questo articolo descriveva p=none come consegnare falsificazioni al inbox e p=reject come l'unica impostazione che blocca un messaggio spoofed, diceva che le regole per i mittenti bulk di Google e Yahoo del 2024 forzavano i mittenti lontano da p=none, e citava una figura di circa uno su tre domini in enforcement. Le descrizioni della politica sono state corrette rispetto a RFC 9989; sia Google che Yahoo infatti accettano p=none, citato sopra dalla loro stessa documentazione; e la figura dell'enforcement è stata rimossa perché il rapporto sottostante non pubblica il suo campione o denominatore. L'articolo ora afferma anche cosa DMARC non esamina.