Che cos’è l’ARF? Formato di segnalazione degli abusi e rapporti di errore DMARC (RFC 5965)

Che cos’è l’ARF (Abuse Reporting Format)?

ARF è l’acronimo di Abuse Reporting Format. Si tratta di un formato standardizzato e leggibile da macchina utilizzato per notificare ai mittenti che un’e-mail ha causato un problema. È stato definito nella RFC 5965 nel 2010, in un’epoca in cui le segnalazioni di abuso erano per lo più e-mail in testo semplice e incoerenti che gli amministratori di posta dovevano leggere manualmente. Questo sistema funzionava bene quando i volumi erano bassi, ma è fallito nel momento in cui i provider hanno voluto automatizzare il processo. L’ARF ha fornito ai destinatari, agli ISP e ai provider di caselle di posta una struttura condivisa, in modo che gli eventi di abuso potessero essere segnalati ai proprietari dei domini e ai mittenti in un formato facilmente gestibile da script e parser.

Oggi l'ARF è presente in quattro luoghi principali:

• Segnalazioni di errore DMARC – quando un messaggio non supera l'autenticazione DMARC, il destinatario può inviare un rapporto ARF che descrive esattamente quale sia stato il problema.
• Circuiti di feedback degli ISP: quando un destinatario clicca su “Questo è spam”, alcuni provider inoltrano tale segnalazione al mittente in formato ARF.
• Segnalazioni all’Abuse-desk – segnalazioni manuali di abusi inoltrate tramite sistemi automatizzati di gestione degli abusi.
• Segnalazioni di phishing e frodi – segnalazioni che indicano un messaggio come fraudolento e non semplicemente indesiderato.

È bene chiarirlo subito: questo ARF non ha nulla a che vedere con qualsiasi altro acronimo a cui potreste pensare. Nel mondo della posta elettronica, ARF sta sempre per “Abuse Reporting Format” (formato di segnalazione degli abusi).

Come è strutturato un rapporto ARF (le tre parti)

La RFC 5965 definisce l'ARF come un messaggio MIME di tipo "multipart/report", il che significa semplicemente che si tratta di un'e-mail composta da tre parti distinte raggruppate insieme. Ciascuna parte è destinata a un destinatario diverso: una è per un utente umano, una è per una macchina e una costituisce la prova.

Parte 1: Riepilogo leggibile dall'utente (text/plain)

La prima parte è un blocco di testo in chiaro pensato per chi dà una rapida occhiata alla propria casella di posta. Di solito contiene un riassunto di una o due righe di ciò che è accaduto, in modo che chi dà un’occhiata al rapporto non debba analizzare i campi leggibili dal computer solo per coglierne il senso generale.

Parte 2: Rapporto leggibile da macchina (message/feedback-report)

Questa è la parte centrale del report e quella che i sistemi automatizzati analizzano effettivamente. Si tratta di un blocco di campi chiave-valore quali Feedback-Type, Version, User-Agent, Source-IP e Arrival-Date, insieme a campi specifici relativi all’autenticazione come Auth-Failure. È proprio qui che risiede il valore diagnostico del report.

Parte 3: Il messaggio originale (message/rfc822 o text/rfc822-headers)

La parte finale riporta il messaggio originale completo oppure solo le intestazioni, a seconda di come il mittente ha configurato il sistema e di quanti dettagli il destinatario è disposto a condividere. Poiché il contenuto del messaggio può contenere informazioni personali, molti destinatari lo riducono alle sole intestazioni oppure ne oscurano alcune parti prima di inoltrare il rapporto.

Tipi di feedback ARF

Il campo "Tipo di feedback" indica il tipo di rapporto che stai visualizzando:

Ai fini del DMARC, qui vedrai sempre e solo un valore: auth-failure. È possibile registrare ulteriori tipi di feedback presso l'IANA qualora dovesse presentarsi un nuovo caso d'uso, ma il caso d'uso del DMARC è rimasto invariato con auth-failure sin dall'inizio.

ARF, AFRF, RUF, relazioni forensi: fare chiarezza sulla terminologia

