Reading DMARC aggregate reports before tightening policy

#email #dmarc #monitoring

Reading DMARC aggregate reports before tightening policy

DMARC gives a domain owner a way to publish authentication policy and request feedback from receiving mail systems. The aggregate report is not a compliance checkbox. It is a compressed XML summary of observed message flows, authentication results, alignment, and dispositions. A team that moves from monitoring to enforcement without reading those reports can block legitimate mail and miss a sender that never authenticated.

The IETF's current DMARC documents describe policy evaluation and the reporting formats. Aggregate reporting is separate from failure reporting, and a report receiver may apply its own sampling, aggregation, and delivery behavior. Treat the data as evidence with scope and delay, not as a complete inventory of every message sent.

Know what the report can show

An aggregate record typically links an observed sending source and count with SPF and DKIM results and an evaluation of identifier alignment. It can show that messages passed DMARC through one mechanism but not another, or that a sending domain's traffic is appearing from an unexpected source. It does not explain intent. A large count from a cloud provider may be a legitimate application, a marketing platform, or abuse that happens to share the domain.

The reporting address is controlled by the domain's policy, and external destinations have their own authorization considerations. Redact local identifiers before sharing reports outside the team, and protect the mailbox that receives them. A report can reveal customer domains, partner relationships, and delivery patterns even when it contains no message bodies.

Build a sender inventory

Before changing policy, map each observed source to an owner, application, and sending path. Record the domain and subdomain, the SPF and DKIM identifiers, the source IP or cloud service, the volume, the alignment result, and the date range. Then ask the owner whether the flow is still needed. A report is only useful when it leads to a named owner and a decision.

Check the subdomain policy separately. A parent domain's policy does not automatically explain every subdomain's traffic, and a sending service can use a different From domain than the envelope sender. Review both DNS records and actual messages. The report may not include every message that failed before reaching a reporting receiver.

Tighten in stages

A conservative rollout looks like this:

Publish a monitoring policy and collect reports over a period that covers monthly or seasonal business activity.
Identify every sender that lacks aligned DKIM or SPF and verify its authentication path.
Move those senders to an aligned configuration or explicitly retire them.
Change the policy at a controlled percentage or subset where the implementation supports it.
Monitor rejects and user reports alongside aggregate pass rates.
Complete enforcement after the remaining senders have accepted the change.

Do not use the DMARC policy to compensate for a broken forwarder or for mail that is supposed to be sent through a domain the organization does not control. Fix the identity or obtain the appropriate authorization. If a third-party sender cannot comply, document the exception and choose a policy that matches the real business requirement.

Preserve useful evidence

Store reports with the policy record, DNS snapshots, and the decision log. Keep enough data to compare before and after the change, but apply a retention limit and access control. Build alerts for changes in source mix, new high-volume senders, and a sudden shift in alignment. A daily aggregate feed is a monitoring signal, not a real-time anti-phishing detector.

When a report looks suspicious, verify the receiving system, the reporting domain, the compressed file type, and the XML against the documented format before opening it in a privileged analyst workstation. Treat report content as untrusted input. A mailbox designed to receive reports should have the same parsing and attachment controls as any other external feed.

Make enforcement reversible

Keep a tested rollback path and an owner for it. If enforcement produces a delivery failure, the team should know whether the fix is a DNS change, a sender configuration change, or a temporary policy adjustment. Do not publish a stronger policy and leave the rollback decision to an untested guess during an outage.

DMARC reporting is most valuable when it changes a concrete decision: a sender is retired, a DKIM key is aligned, a subdomain policy is corrected, or an enforcement date is delayed because evidence is incomplete. The final test is whether the domain owner can name every approved sender and show why the policy is safe for the traffic that remains.