Una policy p=none non blocca nessun messaggio, mentre una policy p=reject preparata male ne blocca di legittimi. Nel mezzo, DMARC lascia fuori il display name e i domini simili; anche un account compromesso gli sfugge. In sintesi: il protocollo ferma lo spoofing esatto del dominio del mittente e nient’altro, mentre la sua messa in opera espone a email dei clienti perse e a mittenti terzi dimenticati. I limiti si compensano con altri strumenti; i rischi si tengono sotto controllo con un’adozione graduale.
La dashboard dello strumento di emailing mostra «tutto OK» e le campagne finiscono comunque in spam: l’autenticazione è uno dei primi punti da controllare. Sul fronte delle frodi, l’FBI quantifica in 3,05 miliardi di dollari le perdite legate al Business Email Compromise (24.768 denunce) nel suo rapporto IC3 2025, contro i 2,77 miliardi del 2024 (21.442 denunce).
Cosa controlla DMARC
DMARC si appoggia a SPF e DKIM. Un messaggio supera il controllo se almeno uno dei due passa e se il dominio autenticato è allineato con quello dell’intestazione From, campo definito dalla RFC 5322. L’allineamento è il punto che i team scoprono per ultimo: un SPF valido per il dominio di un fornitore non basta quando l’indirizzo visualizzato porta il vostro. In caso di errore, il destinatario applica la policy pubblicata dal proprietario del dominio: quarantine manda in spam, reject rifiuta il messaggio, none non fa nulla.
Due impostazioni definiscono il rigore di questo allineamento. Di default è «relaxed»: mail.esempio.it si allinea con esempio.it, perché condividono lo stesso dominio organizzativo. In modalità «strict», impostata con adkim=s per DKIM e aspf=s per SPF, i due nomi devono essere identici. La modalità strict chiude delle porte, ma manda in crisi anche i fornitori che firmano con un sottodominio, cosa che si scopre raramente prima del passaggio a reject.
Lo standard stesso delimita il proprio perimetro. Da maggio 2026 è la RFC 9989 (percorso Standards Track dell’IETF) a definire DMARC, sostituendo le RFC 7489 (marzo 2015) e 9091 (2021). La sezione 2.2 precisa che DMARC non tratta né i domini visivamente simili né l’abuso del nome leggibile del mittente, e la sezione 2.4 colloca gli attacchi via display name fuori dal campo di applicazione: il testo del 2015 diceva già la stessa cosa.
Display name e domini simili: due punti ciechi documentati
Un messaggio che appare come «Servizio clienti Banca X» e viene inviato da support@banca-x-sicurezza.com supera DMARC senza difficoltà. Il dominio di invio appartiene all’attaccante, che vi ha pubblicato il proprio SPF e la propria chiave DKIM: SPF, DKIM e DMARC sono quindi tutti in verde. Il controllo riguarda il dominio tecnico; il nome che il client di posta mette in evidenza non viene esaminato.
I domini simili (typosquatting, trattini aggiunti, estensione diversa) seguono la stessa logica: il vostro record protegge il vostro dominio, non quelli che gli somigliano. La contromisura sta nel monitoraggio delle registrazioni di domini vicini al vostro e nel filtraggio lato ricezione.
Un account compromesso supera tutti i controlli
Una casella le cui credenziali sono trapelate invia dall’infrastruttura giusta, con la firma giusta. Il punto d’ingresso è spesso un phishing o una fuga di dati; DMARC non ha nulla da rilevare, perché il messaggio è autentico. L’autenticazione a più fattori e gli avvisi sugli accessi insoliti agiscono a monte, fuori dal perimetro del protocollo.
Inoltri e mailing list: l’allineamento si spezza lungo il percorso
Quando un alias aziendale o una mailing list ritrasmette un messaggio, l’IP del relay non compare nell’SPF del dominio d’origine; SPF quindi fallisce, in genere. Resta DKIM, che sopravvive finché il contenuto firmato non viene modificato. Una lista Mailman o Listserv che aggiunge un footer invalida la firma: il messaggio legittimo fallisce entrambi i controlli.
La RFC 9989 (sezione 7.4) porta l’esempio di una banca i cui clienti hanno fornito un indirizzo da ex studente, del tipo jones@alumni.example.edu, che inoltra verso un’altra casella: il messaggio arriva dall’IP del relay, assente dall’SPF del mittente (RFC 5321 del 2008, MailFrom), salvo riscrittura. Le firme DKIM (RFC 6376 del 2011) restano in genere valide finché il corpo del messaggio non viene modificato. Una mailing list che aggiunge un footer le invalida.
La RFC 9989 (sezione 7.4, che rimanda alla RFC 7960 del 2016 sulle mailing list) ne ricava due indicazioni: un dominio in p=reject non deve affidarsi al solo SPF e deve firmare con DKIM; un dominio i cui utenti scrivono a mailing list pubbliche non dovrebbe pubblicare p=reject. Il protocollo ARC (Authenticated Received Chain, RFC 8617 del luglio 2019) serve a preservare il risultato di autenticazione originale, a condizione che il relay l’abbia attivato.
Sottodomini: vince il dominio o il sottodominio?
Il sottodominio prevale non appena pubblica un proprio record; altrimenti eredita quello del dominio padre. La RFC 9989 lo esprime in due regole. Il destinatario cerca prima un record sul dominio esatto del From, poi risale l’albero DNS (DNS tree walk, sezione 4.10, limitato a 8 query DNS): un record specifico del sottodominio ha quindi la precedenza su quello del padre. E senza il tag sp=, la policy p= del dominio principale si applica ai sottodomini.
Conseguenza pratica: un _dmarc.newsletter.esempio.it rimasto in p=none dopo un test lascia quel perimetro in semplice monitoraggio, mentre esempio.it è in reject. Nel senso opposto, un sp=none sul dominio principale lascia aperti tutti i sottodomini privi di record; utile durante l’audit, da togliere dopo. Il tag sp= viene ignorato in un record pubblicato su un sottodominio. Dalla RFC 9091, ripresa dalla RFC 9989, un tag np= regola inoltre il caso dei sottodomini che non esistono nel DNS.
p=none, la modalità di monitoraggio che dà una falsa sensazione di sicurezza
Il record esiste e il controllo di conformità passa; nulla viene bloccato. Google precisa nella sua pagina sull’adozione, consultata il 27 ottobre 2026, che con p=none i messaggi vengono recapitati normalmente. Un dominio che ci resta per anni continua ad accettare i messaggi contraffatti.
p=reject: le email legittime che spariscono
Passato in reject, un dominio vede rifiutato ogni mittente il cui SPF e il cui DKIM non sono allineati. L’ufficio HR invia le buste paga con uno strumento esterno, il supporto passa da un helpdesk e la fatturazione da un modulo SaaS: ciascuno scrive a nome del dominio e verrà rifiutato il giorno del passaggio se non è allineato. Google è esplicito: i messaggi che falliscono il controllo vengono rifiutati e mai recapitati. In quarantine, nel migliore dei casi finiscono nella cartella spam. I report rua del giorno dopo elencano allora gli IP i cui messaggi sono falliti, compresi quelli che nessuno aveva censito. Da qui l’utilità di passare da quarantine, poi di segnalare la fase di prova con t=y prima di ogni reject.
I fornitori di invio creano la trappola più frequente. Su un IP condiviso o dedicato, l’SPF convalida il dominio del fornitore; l’allineamento DMARC dipende allora da una firma DKIM a nome del vostro dominio, salvo Return-Path personalizzato. Senza di essa, la campagna fallisce fin dal primo passaggio a reject. La chiave DKIM si pubblica sotto un selettore dedicato, nella forma selettore._domainkey.esempio.it; la firma deve riportare il dominio del From.
Errori nel TXT e limite SPF di 10 query DNS
Basta un errore di configurazione per neutralizzare DMARC senza alcun avviso. Il DNS non lo segnala: il record si pubblica senza validazione, quindi un refuso nella zona emerge solo leggendo i report, qualche giorno dopo. Un record spezzato in due stringhe unite male, una virgoletta tipografica incollata da un word processor o un punto e virgola dimenticato tra due tag sono sufficienti. Due record DMARC sullo stesso nome? La RFC 9989 scarta allora tutti i record trovati in quel punto (sezione 4.10). Un v=DMARC1 scritto male fa ignorare l’intero record; un tag sconosciuto viene ignorato senza avviso; un errore in rua= toglie i report senza rompere nulla di visibile. Un indirizzo di report ospitato su un altro dominio richiede inoltre un record di autorizzazione presso quest’ultimo (RFC 9990).
Sul fronte SPF, la RFC 7208 (sezione 4.6.4) limita la valutazione a 10 query DNS: include, a, mx, ptr, exists e redirect contano, ip4 e ip6 no. Le query a vuoto sono limitate a 2. Oltre, il risultato è permerror (limite già presente nella RFC 4408 dell’aprile 2006) e SPF smette di contribuire a DMARC. Ogni strumento aggiunto tramite un include avvicina il dominio a questa soglia.
Limiti e rischi in una tabella
| Caso | Perché | Cosa fare |
|---|---|---|
| Display name falsificato | DMARC controlla il dominio del From; il nome visualizzato gli sfugge | Filtro anti-phishing in ricezione, sensibilizzazione |
| Dominio simile | Dominio terzo con i propri SPF, DKIM e DMARC | Monitoraggio dei domini vicini, registrazioni difensive |
| Account compromesso | Il messaggio è autentico | MFA, avvisi di accesso |
| Inoltro, mailing list | SPF fallisce; DKIM fallisce se il contenuto cambia | DKIM su tutti i flussi, ARC |
| Sottodominio | Eredità di p=; un record proprio prevale |
Inventario, sp= scelto con consapevolezza |
p=none prolungato |
Nessuna azione sui messaggi che falliscono | Calendario di passaggio a quarantine |
p=reject troppo presto |
Mittente terzo non allineato | Inventario, report rua, prova con t=y |
| SPF oltre le 10 query | permerror, SPF non conta più | Togliere gli include inutili, firmare con DKIM |
| Errore nel TXT | Record o tag ignorati | Un solo record, rilettura della sintassi |
Passare da none a reject senza perdere email
Il percorso si articola in tre tempi: censire i mittenti, osservare in none, poi irrigidire per gradi passando da quarantine prima di reject. Tutto comincia dall’inventario dei mittenti: strumento di emailing, CRM, helpdesk, paghe, fatturazione, server applicativi. I team ne dimenticano sempre uno; i report aggregati rua servono a ritrovarlo, perché elencano ogni IP che ha inviato a nome del dominio con il suo risultato SPF e DKIM.
I passaggi sono sempre gli stessi: p=none, lettura dei report, quarantine, poi reject. Nella guida di Google Workspace, Google raccomanda di configurare SPF e DKIM almeno 48 ore prima di pubblicare DMARC, di restare in p=none per una settimana con una lettura quotidiana dei report, poi di passare a quarantine su una piccola percentuale di messaggi: 10% per una piccola organizzazione, 1% per una grande (pagina «Implementazione DMARC consigliata»). Un record di partenza assomiglia a v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@esempio.it, pubblicato in TXT su _dmarc.esempio.it. Attenzione: il tag pct= della RFC 7489 non esiste più nella RFC 9989, che osserva come fosse applicato in modo molto disomogeneo al di fuori dei valori 0 e 100 e lo sostituisce con t=y (prova) o t=n. La stessa RFC 9989 raccomanda di pubblicare p=none per almeno un mese, basandosi sui report aggregati.
Il tempo di ogni passaggio dipende dal numero di flussi: con poche fonti di invio, una settimana di report può bastare a censirle; con 20 strumenti, i mittenti dimenticati emergono report dopo report. Durante la salita, un sp= distinto permette di irrigidire il dominio principale mentre i sottodomini non ancora verificati restano in none.
Gmail, Yahoo e la deliverability
Dal 1° febbraio 2024, Google richiede ai mittenti di oltre 5.000 messaggi al giorno verso Gmail un SPF e un DKIM validi, più una policy DMARC; può restare su none. Il tasso di spam mostrato in Google Postmaster Tools deve restare sotto lo 0,30%, con un obiettivo sotto lo 0,10% (linee guida di Google per i mittenti). Yahoo, che applica le sue regole ai mittenti in massa da febbraio 2024, chiede anch’esso un DMARC almeno in none, con un dominio From allineato su SPF o DKIM (best practice di Yahoo). Il dettaglio lato Gmail si trova nell’articolo sui requisiti di Gmail per i mittenti.
DMARC apre quindi la porta della posta in arrivo senza fissare la reputazione del mittente. Questa reputazione dipende dal tasso di reclami e dai rimbalzi: un dominio in reject che scrive a una lista piena di indirizzi morti alimenta gli hard bounce e danneggia la propria deliverability. Far passare un campione della lista in uno strumento di verifica prima della prossima campagna mostra questo tasso prima che Gmail lo misuri.
Il vostro prossimo report rua contiene una fonte di invio che nessuno nel team riconosce?
