What is a DMARC Report?

A DMARC report is data that receiving mail providers send back to you about messages claiming to come from your domain. When you publish a DMARC record with a reporting address, providers like Google and Microsoft begin emailing you summaries of what they saw: which servers sent mail as you, and whether that mail passed SPF and DKIM alignment.

These reports turn DMARC from a blunt instrument into a measured rollout. Instead of guessing which services send on your behalf, you get an evidence-based list, so you can authorize every legitimate sender before you start rejecting failures.

DMARC defines two report types, requested with separate tags in your record:

• Aggregate reports (rua) — daily XML summaries that group message volumes and authentication results by sending source. They contain no message content, which is why nearly every provider sends them. This is the report type you will actually work with.
• Forensic or failure reports (ruf) — individual samples of messages that failed authentication, including redacted headers. They are useful for debugging a specific failure, but most providers no longer send them because the samples can expose personal data.

You request both in the DMARC record itself:

An aggregate report is an XML document covering a single provider over a single day. For each sending source it records:

• The sending IP address — the server that sent mail claiming to be your domain.
• Message volume — how many messages came from that source in the reporting window.
• SPF result — whether the message passed SPF and whether that SPF domain aligned with your From address.
• DKIM result — whether a valid signature was present and whether the signing domain aligned.
• DMARC disposition — what the receiver did with the message: none, quarantine, or reject.

Because the data is grouped by source, an aggregate report effectively answers the question that matters most for a rollout: which servers are sending as me, and which of them are failing?

Raw aggregate reports arrive as compressed XML attachments, and reading them by hand quickly becomes unmanageable once several providers report on dozens of sending sources. The practical approach is to feed them into a DMARC report analyzer, which parses the XML, resolves IP addresses to recognizable service names, and presents pass and fail rates per source over time.

With that view in front of you, the workflow is simple: for every source sending real mail, confirm it passes SPF or DKIM and aligns with your From domain. Anything failing is either a misconfigured legitimate service to fix, or a spoofer you are safe to let your policy block.

The entire reason to collect DMARC reports is to move your policy from p=none to p=quarantine and finally p=reject with confidence. Start in monitor mode, let reports accumulate for a few weeks, and use them to align every legitimate sender. Once the reports show only authorized mail passing, raising the policy is safe because you already know nothing legitimate will be blocked.

If you want the difference between SPF, DKIM, and DMARC spelled out before you begin, see SPF vs DKIM vs DMARC. ZoneWatcher's DMARC monitor then watches the record itself, flagging a missing reporting address or a policy left stuck on p=none.