I rapporti DMARC mostrano parte del traffico osservato dai destinatari partecipanti: origini, autenticazione, allineamento e trattamento. Aiutano a indagare falsificazioni ed errori dei fornitori e a valutare politiche restrittive, senza garantire da soli che sia sicuro applicarle.
Pubblicare un record e indirizzare rua= a una casella non basta. Senza analizzare l'XML, i problemi restano inesplorati. Rivedi le basi con la posta aziendale per piccole imprese e la posta con dominio proprio. Confronta poi i rapporti con l'inventario: non coprono necessariamente tutti i mittenti né tutto il traffico.
Raccogli i rapporti, identifica i sistemi e correggi l'allineamento. Esamina gli inoltri: DKIM valido e allineato può consentire a DMARC di passare, ma non evita la verifica del percorso. Irrigidisci la politica con prove, non soltanto percentuali favorevoli.
Cosa sono i rapporti DMARC?
I destinatari partecipanti inviano informazioni dopo aver valutato messaggi che dichiarano il tuo dominio come mittente. Autenticazione, allineamento, IP sorgente e decisioni sono utili per sicurezza e recapitabilità, con copertura parziale.
Esistono due categorie principali.
I rapporti aggregati vengono generalmente richiesti con rua e arrivano in XML. Raggruppano traffico per destinatario, IP, risultati e disposizione. Aiutano a indagare se Google Workspace, Microsoft 365, SendGrid, Mailchimp, un'applicazione o un altro server invia con il dominio, senza identificare automaticamente il responsabile di ogni IP.
I rapporti di errore, richiesti con ruf, possono dettagliare messaggi secondo i criteri configurati e l'implementazione, non necessariamente solo errori DMARC. Il supporto è limitato e la riservatezza restringe il contenuto. Usali come complemento, non come unica base.
I rapporti aiutano a rispondere:
- Quali origini osservate inviano con il mio dominio?
- SPF o DKIM passa con allineamento?
- Quale traffico osservato viene messo in quarantena o rifiutato?
- Cosa potrebbero colpire
p=quarantineop=reject?
Come funzionano i rapporti DMARC?
Pubblichi un TXT sotto _dmarc.yourdomain.com con politica e destinazioni dei rapporti. I destinatari partecipanti possono inviare i dati. Una destinazione esterna può richiedere autorizzazione DNS del dominio che riceve i rapporti: verifica la configurazione.
Questo esempio usa monitoraggio con allineamento rigoroso facoltativo:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s; pct=100"Richiede monitoraggio e rapporti aggregati a dmarc@example.com. Le opzioni adkim=s e aspf=s esigono corrispondenza esatta dei domini. Sono facoltative e possono colpire mittenti che funzionano con allineamento rilassato tra sottodomini dello stesso dominio organizzativo: non sono una scelta universale.
Tag importanti:
v=DMARC1: versione obbligatoria.p=: trattamento richiesto per gli errori DMARC.rua=: destinazione dei rapporti aggregati.ruf=: destinazione dei rapporti di errore.pct=: percentuale richiesta di applicazione ai messaggi che falliscono, non rispettata uniformemente.adkimeaspf: modalità di allineamento DKIM e SPF.
La RFC 7489 definisce formato e logica. Per questo i rapporti arrivano spesso come XML compresso, non come un pannello direttamente leggibile.
Il contenuto dei rapporti aggregati
Riassumono traffico osservato per organizzazione, IP, volume, autenticazione e disposizione. Distingui risultati SPF e DKIM grezzi da quelli valutati per la politica, che incorporano l'allineamento.
Normalmente includono:
- Il destinatario che informa, come Google o Microsoft.
- Il periodo coperto.
- L'IP sorgente.
- Il numero di messaggi osservati.
- Il risultato SPF.
- Il risultato DKIM.
- L'allineamento SPF al From visibile.
- L'allineamento DKIM al From visibile.
- La disposizione DMARC: none, quarantine o reject.
Un errore SPF non dimostra sempre una configurazione sbagliata: gli inoltri cambiano l'IP. Se DKIM conserva i dati firmati, passa ed è allineato, DMARC può passare.
Destinatario: gmail.com
IP sorgente: 198.51.100.24
Numero: 842
From dell'intestazione: example.com
SPF: fail
DKIM: pass
DMARC: pass
Disposizione: none
Il risultato è compatibile con un inoltro che preserva DKIM. Verifica percorso e allineamento: autenticazione valida non dimostra contenuto sicuro o legittimo.
Destinatario: outlook.com
IP sorgente: 203.0.113.77
Numero: 314
From dell'intestazione: example.com
SPF: fail
DKIM: fail
DMARC: fail
Disposizione: quarantine
Indaga: mittente legittimo mal configurato, nuovo fornitore, modifiche degli intermediari o falsificazione sono possibili. Il rapporto non sceglie automaticamente una causa.
Rapporti aggregati o di errore
Gli aggregati danno una visione ampia ma parziale di origini e destinatari partecipanti. Quelli di errore dettagliano alcuni messaggi quando disponibili. Nessuno sostituisce inventario, test e verifica dei flussi critici rari.
| Tipo | Richiesta | Dati | Uso principale | Situazione nel 2025-2026 |
|---|---|---|---|---|
| Aggregato | rua=mailto:... | Riepiloghi XML, spesso giornalieri, per origine, autenticazione e disposizione | Inventario osservato, allineamento e valutazione delle politiche | La base di dati abituale di molti team |
| Errore / forense | ruf=mailto:... | Dettagli dei messaggi, spesso parziali o oscurati | Indagare errori o abusi specifici | Supporto irregolare; molti grandi destinatari ne inviano pochi o nessuno |
Un fornitore di analisi dovrebbe spiegare la differenza e permettere di intervenire sui risultati, non soltanto mostrare grafici.
Leggere i rapporti in modo efficiente
Parti dalle origini di maggior volume, collegale ai sistemi noti e correggi gli errori legittimi. Non scartare piccoli volumi quando rappresentano processi critici o poco frequenti.
Procedura pratica:
- Esamina le origini con maggior volume osservato.
- Identifica il sistema: Google Workspace, Microsoft 365, marketing, applicazione, supporto o origine sconosciuta.
- Verifica che SPF o DKIM passi con allineamento al From visibile.
- Correggi gli errori legittimi prima di cambiare politica.
- Indaga le origini sconosciute prima di classificarle come abuso: possono essere inoltri o relay condivisi.
Il volume aiuta a dare priorità, ma una fattura occasionale o un messaggio di recupero può essere essenziale. Considera l'importanza di ogni flusso.
| Risultato osservato | Possibile spiegazione | Azione |
|---|---|---|
| SPF pass, DKIM pass, DMARC pass | Autenticazione valida e allineata | Documentare l'origine; non prova contenuto sicuro |
| SPF fail, DKIM pass, DMARC pass | Inoltro o differenza nel percorso SPF | Verificare DKIM allineato e la sua conservazione |
| SPF pass, DKIM fail, DMARC pass | SPF allineato consente di passare nonostante DKIM | Indagare e correggere DKIM |
| SPF fail, DKIM fail, DMARC fail | Abuso, configurazione o modifica del percorso | Esaminare origine e messaggio |
| IP sconosciuto con volume | Servizio non inventariato, relay, inoltro o abuso | Identificare prima di valutare un blocco |
Le correzioni possono includere:
- Aggiungere l'autorizzazione SPF adatta a un mittente legittimo.
- Attivare e verificare DKIM dal fornitore.
- Configurare un return-path proprio per aiutare l'allineamento SPF.
- Usare un sottodominio per separare un servizio se necessario.
- Rivedere gli inoltri e preservare le firme senza dipendere solo da SPF.
Queste interrogazioni aiutano a verificare la pubblicazione:
dig TXT _dmarc.example.com +short
dig TXT example.com +short
dig TXT selector1._domainkey.example.com +shortSe ci sono errori DNS, consulta i record DNS richiesti e la guida ai messaggi che finiscono nello spam di TrekMail, senza attribuire tutto all'XML.
Problemi che i rapporti possono rivelare
I rapporti aiutano a rilevare autenticazione incompleta dei fornitori, mancato allineamento, modifiche degli inoltri e politiche senza monitoraggio. Confronta sempre con la configurazione reale.
Un nuovo servizio può inviare con il dominio senza SPF o DKIM configurati correttamente. Un IP sconosciuto è un indizio, non prova di falsificazione.
SPF può anche passare per il dominio della busta senza allinearsi a From. Senza DKIM valido e allineato, DMARC fallisce. Succede con marketing o supporto senza dominio di ritorno personalizzato.
Dipendere solo da SPF complica gli inoltri. Se DKIM manca o viene invalidato, può sparire l'autenticazione allineata. Consulta configurazione e correzione dell'inoltro per valutare percorsi indiretti.
Pubblicare p=none e accumulare rapporti senza leggerli non corregge configurazioni né richiede blocchi.
Passare troppo presto a p=reject può colpire messaggi legittimi. Verifica mittenti abituali ed eccezionali prima delle restrizioni.
Il ruolo di TrekMail
I rapporti aiutano se puoi applicare le correzioni. TrekMail può coordinare domini e controlli DNS secondo il piano, ma occorre verificare anche i servizi esterni.
Un ambiente disperso richiede diversi hosting, SMTP separati e rapporti in una casella condivisa, oltre all'inventario dei nuovi mittenti.
Un percorso coordinato può riunire hosting multidominio, configurazione SPF/DKIM/DMARC, controlli DNS, SMTP proprio o gestito, caselle, inoltri e migrazione secondo le funzioni disponibili. L'hosting di posta multidominio descrive il modello.
TrekMail offre domini personalizzati, caselle IMAP, catch-all, inoltro e migrazione IMAP compatibile secondo il piano, con API nei piani corrispondenti. Per Nano, consulta SMTP proprio. I piani a pagamento che lo includono possono usare SMTP gestito; Starter è pubblicizzato da $3.50 al mese. Nano viene offerto gratuitamente senza carta e i piani a pagamento possono includere una prova di 14 giorni con carta richiesta. Verifica le condizioni vigenti.
I rapporti non correggono nulla automaticamente: forniscono indizi. Coordinare configurazione e test può facilitare gli interventi.
Quando passare da p=none a quarantine o reject?
I rapporti mostrano autenticazione allineata nel traffico osservato, senza garantire che tutti i mittenti siano pronti. Completa l'inventario e prova i processi critici prima di valutare quarantine e reject.
I record rappresentano fasi alternative: pubblica solo quello adatto, non tutti insieme.
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=25"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100"La percentuale richiede copertura dei messaggi che falliscono, non applicata uniformemente. Esamina più cicli e processi rari, conferma autenticazione allineata e verifica che gli inoltri preservino DKIM quando ne dipendi.
Google richiede SPF o DKIM per i mittenti generici verso Gmail personale; per quelli di grandi volumi, entrambi e DMARC con l'allineamento applicabile. Consulta le domande frequenti sulle linee guida per i mittenti Gmail.
Conclusione: integrare i rapporti nella gestione
I rapporti mostrano origini e risultati osservati e aiutano a decidere cosa indagare e correggere. Inseriscili nelle verifiche periodiche insieme a inventario e test, anziché lasciarli in una casella ignorata.
Con molti domini e fornitori, coordinare gli strumenti può aiutare. Secondo il piano, TrekMail offre hosting multidominio, spazio condiviso, migrazione IMAP, SMTP proprio o gestito e configurazione di autenticazione. Verifica l'opzione gratuita o i prezzi TrekMail secondo le tue esigenze, senza presumere che una piattaforma garantisca una politica sicura.
