DMARC aggregate report walkthrough: turn rows into sender decisions

Define the decision

An aggregate report is a receiver’s summary, not a list of individual people who saw your campaign. Coverage and timing vary. Preserve the report identifier and interval so repeated downloads do not become duplicate evidence.

Work through the procedure

1. Record reporter, report ID and reporting period.
2. Group rows by source infrastructure and authentication outcome.
3. Match legitimate services using administrator records rather than IP recognition alone.
4. Investigate unknown failures and legitimate misalignment separately.
5. Assign corrections and compare a later reporting period after changes.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Row group A: known billing service, 40 observations, aligned DKIM pass
Row group B: same known service, 6 observations, alignment failure
Action: investigate the alternate billing path before changing domain enforcement
These are illustrative report counts, not recipient or inbox counts

Read the result

The second group is actionable because it belongs to a legitimate stream with a different outcome. A large volume of unknown failures may represent spoofing; it should not automatically cause you to authorize an unknown sender.

Check before moving on

1. Deduplicate reports by reporter and report identity.
2. Retain report time boundaries when comparing periods.

Limits and next action

RFC 9990 defines current aggregate reporting. Legacy report formats may remain in circulation, so use a parser that preserves unfamiliar fields and fails visibly on unsupported input.

Source: RFC 9990: DMARC aggregate reporting