Reading and understanding DMARC reports
XML files land in the dmarc mailbox daily — what is actually in them? Report structure, the fields that matter, and how to spot when action is needed.
Anyone who has set DMARC with a rua address gets mail: Gmail, Microsoft, Yahoo and many others send, usually daily, an aggregate report on which servers delivered emails with your domain in the sender address and how the checks turned out. The reports arrive as a ZIP or GZIP file with an XML file inside — unwieldy, but the only complete view of who is sending in your name.
The structure in brief
Each report contains a header (who is reporting, which period, which policy they saw on your domain) and then one record block per sending source. The three pieces of information that matter appear in every record:
- source_ip: the server that delivered the emails — plus count, how many there were.
- policy_evaluated: how SPF and DKIM turned out from DMARC's point of view (pass/fail) and which disposition the recipient applied (none, quarantine, reject).
- auth_results: the details — which domain passed SPF, which DKIM selector signed.
The three typical patterns
1. Both pass — all good
Your mail servers and sending services appear with dkim=pass and/or spf=pass aligned with your domain. This is the normal state you want to see.
2. Known source, but fail — repair
An IP recognisably belongs to one of your services (newsletter, shop) but fails — usually its DKIM or the SPF include is missing. These are the findings the monitoring phase exists for: repair them BEFORE the policy is tightened.
3. Unknown sources with fail — the protection doing its job
Unknown servers from all over the world that fail with your domain are forgery attempts or forwarded mail. With p=reject you will see disposition=reject next to them — then you are watching the protection at work. No cause for concern, quite the opposite: this is exactly what DMARC is for.
Analysing in practice
Opening individual reports by hand is only worthwhile for spot checks. With more than a handful of domains or sources, you use an analysis tool that collects the XML files and condenses them per source. What matters is less the tool than the routine: during the rollout phase look in weekly; after the switch to reject an occasional glance is enough.
Frequently asked questions
I am not receiving any reports at all — why?
Most common reasons: the rua address is misspelled, the mailbox behind it does not exist, or the address is on a DIFFERENT domain without an authorisation record (external report addresses require a confirmation TXT record on the receiving domain). And: reports only arrive once someone has actually sent emails with your domain.
What is the difference between rua and ruf?
rua are the daily aggregate reports — those are the ones you want. ruf would be per-message reports for every email that failed; most recipients no longer send them at all for privacy reasons. rua is enough.
Do I have to keep the reports?
There is no obligation to. In practice it is enough to know the evaluated state; retaining them for a few weeks helps at most when reconstructing an incident.