Read DMARC Reports — What the Aggregate Reports Tell You

What arrives

Every large receiver sends one mail a day with a compressed XML attachment. One report covers one receiver and one day — for an active domain that quickly becomes ten to thirty mails daily. They therefore belong in a dedicated mailbox, not the one you work in.

Reports arrive with a lag: what comes in today describes yesterday. After a DNS change, wait at least two days before judging the effect.

How the XML is built

The interesting part of <policy_published> is as a control value — if it differs from your DNS you have a typo or a stale zone. Everything after it is the data.

Reading one record

• count is the number that matters. A row with count 3 is noise; one with 4,000 is a sending system. Counting rows instead of messages weights everything wrongly.
• policy_evaluated shows the aligned result, not the raw one. An spf=pass further down in auth_results can still appear as fail here — SPF passed, but for a domain other than the one in the From header. That difference is precisely what DMARC is.
• disposition says what the receiver actually did. Under p=none it always reads none, failures included.

The three patterns you will learn to recognise

1. DKIM pass, SPF fail, known IP. Almost always a forward. The forwarding server sends from its own IP while the signature survives. This is harmless — DMARC passes as soon as one of the two passes in alignment.
2. SPF pass, DKIM none, foreign IP. A provider you authorised who does not sign with your domain. Worth setting up DKIM signing with your own domain at that provider — otherwise delivery hangs on a single check.
3. Both fail, unknown IP, small numbers from changing countries. This is the abuse DMARC was built against. It does not disappear through reports, only through an enforced policy.

Two setup traps

External report addresses need authorisation. If the rua address sits on a domain other than the reported one, RFC 7489 requires a confirming record in the target domain:

Without it, conforming receivers send no reports at all — and the silence looks exactly like “nobody sends in my name”.

More than two destinations achieve nothing. Many receivers only serve the first one or two URIs in the list. Enter four addresses and the later ones reliably get nothing.

And the ruf reports?

Forensic reports contain individual failed messages including headers. In practice hardly any large receiver still sends them, because they carry third parties' personal data. You can set ruf, but you should not plan around it.