DMARC Aggregate Reports (RFC 9990)

When your domain's DMARC record lists a rua= address, receivers send that address regular XML summaries of the mail that uses your domain. These aggregate reports are the main evidence for deciding when a domain is ready to move to Enforcement (see DMARC).

RFC 9990 defines the report format. It is a Standards Track specification published in May 2026, and one of the three DMARCbis documents that together obsolete RFC 7489, with RFC 9989 and RFC 9991.

What a report contains

A report is an XML document with the root element feedback and the namespace urn:ietf:params:xml:ns:dmarc-2.0. It has three parts:

Per-record elements

When a message carries many DKIM signatures, the receiver reports them in this order of priority: a strict aligned pass, then a relaxed aligned pass, then other passing signatures, then failing signatures. The specification recommends reporting at most about 100 signatures per row.

Policy-override reasons

When the disposition the receiver applied differs from the published policy, the record gives the reason:

Timing and transport

• The reporting period is typically one UTC day, starting at 00:00 UTC. Periods SHOULD NOT overlap.
• Reports are delivered by email to each rua= mailto URI. The receiver first discards any malformed URI, and must then attempt delivery to every URI that remains.
• The payload SHOULD be GZIP-compressed XML (application/gzip). Otherwise it is sent as text/xml.
• The attachment filename follows the pattern receiver!policy-domain!begin-timestamp!end-timestamp[!unique-id].extension, for example mail.receiver.example!example.com!1013662812!1013749130.xml.gz.
• The subject line follows the pattern Report Domain: <policy-domain> Submitter: <reporter-domain> Report-ID: <id>.
• The mail stream that carries the reports must itself pass DMARC with an aligned pass. Secure transport (STARTTLS or TLS) is recommended.

External report destinations

If a rua= address is outside the Organizational Domain of the policy domain, the receiver first confirms that the destination has agreed to receive the reports. It queries this record:

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

The record must contain v=DMARC1, and it may override the report URI. If the record is missing, the receiver does not send reports to the external address. This is why third-party DMARC monitoring vendors either ask you to publish this "external destination verification" record on their domain's behalf, or already publish it on their own domain.

Changes from RFC 7489

• The XML schema (XSD) is tightened and clarified, and report identifiers are structured more rigorously.
• Reporting the DKIM selector is mandatory. Reporters under 7489 often left it out. With the selector, it is far easier to identify which system produced a failing signature.
• Awareness of Public Suffix Domains is built in, and an extension mechanism is added.
• The single RFC 7489 document was split into three: 9989 (core), 9990 (aggregate) and 9991 (failure).

Working with aggregate reports

• Reports are machine-readable XML and arrive daily from every major receiver. Nobody reads them by hand at scale, so route rua= to a dedicated mailbox or to a DMARC analytics service.
• Use them to answer one question: which sources send mail as my domain, and does that mail produce an aligned pass? Rows that fail both mechanisms from IP addresses you recognize point to a legitimate source that is misconfigured; fix SPF, DKIM or alignment. Rows from IP addresses you do not recognize point to spoofing or to shadow IT.
• When every legitimate source shows aligned passes for a sustained period, the domain is ready for p=quarantine or p=reject.

Related articles

• DMARC
• DMARC standard reference
• DMARC failure reports
• Authentication-Results header, the same data for a single message