Come leggere un report aggregato DMARC: guida voce per voce

Il tuo record DMARC ha il tag rua= e ogni giorno i provider di caselle di posta ti inviano un file XML. Ecco cosa contiene realmente e come leggerlo senza mal di testa.

Tieni questa tabella a portata di mano. Tutto ciò che segue analizza perché ogni riga conta e come leggerla in un file reale.

I report aggregati DMARC sono l’unica parte del sistema DMARC pensata specificamente per essere letta dagli umani, eppure sono ancora scritti in XML. È questa la difficoltà. Red Sift OnDMARC trasforma tutto in dashboard così non tocchi mai l’XML grezzo, ma capire cosa riassumono quelle dashboard rende ogni decisione sulla policy DMARC più rapida e difendibile. Questa guida affronta un vero report, voce per voce, e ti mostra come distinguere una rotazione di provider email da un vero tentativo di spoofing.

Questa non è una ripetizione di cosa sia un report aggregato né di perché la casella rua= potrebbe essere vuota. Se ti serve quella base, la nostra guida ai fondamenti del reporting aggregato DMARC la copre. Qui partiamo da quando il file arriva nella tua casella e ti mostriamo cosa farne.

Alla fine saprai:

• Aprire un report e identificare ogni sezione senza bisogno di legenda
• Distinguere tra il risultato passa/fail di DMARC e il risultato grezzo SPF/DKIM sottostante
• Leggere la colonna disposition e capire esattamente cosa è successo a quella mail
• Riconoscere i quattro pattern più comuni nei report reali, inclusi inoltro, rotazione ESP e spoofing reale
• Comprendere cosa è cambiato nel formato del report con l’aggiornamento DMARC 2026

Ogni report aggregato DMARC è un singolo documento XML con un elemento radice chiamato feedback. Al suo interno, tre blocchi contengono tutte le informazioni che ti servono [1].

• report_meta identifica chi ti ha inviato il report e quando. Include il nome dell’organizzazione, una mail di contatto, un ID report univoco e un date_range che indica la finestra di riferimento in secondi dall’epoch Unix. La maggior parte dei riceventi riporta su finestre scorrevoli di 24 ore.
• policy_published è la lettura del tuo record DMARC fatta dal ricevente al momento della valutazione della mail. Conta più di quanto sembri. Se cambi la policy da p=none a p=quarantine durante una giornata, diversi report di quella giornata potrebbero mostrare valori differenti qui, perché propagazione DNS e caching fanno sì che non tutti i riceventi vedano la modifica nello stesso momento [1].
• record è dove stanno i dati veri. C’è un blocco record per ogni combinazione di IP mittente, risultato e identificatori di autenticazione, quindi lo stesso IP può comparire in più record anche se la disposition è identica. Un report può contenerne da uno a migliaia a seconda del volume di posta. Ogni record si divide in tre parti: row (IP, numero e verdetto), identifiers (i domini effettivamente verificati da DMARC) e auth_results (i risultati SPF e DKIM grezzi prima dell’allineamento DMARC).

Quando sai riconoscere questi tre blocchi a colpo d’occhio, leggere qualsiasi report è solo una questione di trovare quello giusto, non decifrare da zero l’intero file.

Ecco come appare un record singolo una volta decompresso, in base alla struttura definita dalla RFC 9990 [1]. La maggior parte dei riceventi comprime il file (Gmail invia .zip, altri inviano .xml.gz), quindi il primo passo è sempre la decompressione.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>16215678901234567890</report_id>
    <date_range>
      <begin>1754784000</begin>
      <end>1754870399</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>redsift.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
  </policy_published>

  <record>
    <row>
      <source_ip>203.0.113.42</source_ip>
      <count>842</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>redsift.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>redsift.com</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>redsift.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Cosa ti dice ogni riga:

