DMARC Aggregate Reports (RFC 9990)

RFC 9990 (Standards Track, May 2026; part of the DMARCbis set with RFC 9989 and RFC 9991, together obsoleting RFC 7489) defines the aggregate feedback report: the XML digest receivers send to the rua= addresses in a domain's DMARC record. Aggregate reports are the primary data source for deciding when a domain is ready to move to Enforcement — see DMARC.

What a report contains

XML document, root element feedback, namespace urn:ietf:params:xml:ns:dmarc-2.0:

Section	Contents
Report metadata	Reporting org name, contact email, unique report ID, reporting period begin/end (Unix seconds).
Policy published	The DMARC record the receiver discovered: domain, p/sp/np, adkim/aspf, discovery method (exact match vs. Tree Walk).
Records (one or more)	Per source-IP results: the row, identifiers, and raw auth results below.

Per-record elements

Element	Fields
row	Source IP (v4 or v6); message count for that IP/disposition combination; disposition applied (none, pass, quarantine, reject); DKIM and SPF alignment results (pass/fail from DMARC's perspective).
identifiers	header_from (RFC5322.From domain — required); envelope_from (RFC5321.MailFrom domain — optional); envelope_to domain (optional).
auth_results	Raw results per mechanism: DKIM entries with domain, selector (mandatory to report in 9990), result, optional human-readable note; SPF entries with domain, scope (mfrom), result.

For messages with many DKIM signatures, reporting priority is: strict aligned pass > relaxed aligned pass > other passing signatures > failing signatures; at most ~100 signatures per row recommended.

Policy-override reasons

When the applied disposition differs from the published policy, the record says why:

Reason	Meaning
local_policy	Receiver's local exemption (often ARC-based — see ARC)
mailing_list	List-detection heuristics
policy_test_mode	The record's t=y test mode was in effect
trusted_forwarder	Known-forwarder exemption
other	Anything else, with optional comment

Timing and transport

• Reporting period: typically one UTC day starting 00:00 UTC; periods SHOULD NOT overlap.
• Delivered by email to each rua= mailto URI (after discarding malformed ones — a delivery attempt must be made to every remaining URI).
• Payload SHOULD be GZIP-compressed XML (application/gzip); otherwise text/xml.
• Attachment filename: receiver!policy-domain!begin-timestamp!end-timestamp[!unique-id].extension, e.g. mail.receiver.example!example.com!1013662812!1013749130.xml.gz.
• Subject line: Report Domain: <policy-domain> Submitter: <reporter-domain> Report-ID: <id>.
• The mail stream carrying reports must itself pass DMARC with an aligned pass; secure transport (STARTTLS/TLS) recommended.

External report destinations

If a rua= address is outside the policy domain's Organizational Domain, the receiver verifies consent by querying:

<policy-domain>._report._dmarc.<destination-host>   (TXT)

The record must contain v=DMARC1 (and may override the report URI). Without it, reports are not sent to the external address — the reason third-party DMARC monitoring vendors have you publish this "external destination verification" record on their domain's behalf, or it exists already on theirs.

Changes from RFC 7489

• XSD tightened and clarified; report identifiers structured more rigorously.
• DKIM selector reporting is mandatory (7489 reporters often omitted it), which makes it far easier to identify which system produced a failing signature.
• Public Suffix Domain awareness integrated; extension mechanism added.
• The monolithic RFC 7489 was split into 9989 (core) / 9990 (aggregate) / 9991 (failure).

Working with aggregate reports

• They are machine-readable XML, arriving daily from every major receiver — route rua= to a dedicated mailbox or a DMARC analytics service; nobody reads these by hand at scale.
• Read them to answer: which sources send as my domain, and do they produce an aligned pass? Rows failing both mechanisms from IPs you recognize = a misconfigured legitimate source (fix SPF/DKIM or alignment). Rows from unknown IPs = spoofing or shadow IT.
• When every legitimate source shows aligned passes for a sustained period, the domain is ready for p=quarantine/p=reject.

Related

• DMARC · DMARC standard reference · DMARC failure reports
• Authentication-Results header — the per-message view of the same data