Se avete letto qualcosa sui report DMARC e avete iniziato a notare che i termini ARF, AFRF, RUF e “report forense” vengono utilizzati quasi in modo intercambiabile, non state immaginando cose. Questi termini si sovrappongono effettivamente, ed ecco come sono realmente correlati:

• L'ARF è il formato di base definito nella RFC 5965. Si tratta di un formato generico che non è mai stato specifico per DMARC.
• L'AFRF (Authentication Failure Reporting Format) è l'estensione definita nella RFC 6591 che ha adattato l'ARF specificamente per la segnalazione degli errori di autenticazione SPF, DKIM e DMARC.
• RUF è il tag DMARC (ruf=) che si inserisce nel proprio record DNS per richiedere che i rapporti di errore relativi ai singoli messaggi vengano inviati a una determinata destinazione.
• Il termine “rapporto forense ” è la denominazione precedente di questo stesso artefatto, ereditata dalla specifica DMARC originale, RFC 7489. L’attuale serie di RFC lo definisce invece “rapporto di errore”.

Quindi, quando qualcuno chiede un “esempio di rapporto forense” e qualcun altro lo chiama “rapporto di errore DMARC”, si riferiscono alla stessa cosa. È cambiata la denominazione con l’introduzione dello standard, non il meccanismo di base.

ARF e DMARC: spiegazione dei rapporti di errore

Quando si aggiunge un tag ruf= al proprio record DNS DMARC, si richiede ai server di posta in ricezione di inviare un rapporto ogni volta che un messaggio che dichiara di provenire dal proprio dominio non supera il controllo DMARC. A differenza dei rapporti aggregati, che raggruppano il traffico di un’intera giornata in un unico riepilogo XML, i rapporti di errore sono pensati per essere generati in prossimità del momento in cui si verifica l’errore e riguardano un singolo messaggio.

Un rapporto di errore DMARC fornisce informazioni che un rapporto aggregato non è in grado di fornire: i risultati dell’autenticazione relativi a quel messaggio specifico, i dettagli su quale meccanismo abbia effettivamente fallito, le informazioni sulla fonte di invio e il messaggio completo o le sue intestazioni, in modo da poter risalire alla sua provenienza effettiva. È proprio questo livello di dettaglio a rendere i rapporti di errore utili per individuare un tentativo di spoofing quasi in tempo reale, ammesso che se ne riceva effettivamente uno, il che ci porta alla sezione successiva.

Cosa è cambiato con la RFC 9991 (aggiornamento del 2026)

Nel maggio 2026, l’IETF ha pubblicato una nuova serie di documenti DMARC che sostituiscono l’originale RFC 7489: RFC 9989 (DMARC di base), RFC 9990 (reportistica aggregata/RUA) e RFC 9991 (reportistica degli errori/RUF). Insieme, rendono obsoleta la RFC 7489. Ecco cosa è effettivamente cambiato per quanto riguarda i rapporti di errore:

• La linea di sviluppo delle RFC ha subito una modifica: la RFC 9991 ora tratta la segnalazione degli errori e rende obsolete le sezioni relative alla segnalazione degli errori contenute nella RFC 7489. Inoltre, aggiorna la RFC 6591 (AFRF) con una serie più precisa di campi obbligatori.
• Il formato ARF in sé non è cambiato: l'RFC 5965 rimane il formato di base sottostante.
• Un nuovo campo obbligatorio: Identity-Alignment: un elenco separato da virgole che indica quale meccanismo, DKIM o SPF, non è riuscito a generare un identificatore allineato, oppure “none” se l’identificatore allineato ha effettivamente effettuato l’autenticazione. Questo è il campo più utile per chiunque legga un rapporto, poiché indica direttamente se si tratta di una configurazione errata o di un vero e proprio spoofing,
• Un nuovo tipo di errore di autenticazione: dmarc: viene utilizzato specificatamente quando nessun identificatore allineato ha autenticato il messaggio, a differenza di un errore generico SPF o DKIM.
• Nuovi campi obbligatori per la diagnosi degli errori di allineamento: DKIM-Domain, DKIM-Identity e DKIM-Selector sono obbligatori quando una firma DKIM allineata non supera il controllo. SPF-DNS è obbligatorio quando un controllo SPF allineato non supera il controllo.
• Nuovi campi opzionali per ulteriori dettagli: "Delivery-Result" e la coppia "DKIM-Canonicalized-Header/Body", disponibili quando un destinatario desidera includere ulteriori informazioni diagnostiche.

