# DMARC Aggregate Reports (RFC 9990)

> The XML aggregate feedback format — report structure, transport, filename and subject conventions, external-destination verification, and policy-override reasons.

Source: emailmarketing.net — https://emailmarketing.net/learn/authentication/dmarc-aggregate-reports

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](https://emailmarketing.net/learn/authentication/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](https://emailmarketing.net/learn/authentication/dmarc-standard) and [RFC 9991](https://emailmarketing.net/learn/authentication/dmarc-failure-reports).

## 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:

| Section | Contents |
|---|---|
| **Report metadata** | The reporting organization's name, a contact email address, a unique report ID, and the start and end of the reporting period, in Unix seconds. |
| **Policy published** | The DMARC record the receiver found: the domain, `p`, `sp` and `np`, `adkim` and `aspf`, and how the record was discovered (exact match or Tree Walk). |
| **Records** (one or more) | The results for each source IP address: the row, the identifiers, and the raw authentication results described below. |

### Per-record elements

| Element | Fields |
|---|---|
| `row` | The source IP address (IPv4 or IPv6); the message **count** for that combination of IP address and disposition; the **disposition** applied (`none`, `pass`, `quarantine`, `reject`); and the DKIM and SPF **alignment** results, pass or fail, as DMARC evaluates them. |
| `identifiers` | `header_from`, the RFC5322.From domain (required); `envelope_from`, the RFC5321.MailFrom domain (optional); and the `envelope_to` domain (optional). |
| `auth_results` | The raw result for each mechanism. DKIM entries give the domain, the **selector** (reporting it is mandatory in 9990), the result, and an optional note for people to read. SPF entries give the domain, the scope (`mfrom`) and the result. |

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:

| Reason | Meaning |
|---|---|
| `local_policy` | A local exemption at the receiver, often based on ARC (see [ARC](https://emailmarketing.net/learn/authentication/arc)) |
| `mailing_list` | The receiver's heuristics detected a mailing list |
| `policy_test_mode` | The record's `t=y` test mode was in effect |
| `trusted_forwarder` | An exemption for a known forwarder |
| `other` | Any other reason, with an optional comment |

## 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](https://emailmarketing.net/learn/authentication/spf), [DKIM](https://emailmarketing.net/learn/authentication/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](https://emailmarketing.net/learn/authentication/dmarc)
- [DMARC standard reference](https://emailmarketing.net/learn/authentication/dmarc-standard)
- [DMARC failure reports](https://emailmarketing.net/learn/authentication/dmarc-failure-reports)
- [Authentication-Results header](https://emailmarketing.net/learn/authentication/authentication-results-header), the same data for a single message