Pubblicare un record DMARC con il tag rua= è come accendere una telecamera sul proprio dominio. Ogni giorno i grandi provider di posta inviano all'indirizzo indicato un riepilogo di tutti i messaggi che hanno ricevuto con il tuo dominio nel From: da quali server sono partiti, quanti erano, se hanno superato SPF e DKIM. Il problema è che questi report arrivano in XML compresso e, aperti la prima volta, sembrano illeggibili. Imparare a leggerli è il passaggio che separa un DMARC decorativo da uno che protegge davvero.
Come si attivano
Basta indicare nel record DMARC un indirizzo di destinazione:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"
Se l'indirizzo appartiene a un dominio diverso da quello monitorato, il dominio ricevente deve pubblicare un record di autorizzazione, altrimenti i provider non inviano i report. È un meccanismo pensato per impedire che qualcuno inondi di report una casella altrui.
Conviene usare una casella dedicata: anche un dominio piccolo riceve decine di report al giorno, e una casella personale diventa rapidamente ingestibile.
La struttura di un report
Ogni report è un file XML, di solito compresso in zip o gzip, diviso in tre parti.
Metadati
Indicano chi ha generato il report (org_name), l'identificativo del report e l'intervallo temporale coperto, espresso in timestamp Unix. In genere l'intervallo è di 24 ore.
Policy pubblicata
Riporta la policy che il destinatario ha letto nel tuo DNS al momento della valutazione: p, sp, adkim, aspf. Serve a verificare che il record sia stato interpretato come pensavi.
Record
È la parte importante. Ogni elemento record raggruppa i messaggi provenienti da uno stesso indirizzo IP con gli stessi risultati. Un esempio semplificato:
<record>
<row>
<source_ip>192.0.2.25</source_ip>
<count>312</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<dkim><domain>example.com</domain><result>pass</result></dkim>
<spf><domain>bounce.example.net</domain><result>pass</result></spf>
</auth_results>
</record>
Leggere un record senza confondersi
Il punto che genera più errori è la differenza tra policy_evaluated e auth_results.
auth_resultsriporta i risultati grezzi di SPF e DKIM, con il dominio su cui sono stati valutati.policy_evaluatedriporta il risultato ai fini DMARC, cioè tenendo conto dell'allineamento.
Nell'esempio, SPF in auth_results è pass, ma sul dominio bounce.example.net, che non corrisponde al From. Per DMARC quindi SPF risulta fail. DKIM invece passa ed è allineato, perché la firma è di example.com. Il messaggio supera DMARC grazie a DKIM. La disposition indica cosa ha fatto il destinatario: none, quarantine o reject.
Classificare le fonti
L'obiettivo pratico è costruire un elenco di tutte le sorgenti che inviano con il tuo dominio e classificarle in tre gruppi.
| Gruppo | Come riconoscerlo | Azione |
|---|---|---|
| Legittime e configurate | DKIM o SPF allineati in pass | nessuna |
| Legittime ma non configurate | IP di un tuo fornitore, DMARC fail | configurare DKIM o il dominio di bounce |
| Illegittime | IP sconosciuti, spesso volumi variabili | lasciare che la policy le blocchi |
Per identificare un IP si parte dal record PTR e dal proprietario del blocco di indirizzi. Un IP che appartiene al fornitore della tua piattaforma di newsletter è quasi certamente legittimo; uno che risolve verso una connessione residenziale in un altro continente, con poche decine di messaggi tutti falliti, molto probabilmente no.
Attenzione a un caso frequente: gli inoltri. Quando un destinatario inoltra automaticamente la posta a un'altra casella, il messaggio arriva da un server che non è tuo. SPF fallisce, ma DKIM spesso resta valido. Questi record compaiono come IP di provider noti con DKIM in pass e SPF in fail: non sono attacchi.
Strumenti per non leggere XML a mano
Leggere i file uno per uno funziona per capire il formato, non per lavorare. Esistono servizi commerciali che raccolgono e visualizzano i report, e strumenti open source che li analizzano e li caricano in un database o in una dashboard. Nel mio lavoro preferisco una soluzione che conservi i dati grezzi: quando si investiga un'anomalia serve tornare al singolo record.
Esistono anche i report forensi (ruf=), che contengono dettagli sui singoli messaggi falliti. Molti grandi provider non li inviano per motivi di riservatezza, quindi non conviene contarci.
Una routine di controllo
- Ogni settimana, verificare che i volumi delle fonti note siano coerenti con l'attività reale.
- Cercare nuove fonti con DMARC fail e volumi significativi: spesso è un reparto che ha attivato un servizio senza avvisare.
- Controllare che nessuna fonte legittima dipenda solo da SPF.
- Prima di irrigidire la policy, assicurarsi che le fonti legittime non allineate siano zero o trascurabili.
In sintesi
- I report aggregati arrivano in XML, uno per provider e per giorno, all'indirizzo indicato in
rua=. auth_resultsmostra i risultati grezzi,policy_evaluatedquelli che contano per DMARC.- L'obiettivo è classificare ogni sorgente come legittima configurata, legittima da sistemare o illegittima.
- Gli inoltri producono SPF fail con DKIM pass e non vanno scambiati per attacchi.
- Uno strumento di aggregazione è indispensabile oltre i primi giorni di monitoraggio.
