Record DMARC: come è fatto e cosa cambia tra none, quarantine e reject

Un record DMARC è una singola riga di testo pubblicata nel DNS, ma quella riga decide se un'email falsificata a nome del tuo dominio finisce ignorata, in quarantena o rifiutata del tutto. Capire la sintassi non richiede competenze da amministratore di sistema: bastano pochi tag da conoscere e la logica con cui si passa da una policy osservativa a una restrittiva. Per chi gestisce l'invio di email di prospezione B2B verso decisori selezionati, questo passaggio tecnico è ciò che separa un dominio percepito come affidabile da uno che i provider trattano con sospetto.

La sintassi di base, tag per tag

Un record DMARC è una stringa di testo con coppie tag=valore separate da punto e virgola, pubblicata come TXT nel DNS all'indirizzo _dmarc.tuodominio.it. Il primo tag è sempre v=DMARC1, che dichiara la versione del protocollo: senza questo prefisso esatto, all'inizio della stringa, il record viene ignorato anche se il resto è scritto correttamente.

Subito dopo viene p=, il tag obbligatorio che definisce la policy applicata al dominio: none, quarantine o reject. È l'unico tag realmente indispensabile oltre a v=, ma da solo, senza gli altri, offre poca visibilità su cosa sta succedendo davvero.

Gli altri tag sono opzionali ma in pratica quasi sempre presenti in un record ben configurato: rua= per i report aggregati giornalieri, ruf= per i report forensi su singoli messaggi falliti, pct= per la percentuale di applicazione, sp= per la policy sui sottodomini, adkim= e aspf= per il livello di allineamento richiesto a DKIM e SPF.

Policy none: osservare senza intervenire

Con p=none il dominio non chiede ai provider di destinazione di fare nulla di diverso da quello che farebbero comunque in assenza di DMARC: i messaggi che falliscono SPF o DKIM continuano a essere recapitati secondo le regole interne di ciascun provider. L'unico effetto concreto è che, se è configurato rua, si iniziano a ricevere report aggregati su chi sta inviando email a nome del dominio.

Questa fase è quasi sempre il punto di partenza corretto, e non un compromesso al ribasso: permette di scoprire, prima di restringere qualcosa, se ci sono strumenti legittimi (una piattaforma di outreach, un servizio di fatturazione elettronica, un CRM) che inviano email per conto del dominio senza essere ancora allineati correttamente con SPF o DKIM.

Il rischio di policy=none è lasciarla così indefinitamente: è la situazione più comune tra i domini che 'hanno il DMARC' solo sulla carta, senza che il record stia effettivamente proteggendo da nulla.

Policy quarantine: la via intermedia più usata

Con p=quarantine, i messaggi che falliscono l'allineamento SPF o DKIM vengono trattati dal provider di destinazione come sospetti, tipicamente indirizzati nella cartella spam invece che nella inbox principale. È il passo intermedio che la maggior parte dei domini aziendali dovrebbe raggiungere dopo un periodo di osservazione con none.

Il tag pct= diventa particolarmente utile in questa fase: impostare pct=25 significa applicare la quarantena solo a un quarto dei messaggi non conformi, un modo prudente per verificare l'impatto prima di estendere la policy al 100% del traffico. Molti team salgono gradualmente da pct=25 a pct=50, poi 100, nell'arco di alcune settimane.

Per un dominio che invia outreach B2B da più strumenti (posta principale, piattaforma di sequenze, eventuale servizio di verifica email), quarantine con pct progressivo è il modo più sicuro per scoprire tempestivamente se uno di questi strumenti non è ancora allineato, senza il rischio di perdere email legittime che finirebbero rifiutate del tutto.

Policy reject: il livello più severo

Con p=reject, i messaggi che falliscono l'allineamento vengono rifiutati dal server di destinazione prima ancora di essere consegnati, spam compreso: per il mittente illegittimo è come se il messaggio non fosse mai partito. È la protezione più efficace contro lo spoofing del dominio, ma anche la più rischiosa da attivare senza preparazione.

Il rischio principale di reject applicato troppo presto è bloccare email legittime che nessuno aveva notato: inoltri automatici, risposte da mailing list interne, o proprio lo strumento di outreach che magari autentica correttamente SPF ma non è ancora allineato su DKIM. Per questo reject va raggiunto solo dopo settimane di report puliti in quarantine.

Una volta a reject=100%, il dominio ha il massimo livello di protezione contro chi tenta di impersonarlo per inviare phishing o email fraudolente a nome dell'azienda, un rischio reale per qualunque dominio aziendale visibile pubblicamente, indipendentemente dal volume di posta che invia davvero.

Errori di sintassi che invalidano il record

Un errore frequente è dimenticare il punto e virgola tra un tag e l'altro, oppure lasciare uno spazio dove non dovrebbe esserci, per esempio scrivendo p = none invece di p=none: molti parser lo tollerano, ma non tutti, e il modo più sicuro è seguire la sintassi esatta senza spazi attorno al segno uguale.

Un secondo errore è pubblicare due record TXT distinti su _dmarc: il protocollo prevede un solo record, e la presenza di due copie, magari lasciate da una migrazione di provider mai completata, porta molti sistemi a ignorare entrambe le versioni.

Un terzo errore, meno evidente, riguarda l'indirizzo in rua=: va scritto nel formato mailto: seguito dall'indirizzo completo, per esempio mailto:dmarc@rossiimpianti.it, e se la casella indicata non esiste o non è monitorata, i report continuano a essere inviati ma nessuno li legge mai, vanificando lo scopo del monitoraggio.

• Spazi non necessari attorno al segno uguale nei tag
• Due record TXT distinti pubblicati sullo stesso _dmarc
• Indirizzo in rua= non nel formato mailto: corretto
• Passaggio diretto da none a reject senza fase intermedia di osservazione

Il tag sp= e la policy per i sottodomini

Molte aziende inviano email di prospezione non solo dal dominio principale ma anche da un sottodominio dedicato, per esempio outreach.rossiimpianti.it, separato apposta per proteggere la reputazione del dominio primario usato per la posta operativa quotidiana. Il tag sp= nel record DMARC del dominio radice serve proprio a definire quale policy si applica a tutti i sottodomini che non hanno un proprio record DMARC dedicato.

Se sp= non viene specificato, i sottodomini ereditano automaticamente la stessa policy indicata in p=. Questo comportamento va tenuto a mente quando si decide di alzare la policy del dominio principale a reject: se un sottodominio non è ancora pronto, conviene impostare sp=quarantine o addirittura sp=none in modo esplicito, finché anche quel sottodominio non ha completato il proprio percorso di allineamento.

Un sottodominio può comunque avere un proprio record DMARC indipendente, pubblicato separatamente su _dmarc.outreach.rossiimpianti.it: in quel caso il suo record ha sempre la precedenza sul tag sp= ereditato dal dominio radice.

Domande frequenti