Perché l’allineamento identitario è così importante

DMARC non ha mai verificato realmente se SPF o DKIM fossero validi singolarmente, ma controlla se un identificatore autenticato corrisponda al dominio presente nell'indirizzo "Da:" visibile. Un messaggio può superare tecnicamente sia il controllo SPF che quello DKIM e tuttavia non superare il controllo DMARC se nessuno dei due è allineato con il dominio "Da:". Questo campo lo specifica chiaramente.

RUA vs RUF: Rapporti aggregati vs Rapporti di errore

Raccomandazione (come in precedenza)

Configurare sempre il parametro `rua=` nel proprio record DMARC. I principali provider di posta elettronica supportano ampiamente i report DMARC Aggregate e offrono la visibilità quotidiana necessaria per monitorare l’autenticazione. La configurazione del parametro `ruf=` è facoltativa e può fornire ulteriori informazioni diagnostiche, ma molti destinatari non inviano report forensi; pertanto, è opportuno considerarli come una fonte di dati supplementare.

Come leggere un rapporto ARF (esempio campo per campo)

Di seguito è riportato un esempio di come potrebbe presentarsi un rapporto di errore DMARC in caso di spoofing diretto del dominio, in cui un malintenzionato invia un’e-mail fingendo che provenga dal proprio dominio senza che vi siano record SPF o DKIM validi a sostegno:

Feedback-Type: auth-failure
Version: 1
User-Agent: MailReceiver/2.1
Auth-Failure: dmarc
Identity-Alignment: dkim, spf
Original-Mail-From: <[email protected]>
Reported-Domain: yourdomain.com
Source-IP: 198.51.100.44
SPF-DNS: v=spf1 include:_spf.yourdomain.com ~all
Authentication-Results: mx.receiver.example;
    dmarc=fail (p=reject) header.from=yourdomain.com;
    spf=fail smtp.mailfrom=spoofed-source.net;
    dkim=none
Arrival-Date: Wed, 22 Jul 2026 09:14:02 +0000

Passeggiando tra i campi che contano di più:

• Il tipo di segnalazione "auth-failure" conferma che si tratta di un problema di autenticazione, non di una segnalazione di spam o abuso.
• Errore di autenticazione: dmarc indica che l'errore è specificatamente un errore di allineamento DMARC, ovvero il tipo introdotto dalla RFC 9991.
• Allineamento dell'identità: dkim, spf è la riga diagnostica chiave. Entrambi i meccanismi non sono riusciti a generare un identificatore allineato, il che, unito all'assenza di una firma DKIM valida e al fallimento del controllo SPF, indica chiaramente un caso di spoofing vero e proprio piuttosto che un errore di configurazione da parte vostra.
• I campi "Source-IP" e "Original-Mail-From" indicano la provenienza effettiva del messaggio, informazione utile per l'inserimento in liste di blocco o per ulteriori indagini.
• "Reported-Domain" conferma quale dei tuoi domini è stato preso di mira, funzione utile se ne gestisci diversi.
• SPF-DNS mostra il record SPF utilizzato dal destinatario per la verifica, il che ti aiuta a verificare se il tuo record è stato letto correttamente.

Se invece si fosse trattato di un mittente di terze parti legittimo che avevi dimenticato di autorizzare, in genere vedresti che “Identity-Alignment” indica un solo meccanismo, mentre l’altro risulta “pass”, il che ti indirizza verso una correzione della configurazione piuttosto che verso un attacco.

Perché potresti non ricevere i rapporti sugli errori

Se hai configurato ruf= e i rapporti non vengono mai visualizzati, oppure arrivano solo sporadicamente, ci sono diverse ragioni plausibili:

