DMARC: che cosa deve succedere ai messaggi falsificati

Il DMARC collega SPF e DKIM a un'istruzione: osservare, mettere in quarantena o rifiutare. Come si legge il record, come si passa da p=none a p=reject e cosa dicono i rapporti.

SPF e DKIM misurano, ma non decidono niente. Un messaggio che fallisce entrambi arriva lo stesso, con qualche punto in meno: ogni destinatario si regola come crede. Il DMARC è la riga che chiude il cerchio. Dice ai server che ricevono la tua posta che cosa fare quando né l'SPF né il DKIM tornano: lasciar passare, mettere in quarantena oppure rifiutare.

E fa una seconda cosa, che quasi tutti trascurano ed è la più utile: ti fa arrivare dei rapporti. Ogni giorno i grandi operatori spediscono un riepilogo di quanti messaggi hanno visto a nome del tuo dominio, da quali server e con quale esito. È l'unico modo per sapere chi sta spedendo a nome tuo — compresi i servizi interni che hai dimenticato e i falsificatori che non hai mai visto.

Com'è fatto il record

Il DMARC è un record TXT su un nome fisso: _dmarc.<dominio>.

_dmarc.esempio.it.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@esempio.it; adkim=r; aspf=r"

Il concetto di allineamento merita una riga in più, perché è quello che sorprende. Non basta che SPF o DKIM passino: il dominio che passa deve corrispondere a quello che il destinatario vede nel mittente. Una newsletter spedita da un fornitore che firma con il proprio dominio supera il DKIM, ma non è allineata — e per il DMARC è come se avesse fallito.

Da p=none a p=reject, senza rompere niente

p=none è il modo giusto di cominciare: si osserva senza toccare nulla. È anche il modo peggiore di restare, e moltissimi domini sono fermi lì da anni.

Il passaggio si fa in tre tappe, e non c'è fretta:

Nella prima tappa leggi i rapporti e cerchi la risposta a una sola domanda: quali server spediscono a nome mio e quali di questi non superano né SPF né DKIM allineati? Ogni voce è o un tuo canale da sistemare, o qualcuno che non dovrebbe esserci. I rapporti sono file XML compressi: per un dominio piccolo si leggono anche a mano, altrimenti esistono servizi che li raccolgono e li mostrano in una tabella.

Si passa alla tappa successiva quando per due settimane di fila nei rapporti non compare più nessun canale legittimo che fallisce. Non prima.

Come si imposta

Il record sta nella zona DNS del dominio, sotto il nome _dmarc. Su Aruba, il provider più diffuso in Italia:

1. Accedi all'area clienti e apri Gestione DNS e Domini.
2. Scegli il dominio e apri la gestione dei record DNS.
3. Crea un record TXT con nome _dmarc (alcuni pannelli vogliono _dmarc.esempio.it: guarda come sono scritti gli altri record).
4. Come valore metti v=DMARC1; p=none; rua=mailto:dmarc@esempio.it.
5. Salva e verifica dopo un'ora che il record sia visibile dall'esterno.
6. Dopo due settimane di rapporti senza sorprese, cambia p=none in p=quarantine.

Su Register.it, Netsons, Serverplan, IONOS, Microsoft 365 e Google Workspace il percorso cambia solo nei nomi delle voci: si cerca la zona DNS, si crea un record TXT chiamato _dmarc, si incolla una riga. Nessuno di questi provider genera il DMARC da sé — va scritto a mano ovunque.

L'indirizzo in rua può essere una casella normale del dominio. Meglio una dedicata: i rapporti arrivano ogni giorno da decine di operatori e riempiono in fretta una casella condivisa.

I rilievi nel dettaglio

Nessun record DMARC

Sotto _dmarc.<dominio> non c'è nessun record. Chi riceve i tuoi messaggi non ha alcuna istruzione su cosa fare delle falsificazioni, e tu non ricevi nessun rapporto. È la situazione in cui chiunque può spedire a nome del tuo dominio senza conseguenze e senza che tu ne venga a sapere niente.

Che cosa fare. Pubblica un record con p=none e un indirizzo in rua. Non cambia nulla nel recapito della tua posta — è il punto: serve solo a far partire i rapporti. Dopo due settimane saprai chi spedisce a nome tuo e potrai decidere il resto con dei dati in mano.

Più record DMARC

Sotto _dmarc ci sono due o più record TXT che cominciano con v=DMARC1. Ne è ammesso uno solo: con due, i destinatari non ne scelgono uno, ignorano il DMARC del tutto. Il risultato è identico a non averlo.

Che cosa fare. Decidi quale record è quello giusto, cancella gli altri. Se i due contengono istruzioni diverse, tieni la più prudente e controlla nei rapporti che nessun canale ne risenta.

DMARC senza istruzione valida

Il campo p= manca oppure contiene un valore che non esiste — uno scambio tra p e sp, un refuso come p=quarentine, o un record che finisce prima del previsto. Senza un p valido il record è inefficace: non produce protezione e, a seconda del destinatario, nemmeno rapporti.

Che cosa fare. Riscrivi il record con uno dei tre valori ammessi: p=none, p=quarantine o p=reject. Attenzione ai separatori: i campi vanno divisi da punto e virgola, e v=DMARC1 deve essere il primo.

DMARC solo in osservazione (p=none)

