What does a DMARC report actually show?

Publish a DMARC record with a reporting address and something slightly surreal happens: Google, Microsoft, Yahoo and hundreds of other mail operators around the world begin emailing you. Daily. Each message contains a compressed attachment, inside which is an XML file, inside which - somewhere - is the answer to whether anyone is impersonating your domain.

Open one and you will find several hundred lines of angle brackets, IP addresses and result codes. These files were designed for machines to exchange, not for humans to read. But everything in them follows a fixed structure, and once you know what each field means, the mystery evaporates. Let us take one apart.

Who sends them, and when

Every mail provider that receives email claiming to be from your domain - and that participates in DMARC reporting, which all the major ones do - compiles what it saw into an aggregate report, usually once per 24 hours, and sends it to the rua= address in your DMARC (Domain-based Message Authentication, Reporting and Conformance) record. A modestly active domain might receive five to thirty such files a day from different providers.

Two reassurances worth stating early. First, aggregate reports contain no email content - no message bodies, no subject lines, no recipient addresses. They are statistics about authentication, nothing more. Second, receiving a report about failed mail does not mean your systems were breached; it usually means someone, somewhere, sent mail claiming to be you - which is exactly what the system exists to surface.

The anatomy of a report

Each XML file has three parts.

1. Report metadata. Who compiled it (google.com), a unique report ID, and the date range covered - expressed, unhelpfully, in Unix epoch seconds (1718150400 means a date, if you happen to think in seconds since 1 January 1970).

2. Published policy. The DMARC policy the reporter saw on your domain at the time: your p= level, subdomain policy, and alignment settings. Useful as confirmation that the world sees what you think you published.

3. The records - the part that matters. One block per source, each containing:

• - the IP address of the server that sent the mail. Just a number, like 203.0.113.47. Identifying whose server that is requires looking the address up - it might be Microsoft 365 sending your genuine mail, your newsletter platform, or an unrelated machine on another continent.
• - how many messages from that source in the period.
• - what the receiver did: none (delivered), quarantine (junked) or reject (refused), per your policy.
• - the headline verdicts: did the message pass aligned SPF and DKIM? These are the results that decide DMARC pass or fail.
• - the raw detail underneath: which domain's SPF (Sender Policy Framework) record was checked and the outcome; which DKIM (DomainKeys Identified Mail) selector signed and whether it verified.
• - the domain shown in the From line recipients see.

Reading a record is answering one question: this source sent this many messages as us - were they genuine? A pass on aligned SPF or DKIM says yes. Failures on both say either "spoofing attempt" or "legitimate sender we have not configured properly" - and telling those apart is the whole craft.

Why the raw data is unreadable in practice

One record is manageable. The reality is volume and fragmentation: dozens of files daily, from different reporters, in slightly different dialects, each listing bare IP addresses that mean nothing without enrichment. To answer even simple questions - is anything new sending as us this week? did our invoice system's DKIM break? is that cluster of failures in Asia an attack or a misconfigured forwarder? - you must aggregate every file, resolve every IP to an owner, track changes over time, and know what normal looks like for your domain.

That is a data-processing job, not a reading job. It is why most businesses that dutifully add a rua= address end up with a mailbox of unopened ZIP files and no more insight than before - the reports arrive, and nobody can hear what they are saying.

What interpretation looks like

The same data, processed and translated, reads like this - an extract in the style of a SealedMail weekly report:

> Your domain sent approximately 1,240 emails this week, all from your two authorised systems (Microsoft 365 and Xero). All passed authentication - nothing legitimate is at risk of being junked.

>

> One thing to be aware of: 38 messages claiming to be from your domain were sent from three IP addresses in Vietnam and Brazil. None passed authentication. Because your policy is p=none, receiving providers will have delivered some of these. This is consistent with low-level spoofing of your domain. No action is needed from you this week, but it strengthens the case for moving towards an enforcement policy - we will recommend timing once your authorised senders have shown a clean fortnight.

That is the entire job of a DMARC report: not the XML, but the answers - what happened, whether it matters, what to do. The data and its interpretation are equally necessary; the raw report without interpretation is noise, and interpretation is only as good as complete data.

Two ways forward

If you have the time and technical appetite, you can absolutely process your own reports - parse the XML, resolve the IPs, build the history. Plenty of self-serve dashboard tools will do the aggregation and leave the interpretation to you.

If you would rather the entire pipeline - receiving, processing, interpreting, explaining - arrived as one plain-English email each week, that is precisely what SealedMail does, for £49 per domain per month. Either way, start by understanding the system the reports serve: What is DMARC? covers the foundations, and Why DMARC p=none is not protecting you explains where the reports fit in the journey to enforcement.

Not receiving reports at all? Then your domain currently has no visibility of its own name being used. SealedMail's Free Domain Health Check will confirm your DMARC record's status - including whether your reporting address points anywhere that still exists - free, by email, no sign-up.