Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting
obsoletes
- rfc-7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Extracted elements (31)
External destination verification via DNS ('_report._dmarc' TXT lookup) is required to prevent abuse: without it, a bad actor could publish a DMARC record directing high-volume failed-authentication reports at an arbitrary victim address, causing a report-based DDoS.
GZIP compression of the XML report is SHOULD-level rather than MUST because compression adds compute cost, but is strongly recommended because uncompressed aggregate XML can exceed SMTP maximum message size limits at receiving Mail Receivers.
The 'discovery_method' field in policy_published distinguishes between 'psl' (Public Suffix List method from RFC 7489) and 'treewalk' (the organizational domain discovery method defined in RFC 9989), enabling report consumers to understand which policy-lookup algorithm was applied.
When a DMARC policy changes mid-reporting-period, a Mail Receiver may generate a single report mixing dispositions from both policies (with only one policy_published element) or separate reports per policy. Report Consumers must expect and tolerate mixed-policy reports during policy propagation.
A separate report MUST be generated for each DMARC Policy Domain encountered during the reporting period. Each report MUST contain data for only one DMARC Policy Domain and for one policy configuration; if multiple configurations were observed, the reporter SHOULD note only the final configuration.
If DKIM validation is attempted for any signature, those results MUST be included in the aggregate report. A report SHOULD contain no more than 100 DKIM signatures per 'row', listed in decreasing priority: strict-aligned pass, relaxed-aligned pass, other passing, then failing.
If DMARC alignment fails and the applied disposition does not match the domain's configured policy, the 'reason' element MUST be included in policy_evaluated. The 'spf' and 'dkim' fields MUST reflect the DMARC-evaluated values, not any receiver-overridden values.
If the confirming external reporting record specifies an override URI whose host differs from the originally verified destination host, the Mail Receiver MUST NOT generate a report to either the original or the override URI.
Mail streams carrying DMARC feedback data MUST conform to the DMARC mechanism, resulting in an aligned 'pass', to minimize the risk of Report Consumers processing fraudulent reports.
PSD DMARC feedback MUST be limited to aggregate reports. Failure reports carry more detailed information and present a greater privacy risk when directed to Public Suffix Operators covering multiple organizations.
The aggregate data MUST be an XML file that SHOULD be GZIP-compressed. The media type MUST be 'application/gzip' if compressed or 'text/xml' otherwise. The attachment filename MUST follow the ABNF: receiver '!' policy-domain '!' begin-timestamp '!' end-timestamp ['!' unique-id] '.' extension, where extension is 'xml' or 'xml.gz'.
The first-level elements of the aggregate feedback report (version, report_metadata, policy_published, extension, record) MUST appear in the listed order, and there MUST be at least one 'record' element.
The Mail Receiver MUST evaluate the provided reporting URIs in the order given. An attempt MUST be made to deliver an aggregate report to every remaining valid URI, up to the Receiver's limits on supported URIs; malformed URIs SHOULD be ignored.
The Report-ID MUST be unique among reports to the same domain. If a report must be re-sent, the system MUST use the same filename as the original report, allowing the receiver to detect and handle the duplicate.
The RFC5322.Subject field for individual report submissions MUST conform to the specified ABNF: '%s"Report"' FWS '%s"Domain:"' FWS domain-name FWS '%s"Submitter:"' FWS domain-name FWS ['%s"Report-ID:"' FWS ridtxt].
When the Organizational Domain of the reporting URI host differs from the policy domain, verification MUST be performed by querying DNS for a TXT record at '<policy-domain>._report._dmarc.<destination-host>'. The record must contain 'v=DMARC1' as the first tag; unauthorized external reporting URIs MUST be ignored.
Where the 'rua' URI does not specify otherwise, a Mail Receiver SHOULD employ a secure transport mechanism—specifically delivery over a channel employing TLS (SMTP+STARTTLS).
Aggregate feedback reports contain only aggregated domain-level authentication data; they do not include individual mail addresses, individual user IP addresses, or message content. Only sending mail server IP addresses and authentication outcomes are reported.
For multi-organization PSDs not requiring DMARC (e.g., '.com'), all DMARC feedback for non-DMARC Organizational Domains will be redirected to the PSO if the PSO publishes a DMARC record with a 'rua' tag, creating significant risk of traffic metadata leakage to the PSO.
Each 'record' element contains, in order: 'row' (source_ip, count, policy_evaluated), 'identifiers' (header_from required; envelope_from and envelope_to optional), 'auth_results' (zero or more dkim, zero or one spf), followed by optional namespaced extension elements.
Policy override types for the 'reason' element are: 'local_policy' (receiver's local policy exempted the message), 'mailing_list' (message routed through mailing list), 'policy_test_mode' (exempted by 't' tag), 'trusted_forwarder' (known trusted forwarder), and 'other' (anything else).
The 'policy_evaluated' element records DMARC outcome: 'disposition' (none/pass/quarantine/reject), 'dkim' and 'spf' alignment results (pass/fail), and zero or more 'reason' elements for policy overrides. Elements must appear in this order.
The 'policy_published' element reports the observed DMARC policy: domain (required), p/sp/np assessment policies (none/quarantine/reject), adkim/aspf alignment modes (r=relaxed/s=strict), fo failure reporting options, testing flag (y/n), and discovery_method (psl/treewalk).
The XML aggregate feedback report uses the root element 'feedback' with namespace 'urn:ietf:params:xml:ns:dmarc-2.0'. Top-level child elements in order: version (optional, value '1.0'), report_metadata (required), policy_published (required), extension (optional), and one or more record elements (required).
IANA registered the URI 'urn:ietf:params:xml:schema:dmarc-2.0' in the 'schema' registry within the 'IETF XML Registry' group as the DMARC aggregate reporting XML schema (defined in Appendix A).
Aggregate reports are processed automatically, making processors vulnerable to malformed input. The archive decompressor and XML parser are specifically at risk of resource exhaustion from zip bombs or XML entity expansion bombs.
Extensions could enable report generators to disclose message placement decisions (Inbox vs. Spam). This is strongly discouraged because it reveals filtering methodology to potentially malicious report recipients.
Report data may be forged. An attacker can submit large volumes of false reports to interfere with Domain Owner policy decisions, influence platform architecture, or overwhelm Report Receiver capacity to process legitimate reports.
Report-ID format (ridtxt) is defined as: ridfmt = dot-atom-text ['@' dot-atom-text]; ridtxt = ('<' ridfmt '>') / ridfmt. The primary goal is uniqueness; combining receiving domain, sending domain, and timestamp is recommended.
The aggregate report attachment filename uses '!' as delimiter: receiver '!' policy-domain '!' begin-timestamp '!' end-timestamp ['!' unique-id] '.' extension. Timestamps are Unix epoch seconds; extension is 'xml' or 'xml.gz'. Example: 'mail.receiver.example!example.com!1013662812!1013749130.xml.gz'.
The 'date_range' element contains 'begin' and 'end' child elements, each representing seconds since the Unix epoch (00:00:00 UTC January 1, 1970), defining the inclusive UTC reporting period. Reporting periods SHOULD NOT overlap.