Il record c'è e dice p=none: i messaggi falsificati vengono contati e segnalati nei rapporti, ma non vengono né separati né respinti. Come punto di partenza è corretto. Come stato permanente non protegge nessuno: chi imita il tuo dominio arriva in casella esattamente come prima.

Che cosa fare. Apri i rapporti. Fai l'elenco dei server che spediscono a nome tuo e, per ognuno, verifica che superi SPF o DKIM in modo allineato. Sistema quelli che non lo fanno — di solito sono uno o due servizi esterni a cui non è mai stato configurato il DKIM. Quando per due settimane i rapporti sono puliti, passa a p=quarantine, e qualche settimana dopo a p=reject.

DMARC si applica solo in parte

Il record contiene pct= con un valore inferiore a 100. L'istruzione viene quindi applicata solo a quella percentuale di messaggi; il resto passa senza controllo. È uno strumento pensato per l'introduzione graduale, ma in pratica resta quasi sempre dimenticato nel record.

Che cosa fare. Se la fase di introduzione è finita, togli pct — l'assenza equivale a 100. Se la stai ancora usando, fissa una data per l'aumento invece di lasciarla aperta: un pct=20 che dura due anni è, per venti messaggi su cento, una protezione e per gli altri ottanta niente.

DMARC senza indirizzo per i rapporti

Nel record manca rua=. L'istruzione viene applicata, ma tu non ricevi nulla: non vedi chi spedisce a nome tuo, non vedi quali dei tuoi canali falliscono, e quindi non potrai mai inasprire l'istruzione sapendo che cosa stai facendo.

Che cosa fare. Aggiungi rua=mailto:dmarc@tuo-dominio.it al record. Se preferisci un servizio esterno che raccoglie e riassume i rapporti, usa l'indirizzo che ti dà: in quel caso leggi anche il rilievo sull'autorizzazione qui sotto.

Sottodomini esclusi (sp=none)

Il record contiene sp=none: qualunque sia l'istruzione del dominio principale, per i sottodomini non vale nulla. È un problema perché le falsificazioni si spostano proprio lì — fatture.tuo-dominio.it o amministrazione.tuo-dominio.it sono schemi ricorrenti, e nessuno di questi sottodomini deve esistere davvero perché il messaggio arrivi.

Che cosa fare. Togli sp del tutto: senza quel campo l'istruzione di p si applica anche ai sottodomini. Se un sottodominio ha bisogno di un trattamento diverso — una piattaforma di invio, per esempio — dagli un record DMARC proprio invece di indebolire quello del dominio principale.

Indirizzo per i rapporti non autorizzato

L'indirizzo in rua sta su un dominio diverso dal tuo, e quel dominio non ha pubblicato l'autorizzazione necessaria. Chi spedisce i rapporti controlla questa autorizzazione e, se non la trova, non spedisce. Il record sembra perfetto e i rapporti non arrivano mai.

Che cosa fare. Sul dominio che riceve i rapporti va pubblicato un record TXT con nome <tuo-dominio>._report._dmarc.<dominio-dei-rapporti> e valore v=DMARC1;. Se usi un servizio esterno, di solito lo fa lui: cerca nella sua documentazione la voce sull'autorizzazione esterna. Se l'indirizzo è di un'agenzia o di un collaboratore, chiedi a loro di pubblicarlo.

DMARC ereditato dal dominio principale

Il nome verificato è un sottodominio e non ha un record DMARC proprio: si applica quello del dominio principale. Non è un errore — è il comportamento previsto, ed è spesso quello che si vuole.

Che cosa fare. Di norma niente. Un record proprio serve solo se questo sottodominio ha canali di invio suoi, con esigenze diverse: una piattaforma di newsletter, per esempio, che va tenuta in osservazione mentre il dominio principale è già su p=reject.

Domande frequenti

p=reject rischia di far sparire messaggi legittimi?

Sì, se ci arrivi troppo presto. Ed è esattamente il motivo delle tappe: con p=none non succede nulla, con p=quarantine i messaggi finiscono nello spam e sono recuperabili, con p=reject vengono respinti. Se i rapporti sono puliti per due settimane, l'ultimo passo è sicuro.

Chi mi manda i rapporti e che forma hanno?

I grandi operatori di posta — Google, Microsoft, Yahoo e diversi altri — spediscono una volta al giorno un file XML compresso con il conteggio dei messaggi visti per ogni server di origine e il loro esito. Non contengono contenuti né indirizzi dei destinatari: solo numeri e indirizzi IP dei server che hanno spedito.

Il DMARC serve anche se non spedisco posta da quel dominio?

Soprattutto in quel caso. Un dominio che non spedisce è il bersaglio più comodo, perché nessuno se ne accorge. Per quei domini p=reject insieme a v=spf1 -all è la scelta giusta fin dal primo giorno: ne parliamo in Ricezione.

Perché una newsletter fallisce il DMARC anche se è firmata?

Per l'allineamento. Se il fornitore firma con il proprio dominio, il DKIM passa ma il dominio firmato non corrisponde a quello che il destinatario vede nel mittente. La soluzione è far firmare i messaggi con il tuo dominio — tutti i servizi seri lo permettono e si chiama di solito «dominio di invio personalizzato» o «autenticazione del dominio». Come si fa sta su DKIM.