• org_name e date_range: Google ha generato questo report, riferito a una finestra di 24 ore. Tutto ciò che segue riguarda la posta inviata in quel periodo, non oggi.
• policy_published: Google ha interpretato il record DMARC di redsift.com come allineamento rilassato (r) su DKIM e SPF, con policy di quarantena. È la policy effettivamente applicata, non per forza quella attualmente attiva nel DNS se è cambiata.
• source_ip: 842 messaggi arrivano da questo IP durante la finestra. È un conteggio aggregato, non 842 righe di log.
• disposition: pass indica che il messaggio ha superato la valutazione DMARC secondo la policy. Disposition riflette il risultato DMARC segnalato qui, non garantisce come il provider ha realmente gestito la posta.
• dkim e spf dentro policy_evaluated: Entrambi mostrano pass, perché il messaggio era allineato secondo DMARC, non solo per il controllo grezzo.
• auth_results: Questo è il verdetto pre-DMARC. DKIM è passato usando il selettore google, anche SPF è passato. Qui i risultati grezzi e quelli DMARC coincidono. Non capita sempre.

Questo ultimo aspetto è spesso il più trascurato alla prima lettura, ma merita una sezione a sé. Ma prima, una parola sul blocco identifiers, che decide a quale dominio attribuire il risultato dell’intero record.

L’elemento identifiers porta solo fino a tre campi ed è facile saltarlo perché non mostra successo o fail. Proprio per questo è importante. Indica quali domini DMARC ha controllato e tutti gli altri verdetti del record si confrontano su questi valori.

• header_form è il dominio nell’indirizzo From visibile, quello che il destinatario vede nella propria casella. È richiesto in ogni record e rappresenta l’ancora logica di tutto l’allineamento DMARC. Ogni controllo di policy_evaluated in pratica chiede: il dominio che ha passato SPF o DKIM corrisponde a questo?
• envelope_form è il dominio dal comando SMTP MAIL FROM, chiamato anche bounce o return-path. I destinatari non lo vedono, ma è contro cui SPF effettua davvero il match. Quando una piattaforma marketing invia per conto tuo, spesso mostra il suo dominio di infrastruttura, quindi l’allineamento SPF fallisce a meno che non configuri un return-path personalizzato.
• envelope_to è opzionale e indica il dominio destinatario: utile se vuoi capire se il traffico in fail va su un provider specifico o su molti.

Da ricordare: se header_from mostra redsift.com ma envelope_from mostra bounce.some-esp.com, SPF viene controllato sul dominio ESP, non tuo. Il controllo SPF può passare perfettamente su quel dominio ESP e comunque fallire l’allineamento DMARC, perché l’allineamento confronta envelope_from con header_from e i due non coincidono a meno che l’ESP invii da un sottodominio che gli hai delegato. Questa relazione spiega più ticket di “perché è fallito?” di qualsiasi altra riga nel report.

Ogni record contiene verdetti distinti DKIM e SPF e rispondono a domande diverse.

• auth_results risponde: “Il controllo SPF o DKIM grezzo è passato?” È il risultato a livello di protocollo, rispetto al dominio specificato dalla firma o dal record SPF.
• policy_evaluated risponde: “Quel risultato ha contato per DMARC?” È il risultato con il controllo di allineamento, quello che decide la tua disposition.

La differenza è l’allineamento. DMARC non chiede solo se SPF o DKIM sono passati: chiede se il dominio passato coincide (in modo esatto o rilassato) con il From visibile (allineamento rigido adkim=s o aspf=s o rilassato, default per la maggior parte) [2]. Un messaggio può passare SPF su bounce.thirdpartyesp.com e comunque fallire DMARC, perché bounce.thirdpartyesp.com non è allineato con redsift.com nell’header From.

Per questo a volte vedrai auth_results mostrare pass mentre policy_evaluated mostra fail per lo stesso record. Questa incoerenza è quasi sempre la risposta quando la posta legittima di un sender finisce in quarantena anche se “tutto passa” sulla dashboard del provider. Il provider ti mostra solo il check SPF o DKIM grezzo: DMARC richiede anche allineamento.

Il campo disposition ti dice effettivamente cosa è successo alla mail e può assumere quattro valori [1]:

Un dettaglio che mette in difficoltà quasi tutti: se la tua policy è p=none, la maggior parte dei record mostrerà disposition: none anche quando SPF e DKIM falliscono entrambi. È normale, anche se il ricevente può comunque applicare policy locali o altre eccezioni: è proprio quello che il campo reason (sotto) indica. A p=none chiedi solo ai riceventi di segnalare cosa succederebbe, non di applicare nulla. Il report fa esattamente il suo lavoro. Nulla viene bloccato perché non hai ancora chiesto di bloccare nulla.

