Summary

  • RFC 9990 defines a structured DMARC aggregate report: a Mail Receiver reports authentication results, evaluated policy, message counts, identifiers and local override reasons for a stated period.
  • The report is not a per-message event history. Policy changes can produce a mixed-period aggregate with only one recorded policy configuration, partial overlaps cannot always be separated, and the RFC expressly warns that report data may be forged.
  • Daniel Kade proposes a privacy-minimized aggregate-reliance receipt that records generator identity, policy epoch, coverage window, file digest, overlap treatment and the consumer’s decision without retaining message bodies or individual addresses.

A useful count can still have an unobserved denominator

Consider a domain owner reviewing a morning DMARC dashboard. One receiver reports 120,000 messages; another reports 80,000; a third has not delivered its file. Some rows show an aligned pass. Others show quarantine, reject or a local-policy override. The owner can find an unauthorized sender, repair a DKIM deployment and decide whether a stricter policy is feasible.

That is valuable operational evidence. It is not the same thing as a complete census of the mailstream. The dashboard does not itself prove which receivers generated reports, which receivers chose not to, which files were lost, cached or discarded, whether two files overlap, or whether the policy shown beside a count was the policy applied to every message in that count.

The distinction is not an argument against aggregation. Aggregation is what makes reporting possible at Internet scale without distributing message content. The mistake is institutional: a consumer receives a standardized XML document and begins to treat standardization as certification of the underlying observations.

RFC 9990 is more candid than such a dashboard. Its rules expose where interpretation remains with the generator and the consumer. Those open decisions are not defects to be hidden. They are the governance surface.

What the standard actually joins

RFC 9990, published on the IETF Standards Track in May 2026, defines DMARC aggregate reporting and replaces the reporting portion of RFC 7489 alongside the newer DMARC documents. A Domain Owner advertises a reporting destination in a DMARC Policy Record. A Mail Receiver evaluates messages, prepares an XML report and attempts delivery to eligible destinations.

The report identifies the reporting organization, a Report-ID and a UTC date range. It records the policy configuration observed for the policy domain. Rows combine a source IP, a message count, evaluated disposition, alignment results and identifiers such as the RFC5322.From domain. Authentication-result elements describe DKIM and SPF results. When the receiver does not apply the requested disposition, a reason can identify local policy, a mailing list, testing mode, a trusted forwarder or another exception.

Each field answers a bounded question. The policy domain tells the consumer which administrative name organized the report. The date range defines the aggregation window, not the exact first and last message. The row count says how many messages the receiver grouped into a tuple. A policy override reason says how the receiver classified its departure from the requested policy. None is a cryptographic statement about an individual message’s full path or final placement.

The standard also says counts are based on messages received even if some other filtering agent ultimately blocks delivery. A disposition in the aggregate therefore should not be read as a universal delivery outcome. DMARC evaluation and the receiver’s larger filtering system remain separate control planes.

The row is a compression, not a replay log

A row is powerful because it collapses many messages sharing relevant attributes. That compression lets a domain owner see patterns: an unexpected source, a selector failing after a rotation, a forwarding path producing alignment failures, or a requested policy being overridden.

But compression discards joins. If 5,000 messages share a source IP and an authentication tuple, the aggregate does not expose 5,000 stable event identifiers. It cannot, by itself, answer which message was first, which recipient class was affected, which separate filter blocked one message, or which later action changed another. It is not supposed to carry message bodies, individual recipient addresses or inbox-placement evidence.

This matters when the aggregate becomes an input to automation. A system may interpret an abrupt count increase as proof of an unauthorized campaign, suspend a sender or force a policy change. The count may justify investigation. It does not, alone, establish causation or completeness. A missing receiver, changed grouping rule, delayed report or duplicate window can alter the graph without any corresponding change in the sender’s behavior.

The evidence object is the receiver’s summarized account of its evaluation. The observed mailstream is a larger object. Calling the first the second quietly gives the report generator more authority than the standard assigns.

One policy field can describe a mixed policy period

The clearest warning appears when a domain changes its DMARC Policy Record during a reporting period. Different receivers may observe the change at different times because of lookup timing, implementation choices and DNS propagation. RFC 9990 permits a receiver to produce multiple reports, one per observed configuration. It can also produce a single report containing dispositions made under the old policy or a mixture of old and new policies while carrying only one policy_published element.

The specification places awareness of that situation on Report Consumers and Domain Owners. Demanding that every receiver continuously track every policy transition at Internet scale would create a heavy burden. The trade-off is reasonable, but it has a consequence: the policy field is not necessarily an epoch label for every count beneath it.

Suppose a domain moves from monitoring to rejection at noon. A report covers midnight to midnight and displays the final configuration. Some failures in its rows may have been evaluated before the change, some after it. Without an additional epoch or separate reports, the consumer cannot safely calculate the counterfactual “all of these messages would have been rejected under the new policy.”

The governance response is not to accuse the receiver of inconsistency. It is to mark the aggregate as mixed or epoch-ambiguous and limit the decisions that depend on it.

An authenticated report is not an authenticated observation set

RFC 9990 requires the mailstream carrying DMARC feedback to obtain an aligned DMARC pass. That reduces the risk that consumers will process fraudulent reports sent from unrelated domains. Secure transport is also recommended. External destinations require a DNS authorization relationship so a domain cannot direct a flood of reports at an unwilling third party.

These are meaningful controls, and their scope should remain visible. An aligned pass authenticates a domain-alignment relationship for the report message under DMARC. External-destination verification proves that a Report Consumer has signalled willingness to receive reports for another domain. TLS protects a transport channel according to its authentication model.

