Moltissimi domini hanno un record DMARC con p=none pubblicato anni fa e mai toccato. È un primo passo utile, perché attiva i report, ma non protegge da nulla: un messaggio falsificato che fallisce DMARC viene consegnato come se nulla fosse. La protezione reale arriva con p=quarantine e soprattutto con p=reject. Il timore di bloccare email legittime frena molte aziende, ed è un timore fondato se il passaggio si fa senza metodo. Con un percorso ordinato, invece, il rischio diventa controllabile.
Le tre policy in breve
| Policy | Cosa chiede al destinatario | Protezione |
|---|---|---|
p=none |
solo monitorare e inviare report | nessuna |
p=quarantine |
trattare come sospetti i messaggi che falliscono, di solito spam | parziale |
p=reject |
rifiutare i messaggi che falliscono durante la sessione SMTP | piena |
Ricorda che DMARC è una richiesta, non un ordine: ogni destinatario applica la policy secondo le proprie regole. In pratica i grandi provider la rispettano in modo abbastanza fedele.
Fase 1: monitoraggio e inventario
Con p=none e un indirizzo rua= attivo si raccolgono i report per almeno qualche settimana. Il periodo ideale include un ciclo completo dell'attività aziendale: fine mese, invio delle fatture, eventuali campagne stagionali. Alcuni servizi inviano poco e di rado, e sono proprio quelli che si dimenticano.
L'output di questa fase è un elenco di tutte le fonti legittime, con lo stato di ciascuna:
- server di posta principale;
- piattaforme di marketing e newsletter;
- CRM, helpdesk, sistemi di fatturazione;
- applicazioni web che inviano notifiche;
- stampanti multifunzione o scanner che inviano via SMTP;
- fornitori esterni che scrivono «a nome» dell'azienda.
Fase 2: sistemare le fonti legittime
Per ogni fonte che non supera DMARC si sceglie una soluzione:
- Configurare DKIM con il proprio dominio, se il servizio lo consente. È la soluzione preferibile.
- Usare un dominio di bounce personalizzato, così che SPF sia allineato.
- Spostare il servizio su un sottodominio dedicato, per esempio
notifiche.example.com, con autenticazione propria. - Cambiare il mittente, se il servizio non supporta nessuna delle opzioni precedenti: meglio che invii con il proprio dominio che con il tuo, non autenticato.
La fase si chiude quando, nei report, la quota di messaggi legittimi che falliscono DMARC è vicina allo zero. I residui sono di solito inoltri e mailing list, che non dipendono da te.
Fase 3: quarantena progressiva
Il tag pct= permette di applicare la policy solo a una percentuale dei messaggi che falliscono. Il percorso tipico è:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
Dopo qualche settimana senza segnalazioni si sale a 50, poi a 100. Va detto che il supporto di pct con valori intermedi non è uniforme tra i destinatari, quindi va considerato un aiuto, non una garanzia di gradualità. Durante questa fase è importante avere un canale per le segnalazioni interne: «un cliente dice che la nostra fattura è finita nello spam» è esattamente l'informazione che serve.
Fase 4: reject
Con quarantena al 100% stabile e report puliti si passa a:
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Da questo momento chi prova a usare il tuo dominio nel From da un server non autorizzato viene respinto dai destinatari che applicano DMARC. Il rifiuto avviene durante la sessione SMTP, quindi il mittente legittimo che sbaglia configurazione riceve un errore immediato, più facile da diagnosticare di un messaggio sparito nello spam.
Non dimenticare i sottodomini
Il tag sp= definisce la policy per i sottodomini. Se non è indicato, i sottodomini ereditano p=. Due errori ricorrenti:
- lasciare
sp=noneper prudenza e dimenticarlo: un attaccante può inviare dafatture.example.comsenza ostacoli; - passare a
p=rejectsenza sapere che un servizio invia da un sottodominio non configurato.
Un sottodominio che ha bisogno di una policy diversa può pubblicare il proprio record _dmarc.sottodominio.example.com, che prevale su quello del dominio principale.
Cosa può ancora andare storto
- Mailing list: alcune modificano oggetto o corpo, rompendo DKIM, e rispediscono con il proprio server, rompendo SPF. Le liste moderne riscrivono il From per evitare il problema; quelle più vecchie no.
- Inoltri semplici: SPF fallisce sempre, DKIM sopravvive se il messaggio non viene alterato.
- Nuovi servizi: il reparto marketing attiva una piattaforma nuova e i primi invii vengono rifiutati. Per questo i report vanno letti anche dopo il passaggio, non solo prima.
Nel mio lavoro consiglio di stabilire una regola semplice: nessun servizio può inviare con il dominio aziendale prima che qualcuno ne abbia verificato DKIM e allineamento.
In sintesi
p=noneserve solo a raccogliere dati; la protezione arriva con quarantine e reject.- Prima di irrigidire la policy si fa l'inventario completo delle fonti, su un ciclo di attività intero.
- Ogni fonte legittima va allineata, preferibilmente con DKIM sul proprio dominio.
- Il passaggio a quarantena può essere graduale con
pct=, poi si arriva a reject. - La policy per i sottodomini (
sp=) e la lettura dei report dopo il passaggio sono parte del lavoro.
