Report DMARC e protocollo DMARC: che cosa mostrano i dati

Hai configurato DMARC e inizi a ricevere allegati XML da Google, Microsoft o Yahoo. Ora occorre distinguere un report DMARC dal protocollo stesso.

DMARC è un protocollo di autenticazione, politiche e report; il record DNS configura la politica richiesta. Il report contiene osservazioni di alcuni destinatari dopo la valutazione di messaggi con il tuo dominio. La configurazione esprime una richiesta; il report fornisce dati parziali.

Per configurare la posta, consulta come creare email con il tuo dominio. Se l’inoltro compromette l’autenticazione, leggi come inoltrare la posta del dominio a Gmail. Qui interpretiamo i report dopo la configurazione.

I report possono arrivare dopo la pubblicazione, senza tempi garantiti né partecipazione di tutti i destinatari. Confondere record, politica, indirizzo dei report e risultati può portare a modificare DNS che non causano il problema.

Vedremo il contenuto del report, la differenza rispetto al record e i campi rilevanti, senza attribuire automaticamente un errore ad abuso o inoltro.

Che cos’è un report DMARC?

Un report aggregato riassume dati di un destinatario partecipante: SPF, DKIM, allineamento a From, politica trovata e trattamento dichiarato per i messaggi osservati.

Il report non è la politica. I destinatari che supportano i report possono consultare il DNS, valutare messaggi con il tuo dominio in From e inviare riepiloghi a rua. RFC 7489 definisce i report aggregati per aiutare a capire autenticazione, correzioni ed effetti delle politiche. L’invio è facoltativo.

Report DMARC e record DMARC

Il record DNS configura DMARC; il report fornisce telemetria dei destinatari partecipanti. Nessuno costituisce un inventario completo di tutti gli invii.

La correzione dipende dal problema. Un record non valido può impedire l’applicazione della politica; un record valido con errori richiede di esaminare servizi autorizzati, inoltri, allineamento e possibili fonti non autorizzate. Il report non decide da solo.

Che cosa contiene un report DMARC?

I report raggruppano messaggi per IP e risultati. Controlla origine, volume, SPF, DKIM, allineamento e disposizione. Nell’XML, auth_results contiene risultati di autenticazione senza valutazione dell’allineamento e policy_evaluated risultati SPF e DKIM che ne tengono conto; non confonderli.

L’XML può includere politica pubblicata, disposizione, identificatori SPF e DKIM e risultati. DMARC passa se SPF o DKIM passa con allineamento. Una disposizione none non dimostra un risultato DMARC riuscito né necessariamente una politica di monitoraggio; quarantine o reject dichiara un’azione, non la legittimità o sicurezza del contenuto.

Un errore SPF non significa che tutte le email falliscano. Se DKIM passa con allineamento, DMARC passa; anche SPF valido e allineato può bastare.

Leggi il report in questo ordine:

1. Controlla l’IP di origine e l’organizzazione che invia il report.
2. Valuta il volume. Un messaggio e 20,000 messaggi hanno impatti diversi; anche un invio isolato può essere critico.
3. Controlla la disposizione none, quarantine o reject senza confonderla con il risultato DMARC.
4. Confronta SPF e DKIM distinguendo autenticazione e valutazione con allineamento.
5. Verifica l’allineamento al dominio reale di From.

Report aggregati e report di errore

Un report DMARC indica generalmente l’aggregato richiesto tramite rua. I report di errore o forensi usano ruf, possono fornire dati di messaggi specifici e sono meno supportati. Non richiedono sempre messaggi completi e possono contenere dati sensibili.

Per una sola destinazione, partire da rua è spesso utile, con monitoraggio, controllo degli accessi e autorizzazione DNS sul dominio destinatario esterno quando necessaria. Le linee guida di invio di Google spiegano che l’autenticazione può influenzare il trattamento secondo i requisiti applicabili. I report forniscono dati operativi, non garanzie di recapito.

Pubblicare un record che richieda report DMARC

Pubblica il TXT su _dmarc con politica e destinazione valida. Il monitoraggio permette di richiedere dati prima delle restrizioni, anche se restano attivi i filtri locali.

Questo esempio usa allineamento rigoroso: non è una configurazione iniziale universalmente sicura. Adattala dopo aver verificato i flussi e i loro domini:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

Come sostituzione successiva, dopo inventario e test dei flussi legittimi, puoi valutare questa politica restrittiva:

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"

La modalità rigorosa richiede il dominio esatto; quella rilassata confronta il dominio organizzativo. Il campionamento dipende dal destinatario e non impone restrizioni con il monitoraggio. Considera il rifiuto dopo test, esame dei flussi rari e un piano di ripristino, non soltanto report apparentemente corretti.

Verifica la pubblicazione con una ricerca:

dig TXT _dmarc.example.com +short

In TrekMail, la procedura guidata e i controlli DNS disponibili possono rilevare assenze o conflitti. Confronta ricerche esterne e messaggi reali: il pannello non dimostra tutti i flussi. Consulta l’aggiunta di un dominio e le email che finiscono nello spam.

Leggere un report senza conclusioni affrettate

Esamina separatamente gli errori previsti e le fonti potenzialmente abusive. Un inoltro può spiegare SPF fallito; un IP sconosciuto non dimostra una falsificazione.

