What format do DMARC aggregate reports use?

DMARC aggregate reports use the XML schema defined by RFC 9990, not RFC 9991. A receiver sends a plain .xml file or a GZIP-compressed .xml.gz attachment to a destination authorized through the domain's rua tag. Each report covers one DMARC Policy Domain and one observed policy configuration. It contains metadata, the published policy, and grouped records with source IP, message count, disposition, alignment results, and underlying SPF and DKIM results. RFC 9991 covers failure reports.

Quick takeaways

• The standard transport format is plain XML or GZIP-compressed XML, not ZIP.
• Each report contains data for one DMARC Policy Domain and one observed policy configuration.
• A record groups messages with shared observed characteristics instead of listing individual messages.
• policy_evaluated describes DMARC evaluation, while auth_results contains underlying SPF and DKIM results.
• Stable report identity and date-range handling prevent duplicate counts.

Who is affected?

Domain owners receiving reports at a RUA destination, DMARC analytics providers, MSPs, and security teams that operate ingestion pipelines all depend on this format.

Even if a dashboard reads the files for you, the format still matters. It determines what the dashboard can prove, and normalization errors can distort totals. Aggregate reports summarize receiver observations. They do not contain normal message bodies, but source IP and domain relationships still deserve appropriate access and retention controls.

The fields also sit at different protocol layers. SPF authenticates an SMTP identity, DKIM verifies a signing domain, and DMARC evaluates alignment with the visible From domain.

What are the requirements?

RFC 9990 defines feedback as the XML root. Its first-level elements appear in a defined order: optional version, required report_metadata, required policy_published, optional extension, and one or more record elements. If version appears, its value must be 1.0.

feedback
  version
  report_metadata
  policy_published
  extension
  record
    row
    identifiers
    auth_results

report_metadata identifies the reporting organization, contact address, report ID, and date range. The begin and end values are seconds since the Unix epoch in UTC. The report ID supports duplicate detection, but reliable ingestion also keeps reporter and interval context.

policy_published records the policy configuration the receiver observed. It includes the policy domain and DMARC settings such as p, sp, np, adkim, aspf, fo, testing, and discovery_method. A mismatch with current DNS is evidence about the receiver's observed policy, not automatic proof that the report is malformed.

Each record contains a row, identifiers, and authentication results. The row includes source_ip, count, and policy_evaluated. The identifiers connect the observation to domains such as header_from and envelope_from. The auth_results section records underlying DKIM and SPF checks without interpreting them as DMARC alignment.

That separation matters because the two sections answer different questions. A DKIM signature can verify while its signing domain fails alignment. An SPF result can pass for an envelope domain that does not align with the visible From domain. Read the row's DMARC evaluation and the underlying results together under the current RFC 9989 evaluation model.

For email transport, the attachment must be XML. A plain file uses text/xml and an .xml extension. A compressed file uses GZIP, application/gzip, and an .xml.gz extension. ZIP is not the transport compression defined by RFC 9990.

When does the requirement take effect?

RFC 9990 was published in May 2026 as the current standalone aggregate-report specification. Core DMARC evaluation is in RFC 9989, while RFC 9991 covers failure reporting.

Deployment timing is controlled by each reporting organization, so an ingestion service should identify the received format instead of assuming every sender changes on the same day. Keep any older parser path explicit and measured. The date range inside report_metadata remains the authority for the period represented by a particular file.

How do I implement the requirement?

1. Receive the attachment safely

Accept expected report-mailbox traffic and support .xml and .xml.gz. Check the declared media type, set message and decompression limits, and store the original attachment for audit. Do not treat a ZIP archive as the RFC 9990 transport format.

2. Validate the XML structure

Parse XML with external entity expansion disabled and validate the current schema. Require the root and mandatory sections, reject a document that does not match the expected format, and preserve unknown namespaced extension fields for forward compatibility.

3. Deduplicate before adding counts

Build report identity from the reporting organization, report ID, policy domain, date range, and filename context. RFC 9990 requires the same filename for a resend. Together, those fields reduce accidental double-counting when a message or attachment is delivered again.

4. Normalize records into sender evidence

Store source_ip, count, disposition, alignment results, header_from, envelope_from, DKIM domains and selectors, and the SPF domain. Map that evidence to a known sender and owner without rewriting the original report.

5. Alert on changes that need a decision

Prioritize new sources, sustained alignment failures, unexpected policy views, and meaningful disposition changes. Isolated rows still need context from volume, sender ownership, and a delivered message before they become a configuration change.

How do I validate compliance?

Inspect the file first. Confirm that the media type, extension, and encoding agree; the XML matches the expected schema; at least one record exists; and the report covers one policy domain and one policy configuration.

Then verify the metadata. Check that the date range is coherent, the report identity is stable, and a resend does not increase totals. Compare summed counts with prior periods and known sender activity, but do not treat a missing receiver report as zero traffic.

For a sampled source, compare policy_evaluated, identifiers, and auth_results with a delivered message's Authentication-Results. The report describes grouped receiver observations, while the delivered header explains one concrete evaluation.

Make SPF, DKIM, and DMARC easier to manage

Palisade's DMARC Agent turns report data into a prioritized list of sender, SPF, DKIM, and DMARC issues. Your team can see what to fix next and follow a guided path toward stronger authentication and DMARC enforcement. Stronger authentication helps protect your domains and supports better email deliverability.

start a Palisade account.