Come leggere un report DMARC (Passo dopo passo per i mittenti B2B)

Un report aggregato DMARC è un riepilogo inviato dai provider di caselle di posta che mostra come le email che dichiarano di provenire dal tuo dominio si sono comportate rispetto ai controlli di autenticazione come SPF e DKIM.

Questi report sono essenziali per capire chi sta inviando email per tuo conto, il volume di email inviate e se tali email superano l'autenticazione. Sono la fonte primaria di verità per identificare mittenti legittimi, configurazioni errate e potenziali abusi.

Tuttavia, anche gli amministratori IT esperti spesso faticano a interpretare i report DMARC. I dati sono densi, altamente tecnici e difficili da tradurre in passaggi chiari e attuabili per migliorare la deliverability e la sicurezza delle email.

Per i team non tecnici, la sfida è ancora maggiore. I report sono consegnati in formato XML e forniscono poche indicazioni su cosa sia realmente importante o cosa risolvere per primo.

In questa guida, analizziamo i report aggregati DMARC in componenti pratici, spieghiamo su cosa concentrarsi e mostriamo come trasformare i dati in azioni significative per migliorare le performance delle email.

Tipi di report DMARC

Lo standard DMARC definisce due tipi di report. Tuttavia, solo uno di questi è costantemente disponibile e utile per la maggior parte dei team B2B responsabili della deliverability delle email.

Report aggregati DMARC (RUA)

I report aggregati DMARC (RUA) sono i report principali con cui lavorerai.

Vengono inviati quotidianamente dai mailbox providers e forniscono un riepilogo a livello di dominio di tutte le attività email osservate in un dato intervallo di tempo. Ogni report raggruppa i messaggi per fonte di invio e mostra i risultati di autenticazione per SPF, DKIM e DMARC.

I mailbox providers come Google e Microsoft forniscono costantemente report aggregati. Di conseguenza, costituiscono la base del monitoraggio DMARC e sono l'obiettivo principale di questa guida.

Report forensi DMARC (RUF)

I report forensi DMARC (RUF) sono progettati per fornire dettagli a livello di messaggio quando l'autenticazione fallisce.

In realtà, sono raramente disponibili. Molti mailbox providers non li inviano più o redigono pesantemente i dati a causa di vincoli di privacy. Il supporto varia ampiamente e la maggior parte dei domini B2B non riceve mai report forensi, anche quando richiesti.

Di conseguenza, la maggior parte dei team si affida quasi interamente ai report aggregati per il monitoraggio continuo e il processo decisionale.

Cosa contiene un DMARC Aggregate Report?

Un DMARC aggregate report è un riepilogo strutturato dell'attività email associata al tuo dominio in un periodo definito. Questi report hanno uno scopo intenzionalmente limitato. Non mostrano messaggi individuali, contenuti o destinatari. Si concentrano invece su segnali di autenticazione di alto livello che i provider di caselle di posta sono disposti a condividere su larga scala.

Dato che i report vengono consegnati come file XML, non sono pensati per una revisione manuale. La maggior parte dei team si affida a strumenti di parsing o piattaforme DMARC per rendere i dati leggibili. Questa limitazione è anche il motivo per cui i report aggregati sono preferiti dai provider di caselle di posta. Bilanciano visibilità e privacy e sono costantemente supportati dai principali provider.

A livello strutturale, ogni DMARC aggregate report contiene gli stessi componenti principali.

Organizzazione di reporting

Questo identifica il provider di caselle di posta che ha generato il report. Tra le organizzazioni di reporting comuni ci sono Google e Microsoft. Ogni provider invia il proprio report basato sul traffico che ha osservato per il tuo dominio.

Intervallo di date

Il report copre una finestra temporale specifica, di solito un periodo di 24 ore. Questo ti permette di monitorare il comportamento di autenticazione giorno per giorno e individuare i cambiamenti nel tempo, piuttosto che eventi isolati.

Sorgenti di invio

Le sorgenti di invio sono elencate a livello di indirizzo IP. Ogni sorgente rappresenta un server che ha inviato email usando il tuo dominio durante il periodo di reporting.

Volume dei messaggi per sorgente

Per ogni sorgente di invio, il report include il numero di messaggi osservati, fornendo visibilità sul volume di email inviate da ciascun IP per conto del tuo dominio durante l'intervallo di tempo specificato.

Risultati dell'autenticazione

Ogni sorgente di invio include i risultati dell'autenticazione basati su tre meccanismi.

o   I risultati SPF mostrano se il server di invio era autorizzato a inviare email per conto del dominio.

o   I risultati DKIM mostrano se i messaggi erano firmati crittograficamente e se il dominio di firma era allineato con il dominio From visibile.

o   La disposizione DMARC mostra come il provider di caselle di posta ha gestito i messaggi in base alla tua policy DMARC pubblicata.

Framework passo-passo per leggere un DMARC Report 

I DMARC aggregate report vengono consegnati come file XML. Anche se possono sembrare tecnici, non è necessario capire ogni tag per ricavarne informazioni significative.

