Implementare il DMARC: da none a reject

Modulo 4: Recapitabilità: SPF, DKIM e DMARC nella pratica · Tempo di lettura: 12 minuti

Obiettivo della lezione: Al termine di questa lezione sarà in grado di spiegare come funziona l'allineamento, pianificare un'implementazione del DMARC in fasi da p=none a p=reject, scegliere i tag corretti (rua, sp, np, t) e gestire le insidie note legate al reindirizzamento e alle mailing lists.

Concetti chiave: DMARC (RFC 9989), Author Domain (il dominio nel campo Da), allineamento (alignment), relaxed e strict (adkim, aspf), dominio organizzativo, DNS tree walk, p=none, p=quarantine, p=reject, rua, sp, np, t=y (modalità di test), tag obsoleti pct, rf, ri, mailing lists, riscrittura del From, ARC

Cosa controlla esattamente il DMARC

Il DMARC risponde a una sola domanda per ogni mail in arrivo: SPF o DKIM sono passati per un dominio che corrisponde all'indirizzo Da? Il dominio nell'indirizzo Da si chiama, nello standard, Author Domain. Le basi del record sono spiegate nel corso DNS, lezione 4.5. Nel maggio 2026 è stata pubblicata la versione rivista dello standard: RFC 9989, con RFC 9990 per i rapporti aggregati e RFC 9991 per i rapporti di errore. I record esistenti con v=DMARC1 restano semplicemente validi.

L'allineamento nella pratica

"Corrisponde" si chiama allineamento (alignment). Esistono due modalità:

• relaxed (predefinita): i domini hanno lo stesso dominio organizzativo. nieuws.example.com e example.com sono allineati; example.com e example.net no.
• strict (adkim=s o aspf=s): i domini devono essere esattamente identici.

Per l'SPF, il DMARC confronta il dominio del Return-Path con il dominio Da. Per il DKIM, il dominio d= di una firma valida. Alcuni esempi per una mail con Da: info@example.com:

Mantenga quindi adkim e aspf su relaxed, a meno che non abbia un buon motivo per non farlo.

Come fa un destinatario a sapere qual è il dominio organizzativo? In passato si usava la Public Suffix List, un elenco di domini come .nl, .co.uk e github.io. L'RFC 9989 la sostituisce con un DNS tree walk: il destinatario cerca i record _dmarc del dominio e dei domini superiori. Per un utente comune non cambia nulla; lo si nota solo se si lavora con record su sottodomini.

L'implementazione in quattro fasi

L'obiettivo è p=reject: in questo modo i destinatari rifiutano la posta che si spaccia per Lei, ed è questa la migliore protezione contro le fatture false e il phishing a Suo nome. Ma chi passa subito a reject senza conoscere i propri mittenti rischia di bloccare le proprie stesse fatture. Per questo si consiglia il seguente ordine (la linea guida di questo corso):

Fase 0: preparazione

• Crei l'inventario di tutti i Suoi mittenti (lezione 4.2).
• Si assicuri che ogni mittente abbia SPF o DKIM allineati; preferibilmente DKIM, perché sopravvive al reindirizzamento.
• Crei un indirizzo dedicato ai rapporti, ad esempio dmarc@example.com, oppure utilizzi un servizio di raccolta rapporti. Riceverà rapidamente diversi rapporti al giorno.

Fase 1: misurazione con p=none

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

p=none non fa nulla sulla mail stessa. I destinatari recapitano tutto come di consueto, ma Le inviano quotidianamente un rapporto aggregato (aggregate report) con ogni server che ha inviato posta a nome del Suo dominio e se SPF, DKIM e DMARC sono passati. In questo modo soddisfa anche il requisito minimo di Gmail, Yahoo e Microsoft per i mittenti di grandi volumi (lezione 5.3).

Mantenga questa impostazione per almeno due o quattro settimane, e più a lungo se ha servizi che inviano posta solo saltuariamente (un promemoria annuale, una fattura trimestrale). Legga i rapporti (lezione 4.5) e corregga ogni fonte propria che risulti non conforme.

Fase 2: p=quarantine

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

La posta che non supera il DMARC finisce, presso il destinatario, nella cartella spam. Se Lei dimentica comunque una fonte, quella mail non va perduta, ma diventa difficile da trovare. Se vuole procedere con cautela, aggiunga prima t=y (modalità di test): i destinatari applicano allora una politica di un livello più mite (per quarantine, quindi none), ma nei rapporti vede cosa accadrebbe. Nell'RFC 9989 questo sostituisce il vecchio tag pct=.

Osservi di nuovo i rapporti per qualche settimana.

Fase 3: p=reject

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