Il report aiuta a misurare i risultati delle fonti osservate e conoscere il trattamento dichiarato. Non dimostra il recapito né la sicurezza del contenuto.

Perché l’inoltro complica i report

Dopo l’inoltro, il destinatario successivo valuta SPF per l’IP del relay e il dominio reale di MAIL FROM. Questo può generare errori anche con un messaggio originale legittimo.

Non aggiungere automaticamente a SPF gli IP di caselle personali o vecchi relay. DKIM può preservare un risultato allineato se la firma resta valida e i dati firmati sono conservati dopo la canonicalizzazione; dire che il messaggio è cambiato poco non basta.

SRS può modificare il mittente della busta per SPF senza ripristinare l’allineamento al From originale. ARC può orientare eccezioni locali, non trasformare un errore in autenticazione DMARC riuscita. Consulta la configurazione e risoluzione dei problemi di inoltro.

Quando un report giustifica cambiamenti DNS

Modifica il DNS quando l’esame identifica un mittente autorizzato la cui configurazione deve cambiare. Conferma prima il servizio reale e il meccanismo che fallisce.

Valuta cambiamenti in questi casi:

1. Il dominio reale della busta deve autorizzare tramite SPF il fornitore che usa l’IP osservato.
2. Il fornitore firma con un altro dominio e non resta alcun meccanismo valido e allineato; configura e attiva DKIM personalizzato o Return-Path adeguato, non soltanto tracciamento dei link.
3. Un’applicazione usa un vecchio percorso SMTP: conferma il cambiamento necessario e testa la nuova configurazione.
4. Il record manca di destinazione rua, contiene sintassi non valida o una politica inadatta alla fase verificata.

Non modificare SPF soltanto perché un report mostra un IP di inoltro Gmail o Outlook che fallisce.

TrekMail può centralizzare domini, controlli DNS, caselle, migrazione e SMTP secondo il piano, anziché coordinare registrar, XML e cinque fornitori senza inventario. Verifica comunque l’invio reale e il limite SPF dei meccanismi e modificatori che richiedono DNS, incluse valutazioni annidate, senza duplicare record. Consulta impostazioni IMAP e SMTP oppure hosting email multidominio.

Occorre leggere ogni report manualmente?

Per un dominio piccolo, la lettura manuale iniziale può funzionare. Con più dati, un analizzatore o una casella dedicata aiuta a organizzare XML e controllare l’accesso.

Con un dominio e pochi mittenti, leggere i report disponibili durante l’implementazione può essere fattibile. Con dieci domini richiede più tempo; con cinquanta, pianifica l’analisi e standardizza la configurazione senza presumere report quotidiani da tutti i destinatari.

Report senza errori per fonti note possono essere incoraggianti, ma non dimostrano un inventario completo. Prova anche messaggi rari o critici; una disposizione restrittiva non dimostra da sola una falsificazione.

Processo consigliato per i report DMARC

Pubblica, osserva, confronta l’inventario, correggi autenticazione e allineamento e poi valuta le restrizioni. I report sono una fonte parziale, non un’autorizzazione automatica a rendere la politica più restrittiva.

1. Pubblica DMARC con p=none e una casella dedicata monitorata.
2. Raccogli report per diversi giorni come prima osservazione, senza garantire che ogni destinatario li invii o che ciò copra tutti i flussi.
3. Esamina tre categorie possibili: mittente autorizzato, effetto dell’inoltro o falsificazione; lascia non classificate le fonti non identificate.
4. Correggi i mittenti autorizzati e verifica gli inoltri con DKIM valido e allineato, senza ignorarli indiscriminatamente.
5. Valuta quarantine e poi reject dopo aver confrontato report, log e test dei flussi critici rari, con un piano di ripristino.

Ogni nuovo strumento richiede di verificare SPF, DKIM e il Return-Path realmente usato. Cambiare servizio può modificare l’allineamento senza cambiare il TXT DMARC.

TrekMail e il coordinamento DNS

TrekMail non sostituisce DMARC. Secondo il piano può centralizzare parte della gestione, ma devi ancora pubblicare e verificare record e mittenti.

Domini personalizzati, caselle IMAP, catch-all, inoltro, copia IMAP e SMTP proprio o gestito dipendono dall’offerta e dal piano. Per agenzie e MSP, gestione multidominio e spazio condiviso possono aiutare l’organizzazione. La copia non sostituisce il cambio dei record MX e non migra tutte le applicazioni.

Una tariffa per utente non implica assenza di inventario o strumenti. Confronta processi, limiti e costi: l’offerta descritta presenta piani da $3.50 al mese, Nano senza costi né carta secondo le condizioni e una prova gratuita di 14 giorni per piani a pagamento soggetta ai requisiti applicabili. Consulta la pagina dei prezzi di TrekMail; non sono garantiti risparmi o assenza di incidenti.

Conclusione sui report DMARC

Il report fornisce osservazioni sulla politica e sull’invio reale. Non sostituisce il DNS né dimostra che tutta la configurazione e tutti i flussi corrispondano.

Ricorda la differenza: DMARC è il protocollo, il DNS configura la sua politica e i report parziali aiutano a esaminare mittenti, possibili falsificazioni e quando valutare quarantena o rifiuto. Combinali con inventario, log e test per decidere, senza garanzie di recapito.