# What format do DMARC aggregate reports use? > DMARC aggregate reports use the RFC 9990 XML schema and arrive as plain XML or GZIP. Learn the fields, file types, deduplication, and validation steps. 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](/learning/what-is-a-rua), 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](/learning/what-is-spf) authenticates an SMTP identity, [DKIM](/learning/what-is-dkim) verifies a signing domain, and [DMARC](/learning/what-is-dmarc) evaluates alignment with the visible From domain. ## What are the requirements? [RFC 9990](https://www.rfc-editor.org/info/rfc9990/) 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`. ```text 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](https://www.rfc-editor.org/info/rfc9989/) 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](https://www.rfc-editor.org/info/rfc9991/) 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](https://docs.palisade.email/guides/fixing-authentication-issues/) 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](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_aggregate_report_format&utm_content=dmarc_aggregate_report_format). ## Frequently asked questions ### Are DMARC aggregate reports CSV files? No. The standard interchange format is XML. A reporting platform can export parsed data as CSV for analysis, but that export is not the original aggregate report. ### Can a DMARC aggregate report arrive as a ZIP file? No. ZIP is not the compression format defined by RFC 9990. The standard options are plain `.xml` or GZIP-compressed `.xml.gz`. A local tool may create another archive type for its own export workflow. ### Do aggregate reports contain message content? No. They summarize source, policy, authentication, alignment, and count data. They are not copies of normal message bodies or individual mailboxes. ### Can one report contain multiple policy configurations? No. One report contains one observed policy configuration for one DMARC Policy Domain. A reporting organization can send separate reports when it observed different configurations during the interval. ### Does `count` represent unique recipients? No. It is the message total grouped under that record's observed characteristics, not a count of unique people.