Leggere i rapporti DMARC

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

Obiettivo formativo: Dopo questa lezione sarà in grado di aprire e leggere un rapporto aggregato DMARC, determinare per ogni riga quale sia la fonte e perché risulti promossa o bocciata, e decidere cosa riparare, cosa può ignorare e quando può inasprire la Sua policy.

Concetti chiave: rapporto aggregato (aggregate report, RFC 9990), rua, XML, gzip o zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, rapporto di errore (ruf, RFC 9991), servizio di reportistica, privacy

Cosa riceve

Se nel Suo record DMARC ha impostato un indirizzo rua (lezione 4.4), grandi destinatari come Google, Microsoft e Yahoo Le invieranno circa ogni giorno un rapporto aggregato. È un'e-mail con un allegato, di solito un file XML compresso con un nome come:

receiver.example!example.com!1793923200!1794009599.xml.gz

Questo significa: dal destinatario receiver.example, riguardo al Suo dominio example.com, per il periodo tra i due timestamp (secondi dal 1970; qui il 6 novembre 2026, l'intera giornata in UTC).

Un rapporto non contiene il contenuto della posta, non contiene oggetti e di solito non contiene indirizzi dei destinatari. Contiene, per ciascun server mittente, il numero di messaggi e l'esito di SPF, DKIM e DMARC. Per questo è un quadro affidabile di chi invia posta per conto del Suo dominio, comprese fonti che Lei stesso aveva dimenticato e truffatori.

La struttura di un rapporto

Un rapporto ha tre parti. Di seguito le sezioni principali del file di esempio di questa lezione (dmarc-rapport-1.xml).

1. Chi riporta, su quale periodo

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Quale policy ha trovato il destinatario presso di Lei

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Verifichi sempre questo punto: se qui non compare ciò che pensa di avere nel Suo DNS, significa che il destinatario ha letto un record diverso (o vecchio).

3. Per ciascuna fonte: un record

Ogni record riguarda un unico indirizzo IP mittente con una combinazione di esiti:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

La differenza più importante: auth_results rispetto a policy_evaluated

Qui sta il nucleo della lettura. Nell'esempio sopra, in auth_results compare due volte pass: DKIM è stato superato per mailer.example e SPF è stato superato per bounce.mailer.example. Eppure in policy_evaluated compare due volte fail. Non è una contraddizione: policy_evaluated conta solo un controllo superato che risulti allineato con header_from. Nessuno dei due domini appartiene a example.com, quindi DMARC fallisce.

Ecco come leggere ogni riga:

1. Guardi policy_evaluated. C'è un pass per dkim o spf? Allora DMARC è superato e questa fonte è a posto.
2. Tutto fallisce? Guardi in auth_results i domini. È un servizio Suo che però risulta superato per il proprio dominio? Allora deve attivare presso quel servizio il DKIM con il Suo dominio (lezione 4.3).
3. Fallisce anche in auth_results, oppure manca del tutto DKIM? Scopra a chi appartiene l'indirizzo IP (reverse DNS, lezione 5.1, o una ricerca whois). Se è uno dei Suoi sistemi: ripari. Se è sconosciuto e si tratta di numeri sospetti: probabilmente è una falsificazione.

Schemi ricorrenti

Faccia attenzione anche a IPv6: un server proprio che a volte invia tramite IPv6, mentre il Suo SPF indica solo l'indirizzo IPv4, produce un softfail su quelle righe. Con una firma DKIM, DMARC risulta comunque superato, ma è un segnale che il Suo SPF è incompleto.

Dal rapporto alla decisione

È pronto a inasprire la Sua policy (da none a quarantine, poi a reject) quando:

• ogni fonte che Le appartiene ha, in policy_evaluated, almeno un pass;
• questo accade già da qualche settimana, presso tutti i grandi destinatari;
• ciò che ancora fallisce è solo posta reindirizzata con una firma DKIM valida (che quindi risulta comunque superata) oppure chiaramente falsificazione.

Se una fonte propria importante fallisce, come nell'esempio il servizio di newsletter con 1250 messaggi, è ancora presto. Con p=reject il destinatario rifiuterebbe quelle 1250 newsletter.

Rendere leggibili i rapporti

Un rapporto in un editor di testo è gestibile. Venti al giorno no. Ci sono tre modi:

• Un servizio di reportistica (ce ne sono molti, anche con una variante gratuita). Imposta il loro indirizzo in rua e loro ne ricavano grafici ed elenchi. Attenzione: in questo modo dà a quel servizio visibilità su quali server inviano per Suo conto, e l'indirizzo di reportistica si trova sul loro dominio (vedi l'autorizzazione tramite _report._dmarc nella lezione 4.4). Scelga un servizio di cui si fida e che rispetti il GDPR.
• Uno strumento proprio: esistono programmi open source che prelevano i rapporti da una casella di posta e li presentano in una panoramica.
• Leggerli personalmente con un visualizzatore XML o un browser, per le occasioni sporadiche.