La posta che non supera il DMARC viene rifiutata. Il mittente riceve un bounce, presso Microsoft ad esempio con il codice 5.7.509 e presso Gmail con un riferimento alla policy DMARC (modulo 6). Continui a seguire i rapporti: compaiono sempre nuovi servizi.

Quando si può procedere più velocemente?

Se tutta la Sua posta passa attraverso un unico fornitore che gestisce SPF e DKIM per Lei, e nessun altro invia posta a nome del Suo dominio, può applicare subito una politica rigorosa. Alcune aziende di hosting impostano per questo p=reject come valore predefinito. Se in seguito desidera comunque utilizzare un servizio di newsletter o un programma di contabilità, lo riporti temporaneamente su p=none con un indirizzo per i rapporti, finché quel servizio non sia configurato correttamente.

Gli altri tag

Un indirizzo per i rapporti su un dominio diverso (ad esempio un servizio di raccolta rapporti) funziona solo se quel dominio concede l'autorizzazione con un record come example.com._report._dmarc.rapportdienst.example. Il servizio in genere se ne occupa autonomamente (RFC 9990, capitolo 4).

Insidie

Mailing lists

Una mailing list classica inoltra la Sua mail a tutti gli iscritti, dal proprio server, e spesso aggiunge [lista] all'oggetto o un testo a piè di pagina. In tal caso l'SPF fallisce (server diverso) e il DKIM fallisce (mail modificata). Con p=reject i destinatari rifiutano il Suo messaggio inviato alla lista. I software per mailing list moderni risolvono il problema riscrivendo l'indirizzo Da con l'indirizzo della lista ("Jan via Leden"), oppure inoltrando la mail senza modifiche. Se utilizza una lista che non lo fa, lo noterà nei Suoi rapporti.

Reindirizzamento

Veda la lezione 3.3: l'SPF si rompe, il DKIM in genere sopravvive. Un destinatario può, tramite ARC, decidere di fidarsi di un reindirizzatore noto. Nei rapporti lo riconosce come posta proveniente da un server sconosciuto con DKIM pass e SPF fail; non è questo un motivo per rendere più permissiva la Sua policy.

Due record o un errore di battitura

Due record DMARC su _dmarc rendono la policy non valida, così come un errore di battitura in p= (p=rejected non esiste). Verifichi dopo ogni modifica.

Nella pratica: come si presenta in un pannello

Con un pacchetto di hosting WebOké è impostato come predefinito v=DMARC1;p=reject, senza indirizzo per i rapporti. È sicuro se tutta la Sua posta passa attraverso quei server. Se invia posta anche tramite altri servizi, lo imposti su p=none con un indirizzo rua e segua le fasi descritte. In DirectAdmin lo fa in Amministrazione DNS con la matita accanto al record _dmarc (campi Tipo di policy del dominio e Email aggregata (RUA)); in Mio WebOké con l'assistente DMARC nella scheda DNS. Presso altri fornitori crea un record TXT sul nome _dmarc e digita Lei stesso il testo; il risultato è lo stesso.

Riepilogo

• Il DMARC riesce se SPF o DKIM riescono per un dominio allineato con il dominio Da; l'allineamento relaxed accetta i sottodomini.
• Implementazione: inventario, p=none con rua e lettura dei rapporti, p=quarantine (eventualmente con t=y), e poi p=reject.
• Utilizzi np=reject per i sottodomini inesistenti non appena la policy principale è rigorosa. pct, rf e ri sono obsoleti.
• Le mailing lists e il reindirizzamento causano errori prevedibili; DKIM e ARC ne compensano in parte gli effetti.
• Esattamente un solo record su _dmarc, senza errori di battitura.

Quiz

Esercizio

Esercizio Z4.4: Verificare il DMARC del proprio dominio e scegliere il passo successivo. Inserisca il Suo dominio (oppure internet.nl). Inserisca il record DMARC così come lo ha trovato, il valore di p= e se contiene un indirizzo rua. Scelga poi quale fase dell'implementazione ritiene sia il passo successivo, e perché. Il programma interroga il record in tempo reale, ne verifica la sintassi secondo l'RFC 9989 (un solo record, p valido, tag noti, tag obsoleti come avviso), e affianca le Sue risposte al risultato.

Per approfondire

I passaggi descritti in questi articoli si applicano ai pannelli di WebOké; presso altri fornitori il funzionamento è simile.

• Corso gratuito DNS 4.5: DMARC: cosa devono fare i destinatari con le email false
• Guida DirectAdmin 5.9: DMARC impostare
• Che cos'è il DMARC? Spiegazione in parole semplici
• Creazione del record DMARC in DirectAdmin
• RFC 9989 (DMARC), in particolare il paragrafo 4.7 (tag) e l'appendice C (modifiche rispetto all'RFC 7489)