Come leggere i report DMARC prima di applicare la policy

Una volta pubblicato un record DMARC con un indirizzo rua=, i provider di posta iniziano a inviarti report quotidiani su ogni server che usa il tuo dominio, e saper leggere i report DMARC fa la differenza tra un passaggio sicuro all'applicazione della policy e mandare per sbaglio nello spam le tue stesse fatture. Il problema è che questi report arrivano in un XML fitto, non certo pensato per essere scorso a occhio da un essere umano. Questa guida spiega esattamente cosa contiene un report aggregato, come interpretarlo per trovare la posta legittima che non supera i controlli e quando un analizzatore di report si ripaga.

In breve#

I report aggregati DMARC (quelli attivati dal tag rua=) sono file XML che un ricevente ti invia più o meno una volta al giorno. Ognuno raggruppa la posta che ha visto e che dichiarava di provenire dal tuo dominio per IP di invio e, per ogni sorgente, ti dice: quanti messaggi, se SPF e DKIM hanno superato i controlli e sono risultati allineati e cosa ha fatto il ricevente. Li leggi per costruire un inventario completo di chi invia a tuo nome e per confermare che ogni flusso legittimo si autentichi con allineamento prima di irrigidire la policy da p=none a quarantine e reject. L'XML grezzo è una sofferenza, quindi quasi tutti lo caricano in un analizzatore di report DMARC che lo trasforma in una tabella leggibile.

Hai già un report sottomano? Incollalo o caricalo nell'analizzatore di report DMARC gratuito per seguire questa guida sui tuoi dati: elabora tutto nel browser e non viene caricato nulla.

Cosa fa scattare un report aggregato#

A far scattare tutto è un solo tag del tuo record DMARC. Quando pubblichi rua= su _dmarc.yourdomain.com, chiedi a ogni ricevente che aderisce di inviarti un feedback aggregato:

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

Da quel momento i grandi riceventi (Google, Yahoo, Microsoft, Comcast e molti altri) raccolgono tutto ciò che hanno visto dal tuo dominio in una finestra di 24 ore e inviano un unico report XML per dominio. Di solito il report arriva come allegato compresso (.xml.gz o .zip), con un nome file che indica il mittente del report, il tuo dominio e l'intervallo di date. Puoi indirizzare rua a più indirizzi e puoi persino raccogliere i report di un dominio che non controlli usando una destinazione esterna, anche se questo richiede un record di autorizzazione aggiuntivo sul dominio che riceve. Se non hai ancora pubblicato un record, parti dalla guida passo passo alla configurazione di DMARC: i report iniziano ad arrivare solo quando il record è attivo.

Come leggere un report aggregato DMARC, riga per riga#

Ogni report aggregato segue lo stesso schema XML, definito nell'RFC 7489, poi resa obsoleta dagli RFC 9989 e 9990. Ha tre parti: chi ha inviato il report, quale policy avevi pubblicato in quel momento e poi uno o più blocchi <record>, uno per ogni sorgente di invio. Ecco un esempio ridotto di un singolo record:

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>128</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

La cosa più importante da capire è che un report riporta il risultato di autenticazione in due punti diversi, e i due hanno significati differenti:

Il blocco auth_results indica se SPF e DKIM hanno superato i controlli di per sé. Il blocco policy_evaluated indica se li hanno superati con allineamento, che è l'unica cosa che interessa a DMARC. I due possono non coincidere, ed è in quello scarto che si svolge gran parte del tuo lavoro di indagine.

Individuare una sorgente legittima che non supera i controlli#

Ecco lo schema da cercare, e perché conta. Immagina un record in cui il source_ip appartiene chiaramente a una piattaforma di marketing che usi, l'header_from è il tuo dominio e auth_results mostra spf: pass, ma il dominio SPF indicato è il dominio di bounce della piattaforma, non il tuo, e policy_evaluated/spf riporta fail. Quel messaggio si è autenticato per qualcuno, ma non per te in modo allineato. Con p=none la disposition resta none, quindi non si è rotto niente, per ora. Nel momento in cui passi a quarantine o reject, ogni messaggio di quel count inizia a finire nello spam o a venire respinto.

La lettura è quindi sempre lo stesso confronto in tre passaggi:

• Identifica la sorgente. Associa ogni source_ip a un servizio reale. Di solito basta una rapida ricerca DNS inversa o l'etichettatura integrata nell'analizzatore per dargli un nome. L'obiettivo è un elenco completo: i report fanno regolarmente emergere uno strumento di fatturazione dimenticato o una vecchia piattaforma di campagne che invia ancora a tuo nome.
• Controlla l'allineamento, non solo l'autenticazione. Guarda policy_evaluated, non auth_results. Una sorgente può superare SPF o DKIM e non superare comunque DMARC, perché il dominio per cui si è autenticata non corrisponde al tuo "From".
• Decidi: correggerla o lasciarla fallire. Se la sorgente è legittima, correggine l'allineamento: aggiungila a SPF o, meglio ancora, configura la firma DKIM sul tuo dominio così che il dominio di firma corrisponda. Se è spoofing, il fallimento è esattamente ciò che vuoi, ed è la prova che il tuo futuro p=reject farà il suo lavoro.