1. I principali fornitori, nella maggior parte dei casi, non li inviano

Gmail e Yahoo, che figurano tra le principali fonti di posta in arrivo per la maggior parte dei domini, in genere non generano segnalazioni di errore...

2. Privacy e oscuramento

I rapporti sugli errori possono rivelare informazioni personali contenute nelle intestazioni o nel corpo dei messaggi, esponendo il mittente a rischi legati al GDPR e al CCPA. La RFC 6590 tratta della cancellazione dei dati sensibili dai rapporti sugli abusi, ma l'applicazione di tale procedura può privare il rapporto di gran parte delle informazioni che lo rendevano utile in primo luogo.

3. Le destinazioni esterne devono essere verificate

Se il tuo indirizzo ruf= punta a una destinazione al di fuori del dominio della tua organizzazione, la RFC 9991 richiede che il destinatario esegua una verifica della destinazione esterna (lo stesso meccanismo definito dalla RFC 9990 per i rapporti aggregati) prima di inviare qualsiasi cosa a tale indirizzo. In assenza di tale record di autorizzazione, i rapporti non verranno recapitati.

4. È previsto un limite di velocità

La RFC 9991 invita i segnalatori a limitare il numero di segnalazioni di errore inviate a un singolo destinatario, in parte per evitare di intasare la casella di posta e in parte per prevenire i cicli di segnalazione.

5. Nessun guasto, nessuna segnalazione

Se la tua posta legittima viene autenticata correttamente, non c'è nulla che possa far scattare una segnalazione di errore.

6. Le impostazioni del tag "fo"

Il tag `fo=` controlla esattamente quando viene generato un report: `fo=0` (impostazione predefinita) genera un report solo quando sia SPF che DKIM falliscono o presentano incongruenze; `fo=1` genera un report se uno dei due fallisce; `fo=d` genera un report specificamente in caso di fallimento di DKIM; e `fo=s` genera un report specificamente in caso di fallimento di SPF. La maggior parte dei domini che desiderano effettivamente ottenere una diagnostica utile imposta `fo=1`.

Circuiti di retroazione via e-mail e ARF

I rapporti sugli errori non sono l'unico contesto in cui compare l'ARF. Anche i circuiti di feedback degli ISP (tra cuiil Complaint Feedback Loop di Yahoo e i programmi JMRP/SNDS di Microsoft ) utilizzano esattamente lo stesso formato ARF, con l'unica differenza che il campo "Feedback-Type" è impostato su "abuse" anziché su "auth-failure".

Questi report vengono generati quando un destinatario contrassegna un messaggio come spam e costituiscono un utile segnale precoce di eventuali problemi di consegna, anche se non sono affatto collegati al DMARC.

Come configurare l'ARF (Failure Reporting) per il proprio dominio

Se desideri iniziare a raccogliere segnalazioni di errori relative al tuo dominio:

1. Aggiungi un tag ruf= al tuo record DNS DMARC, indicando una casella di posta dedicata o un indirizzo di segnalazione.

2. Impostare fo=1 se si desidera ricevere segnalazioni in caso di errore SPF o DKIM, anziché solo quando entrambi falliscono.

3. Se l'indirizzo ruf= si trova al di fuori del dominio della propria organizzazione, assicurarsi che sia presente il record di autorizzazione per la destinazione esterna, altrimenti i destinatari non invieranno nulla a quell'indirizzo.

4. Registrarsi separatamente ai programmi di feedback loop dei principali ISP, poiché questi funzionano in modo del tutto indipendente dal DMARC.

5. Non pensate di poterli leggere manualmente in quantità significative. Anche una piccola quantità di posta può generare un numero di report ARF grezzi superiore a quello che è pratico analizzare manualmente. È qui che uno strumento automatizzato di analisi dei report DMARC semplifica le cose.

Riassunto

