DMARC aggregate report

The reporting receiver's identity and the period covered, which is normally one day.

The DMARC policy that was published when the mail was evaluated, so a report can be read against the right configuration.

Rows grouped by sending address, each with a message count.

For each row, whether SPF and DKIM passed, and whether each aligned with the domain the recipient saw.

The disposition applied — delivered, quarantined, rejected — which is what the policy actually caused to happen.

Most organisations do not know every system that sends as their domain. A billing platform, a ticketing system, an old script on a server nobody owns.

Moving to enforcement without that list means discovering the forgotten senders by having their mail rejected, usually by whoever depended on it.

The reports produce the list. A few weeks of them is enough to see the recurring sources and separate them from background forgery.

The sequence that works is: publish a reporting-only policy, read reports until the legitimate sources are identified and authenticated, then tighten.

Which is also why a policy with enforcement and no reporting address is a configuration nobody can steer.

No message content. A row is a count, not a copy of anything.

No recipient addresses, which is what keeps aggregate reporting a low-sensitivity mechanism.

No subject lines, and nothing identifying an individual message.

The separate forensic reporting address is the one that carries per-message detail including content, which is why it is treated differently and is optional.

So publishing an aggregate address is a low-risk step, and it is the one that produces almost all of the value.

They arrive as compressed XML attachments, in volume, from every receiver that supports the mechanism.

Reading them by hand works for a day or two and stops being practical immediately afterwards.

A processing service turns them into a view of sources over time, which is what the exercise actually needs.

Expect a long tail of forged sources that will never authenticate — that traffic is the reason for the policy, not a problem to fix.

The rows that matter are recurring sources with consistent volume that fail alignment, because those are usually yours.

The aggregate reporting destination published in the DMARC record is read and reported.

So is the forensic destination, which is optional and carries message content.

A policy published with no aggregate address is reported as the half-finished state it is: enforcement without visibility.

Whether the destination actually accepts and processes reports is not tested, and a destination that silently stops working produces no signal at all.