Di solito conviene dare la priorità all'allineamento DKIM rispetto a quello SPF, perché una firma DKIM viaggia con il messaggio e sopravvive all'inoltro, mentre l'allineamento SPF si rompe nel momento in cui la posta viene inoltrata. I meccanismi dell'allineamento, cioè relaxed o rigoroso (strict), dominio organizzativo o corrispondenza esatta, sono trattati in SPF, DKIM e DMARC spiegati, se hai bisogno di soffermarti sul concetto.

RUA e RUF: due report molto diversi#

DMARC definisce due tag di reporting, e non sono intercambiabili:

• rua: report aggregati. I riepiloghi XML quotidiani descritti sopra. Contengono conteggi e risultati raggruppati per sorgente, nessun contenuto dei messaggi, e sono quelli su cui ti basi per tutta la transizione. Ogni ricevente serio li invia.
• ruf: report forensi (di errore). Report per singolo messaggio, generati nel momento in cui un messaggio non supera i controlli. Storicamente potevano includere le intestazioni e talvolta parti del messaggio, il che significa che possono contenere dati personali.

Poiché i report forensi possono esporre informazioni sui destinatari, la maggior parte dei grandi provider ha smesso di inviarli anni fa per motivi di privacy, e molti mittenti non pubblicano affatto ruf. Un record che li richiede entrambi ha questo aspetto:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:agg@example.com; ruf=mailto:forensic@example.com"

In pratica riceverai un flusso costante di report aggregati rua e pochi report forensi ruf, o nessuno. Imposta il monitoraggio sui dati aggregati, considera un extra occasionale gli eventuali report forensi che ricevi e attiva ruf solo se hai una base giuridica e un posto dove conservare quelli che possono essere dati personali.

Perché ti serve un analizzatore e non una casella piena di XML#

Puoi aprire l'XML a mano e, per un singolo dominio con due o tre mittenti, per un po' è sopportabile. Ma smette presto di essere sostenibile. Un dominio molto attivo genera decine di report al giorno da riceventi diversi, ognuno con molti IP di origine, e il segnale interessante (un mittente legittimo che, senza dare nell'occhio, non risulta allineato) resta sepolto tra tag con timestamp Unix e indirizzi IP senza etichetta. I migliori strumenti di monitoraggio DMARC li confronta secondo i criteri che contano.

Un analizzatore di report DMARC o una dashboard di monitoraggio riceve i report su un indirizzo dedicato, decomprime e analizza l'XML, associa gli IP a nomi di servizi riconoscibili e riassume tutto in una tabella che puoi leggere davvero: le sorgenti da un lato, i volumi di pass e fail dall'altro, le tendenze nel tempo. I migliori segnalano le sorgenti nuove o che hanno appena iniziato a fallire, così noti un cambiamento senza rileggere ogni file. Che tu usi un servizio in hosting o un parser self-hosted, il lavoro è lo stesso: trasformare un mucchio di XML in "ecco chi invia a tuo nome ed ecco chi non è ancora allineato". È questa chiarezza che rende i report utili invece che semplicemente archiviati.

Come si inserisce in una transizione sicura#

Leggere i report non è un compito separato dalla configurazione di DMARC: è il cuore stesso della transizione, e saltarlo è il modo in cui si finisce per affossare la propria posta. La sequenza:

1. Pubblica p=none con rua. Non cambia nulla nel modo in cui viene gestita la tua posta: si attivano semplicemente i report.
2. Leggi i report aggregati per un intero ciclo di invio. Un paio di settimane come minimo, di più se hai flussi poco frequenti come gli estratti conto mensili. Costruisci l'inventario completo delle sorgenti.
3. Correggi ogni sorgente legittima non allineata. È qui che si spende davvero il tempo, ed è qui che i report ti guidano.
4. Passa a quarantine, poi a reject. Solo quando i report mostrano che ogni flusso autentico supera i controlli con allineamento. p=reject è l'impostazione che ferma davvero lo spoofing e soddisfa le regole per i mittenti di grandi volumi nei requisiti per i mittenti di Google e Yahoo.

I report continuano a essere utili anche dopo che sei arrivato a reject: è grazie a loro che scopri un nuovo strumento SaaS che inizia a inviare a tuo nome o una campagna di spoofing che si intensifica contro il tuo brand. Seguirli insieme alle segnalazioni dei feedback loop e alla reputazione del mittente complessiva ti dà un sistema di allerta precoce e non un'attività di configurazione una tantum. I report DMARC di Qualisend trasformano i report aggregati di ogni dominio in una tabella delle sorgenti di invio con conteggi di superamento e fallimento, così un nuovo mittente emerge senza aprire l'XML grezzo. Per una routine settimanale costruita attorno a quella tabella, vedi il monitoraggio DMARC.

Un limite onesto: superare DMARC con allineamento dimostra chi sei, non che sei un buon mittente. Un dominio perfettamente allineato che scrive a indirizzi morti o a spam trap finisce comunque nello spam: l'autenticazione è il biglietto d'ingresso, mentre sono la qualità della lista e il coinvolgimento a decidere il posizionamento. Questo quadro più ampio è l'argomento della guida alla deliverability delle email, ed è il motivo più comune per cui la posta legittima finisce comunque nello spam anche con report puliti.

I report aggregati ti dicono chi sta inviando a tuo nome; non ti dicono se la lista dietro quella posta è pulita. Fai passare i tuoi indirizzi nella verifica email gratuita per eliminare domini morti, errori di battitura e spam trap prima che generino bounce: anche un dominio perfettamente allineato ha bisogno di una lista sana per guadagnarsi la posta in arrivo.