Summary

  • RFC 9990 gives Domain Owners a standard XML aggregate report from Mail Receivers: a bounded observation of policy, authentication outcomes, source-IP rows and counts over a reporting period.
  • A report destination’s DNS confirmation authorises a reporting relationship, not a universal data licence or an enforcement decision; malformed and forged reports remain hostile or uncertain inputs even when their delivery path looks legitimate.

The first duty in reading an aggregate report is to preserve its point of view. RFC 9990, published as an IETF Standards Track document in May 2026, says that the report carries the DMARC policy configuration observed by the receiving system. Its records say that IP addresses were seen delivering messages for the Author Domain to that receiving system. Those two qualifications are not legal disclaimers pasted onto a universal truth. They define the evidence object.

An operator may receive a row with an IP address, a count, SPF and DKIM outcomes, a policy disposition and an override reason. It can reveal a forgotten bulk-mail supplier, a forwarding route, a key-rotation problem or an abuse pattern worth investigating. Yet the row does not say that every receiver saw the same traffic. It does not identify the person who wrote a message. It does not establish why a receiver made a local disposition, whether another receiver would have done the same, or whether the source intended to mislead anyone.

That distinction becomes urgent when a dashboard turns the row into an action. A count is easy to rank. A reject label looks decisive. A security team under pressure may route it straight into a supplier block, an account restriction or an executive incident report. The protocol has not made those decisions. It has supplied a common way to move a receiver's observations to a Domain Owner.

The period is a measurement frame, not a complete history

The XML structure is deliberately concrete. RFC 9990 requires report_metadata, policy_published and at least one record; it permits the reporting organisation to supply its name, contact, unique report identifier and the UTC range for the reporting period. The period normally covers one UTC day and should not overlap other periods. Crucially, the beginning and end timestamps identify the reporting period, not the first and last messages that the receiver observed.

That small distinction changes a great deal. A report covering a day does not promise that a receiver saw all mail connected with the domain that day. It does not say how much traffic another receiver saw, whether a delivery attempt was retried outside the window or whether a message was excluded before the report's aggregation logic. The document gives a disciplined time box for a record, not a warrant to fill every gap around it with inference.

The same restraint applies to authentication detail. RFC 9990 places DKIM and SPF outcomes inside auth_results but says they are uninterpreted with respect to DMARC. A policy-override reason is a predefined type plus an optional comment describing why an observed policy was overridden. Both are useful operational traces. Neither turns the report into an account of human identity, message truth or institutional fault.

This is why one receiver's observation should be joined to local evidence before it changes a consequential control. Match it with the domain's authorised-sender inventory, relevant signing-key and DNS history, sending logs, complaint evidence, repeat observations from independent receivers and the operator's own change record. Keep the original report hash and the derived dashboard field separate. A graph that says “high risk” is not an original protocol field; it is a new decision made by the organisation that built the graph.

A route for the report is not a mandate for its use

DMARC lets a Domain Owner request aggregate reports at a rua destination. That destination may be operated by another division, a managed security provider or a specialist processor outside the Domain Owner's organisational domain. RFC 9990 therefore requires an external-destination verification procedure. The Mail Receiver checks a specifically constructed DNS name for a qualifying record. If the relationship cannot be confirmed, the receiver must ignore the requested URI. If it is confirmed, the Report Consumer may, within the protocol's constraints, override the destination it will receive.

The check is important. Without it, a malicious actor could point a policy at a victim address and induce many receivers to send unwanted reports there. It is reciprocal routing authority: the external consumer has said it is willing to receive reports for that reporting relationship.

It is not more than that. DNS confirmation does not identify every analyst who will read an extracted row. It does not select a retention period, prohibit onward transfer, decide whether a consumer may enrich the data with other sources, approve a model-training use or authorise a block on a supplier. Even the aggregate data requires judgement: RFC 9990 notes that a third-party recipient may be constrained by the Mail Receiver's privacy policy or terms, and that report recipients may be able to conduct traffic analysis.

The report excludes individual mail addresses, individual IP addresses and message content, but it still maps domain-level authentication activity across a receiver's network.

A sensible reporting inventory should therefore bind more than a DNS name. For every external consumer, record the policy domains it may receive, accountable owner, stated purpose, permitted transformations, access group, retention horizon, onward-transfer rule, incident contact and deletion evidence. Compare that inventory to the confirmed DNS relationship. The DNS record keeps a receiver from becoming an involuntary reflector; it cannot carry the full governance of what happens after receipt.

Authentic delivery, valid XML and true content are different tests

RFC 9990 asks mail streams carrying feedback data to conform to DMARC so that they result in an aligned pass. The purpose is explicitly modest: it minimises the risk that a Report Consumer processes fraudulent reports. The report is ordinarily transported as an XML attachment, often GZIP-compressed, and a duplicate can be identified by its report identifier or filename. These are useful controls for getting an artifact to the right place and making duplicate handling tractable.

They are not a proof that every assertion inside the artifact is correct. The specification says that aggregate data may be forged and could be sent in volume to influence policy or platform-architecture decisions. It also warns that a malformed report can target a report processor's decompressor or XML parser with a zip bomb or XML bomb. A document can have a familiar filename, arrive at an authorised destination and still be incomplete, malicious or false.

The operational rule follows directly from the source material: validate before deriving. Put size, compression-ratio, parser-complexity and schema checks ahead of dashboard ingestion. Preserve the raw artifact in a restricted store, but quarantine content that exceeds the system's safe budget. Treat a mismatched format as evidence in question; RFC 9990 says an evaluator may discard it or sideline it while collaborating with the generator. A parse success is not the same as a reliable observation, and a reliable observation is not the same as a justified action.

The data path needs its own separation of duties. The service that receives mail should not be the service that changes an enforcement configuration. The system that extracts rows should record which validator version accepted them. The dashboard should disclose whether a number came directly from a signed/validated report, a transformed record or an analyst's reconciliation. And any control that changes mail treatment, supplier status or account access should require an owner outside the ingestion pipeline.

Aggregate reporting informs policy; it does not supply policy

RFC 9989, the current DMARC core document, makes the decision gap unusually clear. It says that, depending on mail cadence, a Domain Owner may need many months of consuming aggregate reports before it is sure all of its mail is properly authenticated. The choice of a p value depends on the owner's needs. That is not an invitation to postpone decisions indefinitely. It is an acknowledgement that reporting accumulates evidence before a local operator chooses a policy with real delivery consequences.

The safe sequence is therefore: observe, validate, compare, decide, then record the effect. Observation belongs to the Mail Receiver. External-destination confirmation belongs to the Report Consumer's willingness to receive. Parsing and storage belong to the evaluator. A policy choice belongs to the operator who will bear its effects. No single XML file crosses all four boundaries by itself.

Editorial interpretation: a bounded common layer

This is an editorial frame, not an IETF requirement. Interoperability needs a common report vocabulary, a stable transport expectation and an anti-reflection check. It does not need the report format to appoint a universal authority over mail policy. The operational test is concrete: which receiver observed the mail, which validator accepted the artifact, which owner made the policy change and which outcome followed? Those are separate realities, not paperwork around one automated truth.