Se vedi una disposition diversa da quanto ti aspetti dalla policy pubblicata, cerca un elemento reason all’interno di policy_evaluated. La RFC 9990 prevede cinque tipi di override: local_policy, mailing_list, trusted_forwarder, policy_test_mode e other [1]. Un reason mailing_list su un record fallito indica che l’override è stato attribuito a una gestione da mailing list. Un caso comune è un server lista che inoltra la mail in modo che l’allineamento SPF fallisca e la firma DKIM venga modificata o rimossa; ma il valore reason non garantisce che sia esattamente questa la causa. Resta comunque un comportamento normale per inoltri e mailing list e non è qualcosa da gestire come minaccia.

Analizzare un singolo record serve a poco. Il valore dei report aggregati sta nel leggere insieme molti record dello stesso mittente su più giorni. Quattro pattern si ripetono spesso e distinguerli evita sia di ignorare un problema vero sia di rincorrerne uno finto.

1. Mittente legittimo non ancora autorizzato. Un nuovo source_ip appare, auth_results mostra fail sia SPF che DKIM, e il conteggio è costante di giorno in giorno. Di solito è una piattaforma marketing, CRM o helpdesk che qualcuno ha attivato senza avvisare l’IT. La soluzione è aggiungere SPF e configurare la firma DKIM, non bloccarli.

2. Rotazione IP di ESP o provider cloud. Un mittente è autorizzato da mesi e improvvisamente compaiono nuovi IP che falliscono SPF mentre DKIM continua a passare. I grandi mittenti ruotano spesso infrastruttura. La firma DKIM viaggia con il messaggio a prescindere dall’IP: DKIM resta allineato mentre SPF salta. Contatta il tuo ESP per verificare eventuali cambiamenti.

3. Mailing list e forwarder. SPF e DKIM entrambi falliscono, l’elemento reason mostra mailing_list o il conteggio è basso e sparso su molti IP anziché concentrato. L’header_from resta il tuo dominio. Di solito è un collega che inoltra la mail o una mailing list che la ridistribuisce. È il normale compromesso dell’inoltro DMARC, e la RFC 9989 lo prevede con la gestione dei flussi indiretti [2].

4. Spoofing reale. SPF e DKIM entrambi falliscono, l'IP non è legato a nessun fornitore o infrastruttura nota, non c’è override reason e il volume è una singola ondata o un lento ma costante trickle non attribuibile a processi interni. Qui vale la pena agire: verifica che la policy sia abbastanza restrittiva da bloccare o mettere in quarantena, e se il traffico è alto trattalo come un attacco di phishing contro il tuo dominio.

Fare tutte queste verifiche a mano su migliaia di record al giorno non scala oltre pochi mittenti, ed è proprio per questo che piattaforme come Red Sift OnDMARC esistono: per evidenziare automaticamente questi quattro pattern invece che dover esaminare a occhio l’XML ogni mattina.

Nel maggio 2026 l’IETF ha sostituito la specifica DMARC originale, RFC 7489, con tre documenti separati: la RFC 9989 copre il protocollo principale, la RFC 9990 il reporting aggregato nello specifico e la RFC 9991 il reporting di errore [1, 2]. Chi analizza report aggregati da tempo userà lo stesso formato di sempre. Le piattaforme scritte per la vecchia schema continueranno a funzionare, dato che RFC 9990 impone la tolleranza agli extension data non supportati [1], ma non è garantito: il namespace e lo schema RFC 9990 differiscono dalla 7489 e cambi semantici come la disposition pass possono far fallire i parser troppo rigidi.

Alcuni aggiunte sono utili quando apri un report:

• discover_method può ora apparire in policy_published: indica psl (il metodo Public Suffix List storico) o treewalk (nuovo metodo DNS per identificare il tuo Organizational Domain) [1].
• Ora i selettori sono obbligatori, non più opzionali, ogni volta che una firma DKIM compare in auth_results. Prima alcuni riceventi omettevano il campo selector.
• Un campo generator può apparire in report_metadata, così puoi vedere quale software ha prodotto il report: utile per debugging su file malformati da un ricevente.