Ecco un esempio semplificato di un DMARC aggregate report per example.com.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <date_range>
      <begin>1705968000</begin>
      <end>1706054399</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>example.com</domain>
    <p>none</p>
    <adkim>r</adkim>
    <aspf>r</aspf>
  </policy_published>

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>120</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
  </record>

  <record>
    <row>
      <source_ip>198.51.100.23</source_ip>
      <count>450</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>

  <record>
    <row>
      <source_ip>203.0.113.77</source_ip>
      <count>6</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

Non c'è bisogno di leggere riga per riga. Invece, applica sempre questa scansione in quattro passaggi.

Passaggio 1: Chi ha inviato l'email

Look for the <source_ip> field in each record.

In questo esempio, tre indirizzi IP hanno inviato email usando example.com. Ogni IP rappresenta un sistema di invio osservato dal provider di caselle di posta. A questo punto, il tuo unico compito è il riconoscimento. Chiediti se l'IP appartiene a una fonte conosciuta come Google Workspace, Microsoft 365, un tool di sales outreach o una piattaforma di marketing.

Passaggio 2: Volume delle email inviate

Next, look at the <count> value for each source.

Il volume ti aiuta a dare priorità all'attenzione. Le fonti ad alto volume contano più di quelle a basso volume. Un singolo IP sconosciuto che invia migliaia di email merita un'indagine immediata. Pochi messaggi potrebbero semplicemente indicare tentativi di spoofing in background.

Passaggio 3: L'autenticazione è andata a buon fine?

Quando analizzi un report aggregato DMARC, stai rispondendo a tre domande fondamentali per ogni fonte di invio. Ognuna di esse corrisponde direttamente a uno specifico tag XML nel report.

Now look at the authentication outcomes inside <policy_evaluated>.

Non stai ancora diagnosticando le cause principali. Stai semplicemente osservando i risultati:

• SPF è passato?

SPF results appear in the <policy_evaluated> block under the <spf> tag. If the report shows <spf>fail</spf>, SPF validation failed. The sending IP was not authorized by your domain’s SPF record at the time the message was evaluated.

If it shows <spf>pass</spf>, the sending server was authorized to send email on behalf of the domain.

• DKIM è passato?

DKIM results appear under the <dkim> tag in the same block. A value of <dkim>pass</dkim> means the message was correctly signed and the signature aligned with the visible From domain.

A value of <dkim>fail</dkim> means the message was not properly signed, the signature was invalid, or domain alignment failed.

• DMARC l'ha valutato come conforme?

DMARC’s final decision appears in the <disposition> tag. A value of <disposition>none</disposition> means no enforcement was applied, which is typical when a domain is in monitoring mode.

Valori come 'quarantine' o 'reject' indicano che il messaggio non ha superato la valutazione DMARC e che è stata applicata l'applicazione forzata secondo la policy pubblicata.

Questi tre tag rispondono al terzo passaggio del framework che hai visto prima. Una volta che sai chi ha inviato l'email e quanto ne ha inviato, SPF, DKIM e la disposizione ti dicono se quell'attività è stata autenticata e come i provider di caselle di posta l'hanno trattata.

Passaggio 4: Valuta se il pattern è previsto

Infine, combina identità, volume e risultati di autenticazione.

• Un IP conosciuto di Google Workspace che supera SPF e DKIM è previsto.
• Un tool conosciuto che fallisce SPF ma supera DKIM potrebbe essere normale.
• Un IP sconosciuto che fallisce entrambi i controlli, anche a basso volume, è inaspettato.

È qui che l'XML grezzo diventa un segnale utilizzabile.

Come interpretare i segnali di autenticazione?

Una volta che hai capito chi ha inviato l'email e il volume inviato, il passaggio successivo è interpretare i risultati dell'autenticazione. È qui che i report DMARC diventano utili per prendere decisioni.

I risultati dell'autenticazione aiutano i provider di caselle di posta a decidere se un'email è affidabile. Il tuo compito è capire cosa significano questi segnali e come leggerli.

Fonti di invio e trend di volume
Ogni riga in un report DMARC rappresenta un gruppo di messaggi da un IP specifico. I trend di volume sono importanti perché i provider di caselle di posta costruiscono la reputazione gradualmente. Picchi improvvisi spesso indicano configurazioni errate, nuovi tool o abusi.

Un volume basso ma ricorrente da IP sconosciuti di solito segnala tentativi di spoofing del dominio.

Risultati SPF
L'SPF verifica se un IP mittente è autorizzato a inviare email per conto del tuo dominio.

‍Gli errori SPF sono comuni e non sempre un problema. Spesso si verificano a causa di inoltri, record incompleti o strumenti che si basano invece sul DKIM.

Un errore SPF diventa un problema quando si ripete su larga scala o si combina con errori DKIM.

Risultati DKIM
Il DKIM verifica l'integrità del messaggio e l'allineamento del dominio. È il segnale di autenticazione più forte per la deliverability B2B perché sopravvive all'inoltro ed è molto affidabile per Google e Microsoft.
Per la maggior parte dei mittenti B2B, controlli DKIM coerenti e l'allineamento tra tutti gli strumenti sono non negoziabili.