I rapporti di errore rappresentano un’applicazione specifica dell’ARF all’interno del DMARC. Il RUF fornisce dettagli approfonditi per ogni singolo messaggio al momento della ricezione, ma una quota significativa dei destinatari non lo invia; ciò rende i rapporti aggregati (RUA) la vostra fonte affidabile e quotidiana di visibilità. Ora che lo standard DMARC è stato formalizzato nelle RFC 9989, RFC 9990 e RFC 9991, è più importante che mai utilizzare correttamente la terminologia e i dettagli, specialmente se si sta risolvendo un vero e proprio incidente di spoofing piuttosto che una semplice configurazione errata.

Se stai configurando i report per la prima volta o desideri visualizzare questi dati senza dover analizzare tu stesso i messaggi ARF grezzi, il nostro DMARC Report Analyzer è stato progettato proprio per questo. Registrati oggi stesso per una prova gratuita e consulta i tuoi report senza complicazioni!

Domande frequenti

Che cos’è un rapporto (forense) sugli errori DMARC?

Si tratta di un report ARF generato per ogni singolo messaggio quando un’e-mail non supera l’autenticazione DMARC. Contiene dettagli sul messaggio specifico, tra cui quali meccanismi di autenticazione hanno dato esito negativo e se hanno prodotto un identificatore allineato con il dominio del campo “Da:”. “Report forense” è la denominazione precedente per lo stesso concetto, ereditata dalla RFC 7489.

Qual è la differenza tra RUA e RUF in DMARC?

I report RUA (aggregati) sono riepiloghi giornalieri in formato XML che coprono tutta la posta proveniente da un dominio, ora definiti nella RFC 9990. I report RUF (di errore) sono report ARF quasi in tempo reale relativi a singoli messaggi non recapitati, definiti nella RFC 9991. Il protocollo RUA è ampiamente supportato; il protocollo RUF è facoltativo e la sua invio non è sistematico.

Chi invia i rapporti di errore DMARC?

Solo alcuni client di posta elettronica li generano, mentre i principali provider di posta elettronica come Gmail e Yahoo generalmente non lo fanno. Il supporto varia a seconda del client, e le preoccupazioni relative alla privacy, i requisiti di limitazione della frequenza e le regole di verifica della destinazione previste dalla RFC 9991 riducono tutti la frequenza con cui questi messaggi arrivano effettivamente a destinazione.

Qual è la differenza tra ARF e XARF?

L'ARF (RFC 5965) è il formato standardizzato dall'IETF utilizzato nei rapporti di errore DMARC e nei feedback loop degli ISP. L'XARF è un'estensione proprietaria, sviluppata da un fornitore, che aggiunge un payload JSON per facilitare l'analisi. Non è uno standard IETF e non viene utilizzato dai principali provider per la segnalazione DMARC.

Perché non ricevo alcuna segnalazione di errore DMARC?

Tra le possibili cause figurano l'invio a provider principali che non generano tali segnalazioni, la riduzione del contenuto del rapporto a seguito di operazioni di oscuramento per motivi di privacy, la mancanza di un record di verifica della destinazione esterna se l'indirizzo ruf= è al di fuori del dominio, la limitazione obbligatoria della frequenza da parte del destinatario o, semplicemente, l'assenza di errori di autenticazione da segnalare. Anche l'impostazione del tag fo= determina esattamente quando viene generata una segnalazione.

• Informazioni su
• Ultimi messaggi

Ahona Rudra

Esperto di sicurezza dei domini e della posta elettronica presso PowerDMARC

Ahona è la Marketing Manager di PowerDMARC, con oltre 5 anni di esperienza nella scrittura di argomenti di cybersecurity, specializzata in sicurezza dei domini e delle e-mail. Ahona ha conseguito una laurea in Giornalismo e Comunicazione, consolidando la sua carriera nel settore della sicurezza dal 2019.

Ultimi messaggi di Ahona Rudra (vedi tutti)

• Che cos’è l’ARF? Formato di segnalazione degli abusi e rapporti di errore DMARC (RFC 5965) - 24 luglio 2026
• La maggior parte degli istituti finanziari dispone di DMARC. Quasi nessuno è protetto. - 22 luglio 2026
• Che cos’è la “fatica da MFA” (push bombing)? - 21 luglio 2026