None proves that every XML row corresponds to an actual set of received messages, that every count is complete or that a generator applied its policy exactly as described. RFC 9990 states plainly that the data inside aggregate reports may be forged and could be submitted at volume to influence policy or platform-architecture decisions.

The correct conclusion is not that all aggregate reports are suspect. It is that transport authenticity, generator authority, content integrity and observational truth are different claims. A consumer can trust a known receiver enough to use its data while still recording anomaly checks and avoiding irreversible actions from a single report.

Report-ID solves one identity problem

The Report-ID must be unique among reports to the same domain so a consumer can recognize duplicates. The identifier appears consistently in the report and delivery context, while the filename carries receiver, policy domain, time boundaries and an optional unique component. A retransmission must reuse the original filename.

That design gives the consumer handles for idempotency. It does not make partial overlap mathematically removable. RFC 9990 describes exact duplicates and duplicate information spread across reports, then leaves the treatment to the receiving consumer: reject, discard, inspect, accept or take another locally appropriate action. For partially overlapping time frames, it says there is no clear way to distinguish the impact; the consumer may have to accept or reject the data as a whole.

A unique label proves that two files claim different report identities. Reuse can signal a retransmission. Neither guarantees disjoint observation sets. If an analytics system automatically sums every unique Report-ID, it can manufacture confidence and volume out of ambiguity.

An accountable consumer therefore preserves both the report identity and the overlap decision. Deduplication is not a hidden preprocessing detail when the resulting number will justify a consequential change.

The destination authorization does not endorse the analysis

DMARC permits reports to go to a service outside the Domain Owner’s organizational domain. That is essential for organizations that use specialist processors. RFC 9990 requires the external destination to publish an authorization record. If the relationship cannot be confirmed, the Mail Receiver must ignore that destination.

This protects the unwilling recipient from report flooding and creates a revocable consent surface. Yet the authorization says “this service accepts reports for this domain.” It does not say that the service’s normalization, attribution, dashboards, retention or recommendations are correct. Nor does a contract with a processor transfer the Domain Owner’s responsibility to understand how evidence becomes a policy decision.

The processor may have excellent controls. The point is to record them separately: which raw files were accepted, what transformations were applied, how duplicate periods were handled, which rows were excluded and which human or rule approved the final conclusion.

Privacy is preserved by refusing the temptation to reconstruct mail

Aggregate reporting deliberately omits message content and individual-user characteristics. That limits exposure while giving Domain Owners domain-level authentication evidence. Even so, receiver traffic patterns can be sensitive, intermediaries may be governed by different policies, and Public Suffix reporting can create feedback leakage.

A better audit record should not defeat this minimization. The answer to missing event-level proof is not to collect every message body. For most governance decisions, the consumer needs provenance and decision metadata, not correspondence.

The receipt can retain a file digest, generator domain, policy domain, reporting window, policy-epoch state, accepted row-set digest, count totals, anomaly outcome and decision. It can omit local parts, recipient addresses, message content and inbox placement. Where source IP is needed for DMARC operations, access and retention can be constrained rather than copied into every downstream dashboard.

The processor itself must also treat the report as hostile input. GZIP and XML parsers face resource-exhaustion risks. Syntactic acceptance should be separated from evidentiary acceptance: a file may be parseable yet quarantined because identity, overlap or policy context is unresolved.

Keep an aggregate-reliance receipt

Daniel Kade’s proposal is a small record created when an aggregate becomes evidence for a decision. It is not an RFC 9990 requirement and does not alter the report format.

First, bind the received artifact: exact Report-ID, original filename, file digest, size, media handling, receipt time and authenticated transport result. Record the reporting organization and the identity basis used to accept it.

Second, preserve the claimed scope: policy domain, UTC begin and end, generator, report schema version and whether the window is complete, delayed or known to be partial. Do not silently replace the report’s date range with ingestion time.

Third, state the policy context. Record the policy_published value, the lookup or configuration evidence available to the consumer, and whether the window may include old and new policy epochs. If the state is mixed or unknown, label it rather than assigning every row to the final policy.

Fourth, record duplicate handling. Link reports that share an identifier, filename, generator, policy domain or overlapping time range. Preserve the decision to reject, replace, merge, accept or quarantine and the rule or reviewer responsible.

Fifth, bind transformation. Hash the accepted row set or normalized dataset, identify the parser and normalization version, preserve rejected-row counts and note ignored extensions. A dashboard should be traceable to a stable transformation without retaining the full message stream.

Sixth, preserve checks and uncertainty: malformed input, generator reputation, count discontinuity, unexpected sources, conflicting reports, missing expected reporters and suspicious volume. These are indicators, not automatic fraud verdicts.

Finally, record the reliance decision: investigate, contact a sender, rotate a key, change policy, hold, reject, roll back or supersede. Name the accountable role, threshold, evidence bundle and correction path. A later report should not erase why the earlier decision was reasonable at the time.

The receipt gives the aggregate exactly the authority it earned—no less and no more.

Evidence limits

The checked sources establish the standardized fields, reporting semantics, mixed-policy allowance, duplicate ambiguity, external-destination verification, privacy boundaries and forged-data warning. They do not establish how many receivers implement RFC 9990, whether any named organization sends inaccurate reports, how often partial overlaps occur or which commercial analysis system is most reliable.

This Article does not claim that an aggregate report is merely opinion. It is structured evidence from an operational observer. It does not claim that DMARC pass is weak, that external processors are untrustworthy or that per-message retention is desirable. The narrower claim is that a receiver’s standardized aggregate remains a receiver’s account. Consequential reliance needs a visible join from that account to policy epoch, overlap treatment, transformation and decision.

Sources