Feedback Is the Control Loop
This chapter explains how email deliverability becomes observable through DMARC aggregate reports and the other signals that surround them. The focus is not on reading an XML document for its own sake, but on understanding how a receiver's observations become evidence for a domain owner's next decision. By the end, you should be able to interpret an aggregate-report record at a conceptual level, separate underlying SPF and DKIM results from DMARC disposition, recognize a policy override, and see why feedback must be secure and actionable before it can guide policy.
Authentication answers a question about a message at a point in time. Operations need a different kind of answer: Which systems are sending for this domain? Which streams are legitimate? How many messages are failing because of alignment? Did a receiver apply the published policy, and if not, why? A report is the mechanism that turns those recurring observations into something a domain owner can compare, assign, and repair.
The result is a control loop. A receiver evaluates mail and preserves selected facts. A report consumer validates and organizes them. A domain owner compares the evidence with its inventory of vendors, applications, and recipient relationships. Someone repairs a sending path or list process, then watches later observations before changing policy. If any link is missing, the report may exist without producing better delivery.
What an Aggregate Report Lets You See
DMARC aggregate reporting is designed to give domain owners visibility into the mail streams that use an Author Domain. A participating receiver can report which IP addresses it saw sending on behalf of the domain, what authentication results it obtained, what policy it discovered and applied, and what effect that policy had on the messages. The report can contain both messages that passed and messages that failed. That combination is important: a domain owner needs to find attempted spoofing, but also needs to find legitimate vendors or internal systems that are not yet authenticated correctly.
Reports are periodic rather than event-by-event explanations of one mailbox. RFC 9989 recommends that participating receivers send aggregate reports at least daily, and RFC 9990 describes daily or more frequent feedback as the normal form. The reporting period usually represents a UTC day, though the standards allow a receiver's implementation to determine the exact handling of changes and delivery. The goal is a repeated view of the stream, not a promise that every message will generate a separate diagnostic notice.
A report is organized around a DMARC Policy Domain. Each report contains data for one policy domain and one policy configuration. It can still contain records for multiple visible From domains when those domains rely on the same discovered policy. For example, a report for example.com can include one record for example.com and another for foo.example.com if the subdomain uses the policy discovered at example.com. A separate policy domain receives a separate report. This boundary prevents the report from becoming an undifferentiated dump of all domains a receiver processed.
At the file level, the report identifies the reporting organization, a contact address, a unique report identifier, the reporting period, and the policy that was observed. The policy portion describes the domain, the disposition policy, any subdomain policies, alignment modes, failure-reporting setting, testing state, and the method used to discover the policy. These fields tell the report consumer what configuration the receiver was evaluating, rather than assuming that the domain owner's current DNS record is identical to what the receiver saw during the period.
The report then contains one or more records. Each record groups messages associated with a particular sending source and authentication-result combination. Its row identifies the source IP address, the number of messages in the group, and the policy disposition applied to them. The disposition is the receiver's reported action—such as no action, quarantine, or reject—not a generic statement that the message was good or bad.
The policy-evaluation portion also records the DMARC-related SPF and DKIM outcomes. These values represent whether the SPF and DKIM identifiers aligned for DMARC, not necessarily the raw result that the receiver obtained from each underlying mechanism. That distinction is easy to miss and essential to diagnosis. A row can show an aligned DKIM result that allows DMARC to pass while raw SPF authentication failed.