Nessuno di questi cambi influisce sulla lettura quotidiana: i parser e le dashboard esistenti continueranno a funzionare visto che le regole di estensibilità RFC 9990 richiedono la tolleranza ai campi non supportati [1]. Non è una garanzia del parsing XML, ma una regola precisa della RFC stessa. Un’informazione da tenere a mente se gestisci tuoi parser o stai valutando fornitori. E un promemoria che DMARC è ancora uno standard vivo, non fermo al 2015. Il cambiamento strutturale più importante è che il reporting aggregato ora ha una sua specifica separata: può evolversi autonomamente senza aspettare una revisione completa DMARC ogni volta. Abbiamo riassunto tutte le novità, anche a livello di record DNS, nella nostra analisi dell’aggiornamento RFC 9989.

Un dominio medio può produrre report ogni giorno da 15-30 provider diversi, ognuno col suo file, formato di compressione e sfumature nel riempire i campi opzionali. Niente di questo è pensato per essere gestito a occhio, ma per essere letto dalle macchine e poi riassunto in modo agibile.

Le regole per i bulk sender di Google, in vigore da febbraio 2024, impongono che ogni dominio che invii 5.000+ messaggi al giorno a indirizzi Gmail autentichi via SPF e DKIM e pubblichi almeno una policy DMARC p=none [3]. Questo unico requisito ha portato moltissimi domini su DMARC per la prima volta e quasi tutti si sono scontrati con la stessa realtà: i report sono corretti ma illeggibili su larga scala senza strumenti.

Questo è l’anello che Red Sift OnDMARC colma: riceve tutti i report automaticamente, raggruppa i record per sorgente invece che per file, segnala nuovi mittenti il giorno stesso e offre una vista chiara sui pass rate così puoi decidere se e quando passare da p=none a p=quarantine a p=reject. Se stai iniziando ora, la nostra guida all’implementazione DMARC spiega il percorso completo fino all’enforcement totale.

Leggere un singolo report invece della tendenza. Il report di una sola giornata mostra cosa è successo in 24 ore. Cambiano infrastrutture, volumi e possono avvenire errori isolati. Guarda lo stesso mittente su almeno una settimana prima di trarre conclusioni.

Confondere auth_results con il verdetto DMARC. Come sopra, possono essere discordanti. Se “tutto passa dalla nostra parte” ma DMARC fallisce, quasi sempre è una questione di allineamento.

Assumere che disposition:none significhi nessun fallimento. Con p=none, vuol solo dire che nulla è stato bloccato, non che tutto sia passato. Verifica dkim e spf dentro policy_evaluated a mano.

Ignorare il campo count. Un solo messaggio fallito da un IP sconosciuto è rumore. Un pattern di decine o centinaia di messaggi simili per due settimane indica un mittente da autorizzare o bloccare.

Trattare ogni errore come un attacco. La maggior parte dei fail in una inbox sono inoltri, mailing list o fornitori da aggiornare in SPF, non spoofing. Riserva urgenza ai pattern senza spiegazione interna e senza override reason.

Saltare il blocco identifiers. Non porta un valore di pass/fail quindi è facile concentrarsi solo su policy_evaluated. Ma senza controllare header_from rispetto a envelope_from, resti nel campo delle ipotesi sul motivo del fallimento di allineamento.

Un report aggregato DMARC è costituito da tre blocchi XML e pochi campi ripetuti per ogni sorgente mittente. Se sai individuare a colpo d’occhio report_metadata, policy_published e record, e controllare policy_evaluated invece che auth_results per il risultato DMARC reale, il file non spaventa più. Il difficile è ripetere questa analisi su decine di report da decine di provider e migliaia di record, ogni giorno, senza perdere il filo.

Qui vale la pena automatizzare. Red Sift OnDMARC analizza ogni report all’arrivo, evidenzia automaticamente i mittenti nuovi o non autorizzati e mostra il pass rate per sorgente così la scelta di indurire la policy diventa una verifica da un click anziché un file Excel.

[1] RFC 9990 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting

[2] RFC 9989 - Domain-Based Message Authentication, Reporting, and Conformance (DMARC)

[3] Email sender guidelines FAQ - Gmail Help