# DMARC XML reader > Use a DMARC XML reader to turn one aggregate report into source, count, policy, alignment, and authentication evidence. A DMARC XML reader parses one aggregate-report attachment into readable receiver evidence. Start by checking who generated the report and its date range, then read each record's source IP, message count, applied disposition, identifier alignment, and SPF or DKIM results. This tells you what a receiver observed, not whether a sender is authorized or whether every message stream is healthy. Use unknown sources and failures as leads to investigate before changing DNS or policy. ## Quick takeaways - Aggregate reports are XML feedback about grouped mail streams, not copies of individual messages. - A `record` combines a source IP, count, DMARC evaluation, identifiers, and underlying authentication results. - Read `policy_evaluated` for the DMARC outcome and `auth_results` for the underlying SPF and DKIM results. - An unfamiliar source IP or a failed result needs ownership and message-level context before it becomes a remediation decision. - A one-file reader helps with an attachment; recurring collection, correlation, and ownership work need a separate operating process. ## What a DMARC XML reader shows The current aggregate-report standard, [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html), defines a `feedback` XML document with `report_metadata`, `policy_published`, and one or more `record` elements. A report covers one DMARC Policy Domain and one observed policy configuration. It summarizes grouped receiver observations rather than presenting individual delivered messages. Within a record, `row` identifies the connecting `source_ip`, the number of messages in `count`, and the DMARC disposition and alignment outcome in `policy_evaluated`. `identifiers` supplies the visible `header_from` domain and, when present, the `envelope_from` domain. `auth_results` records the underlying DKIM and SPF results without interpreting them as DMARC alignment. [RFC 9990's record definitions](https://www.rfc-editor.org/rfc/rfc9990.html) distinguish those two evidence layers. That distinction matters. DMARC uses aligned SPF or DKIM results for the author domain, as defined by [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). A reader can therefore highlight a pass in an underlying result while the DMARC alignment result still needs attention. For a fuller explanation of the file structure and safe ingestion, use the [DMARC aggregate report format guide](/learning/dmarc-aggregate-report-format). ## When a single report is enough Use a reader for the first pass on one attachment: confirm its reporting period, find the high-volume sources, and identify rows with failed alignment or an unexpected disposition. Treat the result as a concise evidence record, not a final verdict about intent. RFC 9990 notes that reports can expose source, policy, authentication, and count data, but that scope does not establish a business owner for a source or explain an individual delivery outcome. Do not use one XML file to conclude that a new IP is malicious, that a legitimate vendor is correctly configured, or that a policy change is safe. Compare a suspected legitimate source with its owner and a message from the same path. The broader [DMARC report interpretation guide](/resources-post/how-to-understand-dmarc-reports) covers the two report types and the investigation work that follows. ## Read one report in evidence order Start at metadata and move toward the authentication detail. This avoids treating an SPF or DKIM value as the whole DMARC result. ![Decision card showing the five DMARC XML areas to inspect and the question each answers.](/images/editorial/dmarc-xml-reader/dmarc-xml-reader-evidence-card.svg "1200x900") *Source: [Open the full-size DMARC XML evidence card](/images/editorial/dmarc-xml-reader/dmarc-xml-reader-evidence-card.svg). Labels and evidence order are derived from [RFC 9990 aggregate-report XML definitions](https://www.rfc-editor.org/rfc/rfc9990.html).* ```text report_metadata -> who reported, report ID, reporting period policy_published -> policy domain and policy context observed row -> source IP, message count, disposition, DMARC alignment identifiers -> visible From domain and envelope domain, when present auth_results -> underlying DKIM and SPF results to investigate ``` ### 1. Check report metadata Confirm `org_name`, `report_id`, and the UTC `date_range` before comparing the report with another file. RFC 9990 defines the date range as the reporting period, not necessarily the first and last individual message observed. A reader should make that boundary visible so you do not compare mismatched intervals. ### 2. Read the policy context Use `policy_published` to see the policy domain and settings the receiver observed. It is context for the report, not a substitute for checking today's DNS. If the current public record is the next question, the [DMARC record checker](/tools/dmarc) is the closer action. ### 3. Prioritize rows by source and count Review `source_ip` alongside `count` and `policy_evaluated`. A large count tells you where to investigate first. A low-volume row may still be important, but neither volume nor IP address alone proves whether the source was intended to send for the domain. ### 4. Compare identifiers with alignment results Read `header_from` and `envelope_from` beside the `dkim` and `spf` values in `policy_evaluated`. This is where a reader turns a bare pass or fail into an alignment question. Do not infer sender ownership from an envelope domain alone. ### 5. Use underlying results as investigation detail Review `auth_results` after the DMARC outcome. RFC 9990 describes this section as DKIM and SPF results that are not interpreted with respect to DMARC, so it helps explain a row but does not replace the DMARC alignment values. If reports are arriving continuously, compare the operating tradeoffs in an [open-source DMARC analyzer](/learning/dmarc-report-analyzer-open-source) or a [hosted DMARC analyzer comparison](/compare/best-dmarc-report-analyzers). ## Check the policy behind the report The report tells you what a receiver observed during its reporting interval. When you need to inspect the currently published DMARC record, run the domain through Palisade's [DMARC record checker](/tools/dmarc). The public [Palisade DMARC Record Checker](https://www.palisade.email/tools/dmarc) is the cited public-record evidence source. Compare the record with the report's `policy_published` context before proposing a DNS or policy change. [Check a DMARC record](/tools/dmarc) A DNS lookup can read the public DMARC record, but it cannot parse the attachment, identify every sending service, or establish what happened to an individual delivered message. Keep sender ownership and message-level evidence in the investigation. If these reports become recurring work, [Palisade's DMARC Agent](https://www.palisade.email/features/dmarc-agent) can turn aggregate-report data into prioritized sender and authentication remediation work. A human still reviews the evidence and approves DNS or policy changes. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_reports&utm_content=dmarc-xml-reader) when the ongoing sender-review workflow is the unresolved problem. ## Sources and further reading - [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html) - [Palisade DMARC Record Checker](https://www.palisade.email/tools/dmarc) - [Palisade DMARC Agent](https://www.palisade.email/features/dmarc-agent) ## Frequently asked questions ### Is a DMARC XML report the same as a message log? No. An aggregate report groups receiver observations by shared characteristics, including source IP, count, policy evaluation, identifiers, and authentication results. It is not a message-by-message delivery log or a copy of email content. ### Can an XML reader prove an unknown IP is malicious? No. It can show that a receiver reported mail from that source for the policy domain and how the relevant group evaluated. Confirm ownership, the sending path, and message evidence before classifying the source. ### Does an SPF pass mean DMARC passed? No. SPF can pass for an identity that does not align with the visible From domain. Read the row's DMARC alignment outcome together with the underlying SPF result. ### Why does the report disposition differ from the published policy? Only a policy override or the receiver's observed context may explain the difference. Check `policy_evaluated`, any `reason` entries, and the report's policy context before assuming the current DNS record caused it. ### Can a DMARC XML reader replace ongoing monitoring? No. It makes one attachment understandable. Ongoing monitoring also needs reliable collection, duplicate handling, sender ownership, trend review, and a process for approving remediation.