Capire i risultati delle policy DMARC

Le policy DMARC definiscono come i provider di caselle di posta devono gestire le email che falliscono i controlli di autenticazione. Questi esiti appaiono nei report aggregati come la disposizione finale per ogni fonte di invio.

Queste policy gestiscono l'esposizione al rischio, non la collocazione nella posta in arrivo. Controllano cosa succede alle email non autenticate, non se le email autenticate finiscono nella posta in arrivo.

Le policy DMARC riducono l'esposizione allo spoofing e all'uso non autorizzato del tuo dominio. Non migliorano l'engagement, la reputazione del mittente o la collocazione nella posta in arrivo da sole.

L'autenticazione stabilisce la legittimità. La deliverability è determinata dalla reputazione e dal comportamento nel tempo.

Come riconoscere i mittenti affidabili dagli abusi

Una volta capiti i risultati dell'autenticazione, il passo successivo è decidere quali fonti di invio sono affidabili e quali invece richiedono attenzione.

Questa valutazione si basa raramente su un singolo segnale. Indirizzi IP sconosciuti o fallimenti isolati nell'autenticazione non indicano, da soli, un abuso. La fiducia si costruisce osservando schemi nel tempo, specialmente quando ci sono volume e ripetizione.

Come Classificare Ogni Fonte di Invio

Un buon modo per gestire i report DMARC è etichettare ogni riga in una di queste tre categorie.

Questa semplice classificazione mantiene efficiente la revisione DMARC e previene modifiche inutili che potrebbero interrompere il flusso legittimo delle email.

Modelli Comuni di Fallimento DMARC

I report aggregati DMARC tendono a mostrare le stesse combinazioni di risultati di autenticazione nel tempo. Queste combinazioni sono utili perché indicano cause probabili, non garantite.

I provider di posta elettronica valutano l'autenticazione in modo leggermente diverso, e i percorsi di invio possono variare in base a inoltro, gateway e tooling. I modelli seguenti dovrebbero essere letti come scorciatoie diagnostiche, non conclusioni assolute.

• SPF passa, DKIM fallisce
  Spesso DKIM mancante o non allineato.
  
  
• DKIM passa, SPF fallisce
  Comune con inoltro o infrastruttura condivisa. Di solito accettabile.
  
  
• SPF fallisce, DKIM fallisce
  Modello ad alto rischio. Indica spoofing o errata configurazione.
  
• 
  Un passaggio ma DMARC fallisce
  Problema di allineamento tra autenticazione e dominio From.

Risolvere ciò che mostrano i report DMARC

I report DMARC indicano problemi precisi nella configurazione delle email. Risolvi prima i problemi più grandi, poi affronta gli altri passo dopo passo.

• Autorizza gli strumenti email legittimi: Aggiungi ogni strumento che usi (Outlook, piattaforme di marketing) alla tua lista di mittenti approvati. Questo evita gli errori di "mittente non autorizzato".
• Attiva DKIM per tutte le email: DKIM aggiunge una firma digitale per dimostrare che le email provengono da te e non sono state modificate. Abilitalo ovunque tu invii.
• Semplifica i tuoi record SPF: Mantieni l'elenco dei mittenti approvati breve e aggiornato. Troppe voci confondono i sistemi email. Rimuovi gli strumenti vecchi o non utilizzati.
• Blocca le fonti email indesiderate: Blocca i mittenti sbagliati che si spacciano per la tua azienda. Concentrati sugli IP sconosciuti che inviano molti messaggi.
• Controlla i risultati dopo le modifiche: Monitora i report per 7-14 giorni. I problemi risolti mostrano una diminuzione dei volumi di errore e un aumento dei tassi di successo.

Inizia dai problemi più grandi

Come dare priorità ai problemi?

I report DMARC arrivano quotidianamente. Non tutti i problemi richiedono un'azione immediata. Osserva le tendenze su più giorni per distinguere i cambiamenti normali dai problemi ad alto impatto.

Dall'autenticazione al posizionamento nella casella di posta

DMARC prova la legittimità. Non guadagna fiducia.

I provider di caselle di posta alla fine premiano comportamenti come l'engagement positivo degli utenti, la coerenza e la reputazione nel tempo. È qui che molti team si bloccano. Risolvono l'autenticazione, vedono che tutto passa, eppure finiscono ancora nello spam.

È normale.

L'autenticazione rimuove gli ostacoli. La reputazione determina i risultati.

MailReach completa DMARC gestendo lo strato che DMARC non può influenzare. L'email warmup graduale genera segnali di engagement che insegnano a Google e Microsoft a fidarsi del tuo comportamento di invio. Il test antispam rileva i rischi di contenuto e formattazione prima che danneggino la reputazione. Il monitoraggio continuo assicura che i problemi tecnici non erodano silenziosamente la deliverability.

DMARC spiana la strada. MailReach crea la fiducia che fa leggere le email e ricevere risposte.

Inizia a costruire una reputazione di mittente di cui le caselle di posta si fidano. Usa MailReach per fare l'email warmup dei tuoi account, testare il posizionamento in inbox e proteggere la tua deliverability.