I rapporti di errore (ruf, RFC 9991) sono diversi: per ogni messaggio non riuscito, talvolta con parti del messaggio stesso incluse. Quasi nessun grande destinatario li invia, proprio per motivi di privacy. Non Le servono per introdurre correttamente DMARC.

Nella pratica: ecco come si presenta

Con WebOké può inserire l'indirizzo di reportistica nella guida DMARC in DirectAdmin o Mio WebOké (vedi lezione 4.4), e sceglie Lei stesso una casella di posta dove arrivano i rapporti; un indirizzo separato come dmarc@ con una cartella propria evita che la Sua posta normale venga sommersa. Per la lettura usa un servizio di reportistica o un programma a Sua scelta. Funziona allo stesso modo presso qualsiasi fornitore: il rapporto è in un formato standard.

Riepilogo

• Un rapporto aggregato è un file XML giornaliero (spesso compresso) per destinatario, con per ciascun IP mittente il numero di messaggi e gli esiti.
• auth_results fornisce l'esito grezzo di SPF e DKIM; policy_evaluated solo ciò che è stato superato con allineamento. Un pass in auth_results può corrispondere a un fail in DMARC.
• La posta reindirizzata si riconosce da DKIM pass con SPF fail; la falsificazione da tutto fail da un IP sconosciuto.
• Inasprisca la Sua policy solo quando tutte le Sue fonti proprie risultano superate da qualche settimana.
• I rapporti di errore (ruf) sono rari e non necessari.

Quiz

Esercizio

Esercizio Z4.5: Leggere un rapporto DMARC. Apra il file di esempio dmarc-rapport-1.xml (un rapporto aggregato su example.com, con dati fittizi). Risponda alle domande: quale policy ha trovato il destinatario, quanti messaggi compaiono in totale nel rapporto, quanti di questi hanno fallito DMARC, quale riga corrisponde al servizio di newsletter e cosa bisogna fare al riguardo, quale riga è posta reindirizzata, quale riga è probabilmente falsificazione, cosa deve cambiare nel record SPF secondo la riga 6, quale riga risulta superata solo grazie a DKIM presso un servizio con un proprio Return-Path, e il dominio può ora passare a p=quarantine? Il programma verifica le Sue risposte con una chiave fissa e spiega, per ogni domanda, quale riga del rapporto fornisce la risposta.

Per approfondire

I passaggi descritti in questi articoli valgono per i pannelli di WebOké; presso altri fornitori il funzionamento è simile.

• Che cos'è il DMARC? Spiegazione in parole semplici
• Guida DirectAdmin 5.9: DMARC impostare
• Corso gratuito DNS 4.5: DMARC: cosa devono fare i destinatari con le email false
• RFC 9990 (DMARC Aggregate Reporting), con il rapporto di esempio nell'allegato B; RFC 9991 (Failure Reporting)