InboxRatio
Check your domain

How to read DMARC reports: a field-by-field walkthrough of the XML

Your first DMARC report arrives looking like something went wrong with the encoding: an attachment named like receiver.example!example.com!1736035200!1736121599.xml.gz, which unpacks to a wall of XML. Nothing went wrong. That file is a receiving provider telling you, source by source, every server that sent mail claiming your domain during one day, and whether each source authenticated. This guide reads the file with you, element by element, then decodes the pass/fail combinations that make up every real-world report. If you would rather not hand-read XML at all, our free DMARC report analyzer parses an uploaded report into the same human-readable verdicts this guide teaches; the walkthrough below is what makes its output, or any tool's, meaningful.

This is the hands-on layer of a three-part topic. What reports are and how to start receiving them is covered in DMARC reports; the compact definition lives in the glossary under DMARC aggregate reports.

Where reports come from, and the filename

Publish a DMARC record with a rua= address and receiving providers that send DMARC reports (Google, Microsoft and Yahoo among them) will mail that address aggregate reports, usually one per reporter per day, as compressed XML. RFC 9990, the aggregate-reporting standard published in May 2026 alongside the RFC 9989 core that replaced RFC 7489, specifies GZIP compression, though some reporters still send .zip files. The filename encodes the reporter, your domain, and the reporting window as Unix timestamps. Volume scales with how many providers see your mail, so a real domain quickly accumulates more files than anyone hand-reads daily; the skill matters because you will still hand-read individual reports when something looks wrong.

The three sections of the XML

Every report has the same skeleton. <report_metadata> names the reporter and repeats the date range. <policy_published> echoes the DMARC record the reporter saw when evaluating: your domain, the p= policy, any sp= subdomain policy and the alignment modes. Reporters following RFC 7489 add the legacy pct= value; reporters following RFC 9990 drop it and add np, testing and discovery_method instead, so expect both shapes in your mailbox during the transition. Check this section first; if it does not match the record you believe you published, you are debugging DNS, not mail, and the DMARC checker will show you what the world currently resolves.

Then comes the substance: one <record> element per source-and-result combination. Each record contains three nested blocks, and reading a report is reading these three blocks over and over.

Reading one record

<row> holds the observable facts: <source_ip>, the server that delivered the mail; <count>, how many messages this row summarizes; and <policy_evaluated>, the reporter's verdict, with a <disposition> of none, quarantine or reject (RFC 9990 reporters may also use pass) plus a DMARC-level <dkim> and <spf> result of pass or fail. These last two are the aligned results, the ones DMARC actually scores.

<identifiers> gives <header_from>, the domain in the From header recipients saw, which is the domain everything must align to; some reporters also include <envelope_from>.

<auth_results> shows the raw mechanics: each SPF evaluation with the domain it checked and its result, and each DKIM signature with the signing domain and selector. Raw and aligned results can differ, and that difference is the single most useful diagnostic in the format: raw SPF can pass for a sending service's own domain while aligned SPF fails because that domain is not yours, the exact situation unpacked in SPF alignment and its DKIM counterpart.

The four combinations that matter

Both aligned results pass: healthy mail from a properly configured source. Most rows should look like this.

DKIM passes, SPF fails: usually forwarding. A forwarder re-delivers from its own IP, breaking SPF, while the DKIM signature survives the trip. DMARC needs only one aligned pass, so the mail still passes; no action required, which is why this combination is reassuring rather than alarming.

SPF passes, DKIM fails or is absent: a source sending with a correct envelope but unsigned or missigned mail, commonly a service whose DKIM setup was never finished. Fix the signing; mail surviving on SPF alone breaks under forwarding.

Both fail: two possibilities with opposite meanings. A legitimate service you forgot to authenticate, which the source_ip will identify once you resolve it to its operator, or spoofing, someone else using your name. The volume, geography and persistence of the source usually settle which; the remediation for the first case is finishing that service's records, and for the second, an enforcement policy, per DMARC fail.

From single report to working process

One file is a snapshot; the value is the aggregate. A workable weekly loop: collect the week's reports through the DMARC report analyzer, group rows by source, and identify every sender, your ESP, your SMTP relay, the office suite, the billing system. For each legitimate source with failing alignment, finish its SPF include or DKIM keys and verify with the email authentication checker. What remains unexplained after that is your spoofing baseline. This loop is the evidence engine behind moving your policy from monitoring to enforcement, a migration with its own staged guide in DMARC none to reject, and it is how a new sending subdomain gets confirmed clean before ramping.

One scope note: aggregate reports contain counts and IPs, never message content. The per-message diagnostic variant, rarely sent by major providers, is the forensic report, and treating the two as interchangeable is a common early confusion.

Expect some noise, too. Reporters differ in quality: a few send malformed XML, some batch multiple days, and rows with a count of one from residential IPs are frequently just forwarded single messages rather than an attack. Weight your attention by count and persistence. A source sending thousands of aligned messages that suddenly starts failing is an incident; a stranger's mail server relaying one failing message a week is background radiation every domain has.

Related guides

About this guide

Written by InboxRatio Editorial. The report format, element names and evaluation semantics follow RFC 9990 (May 2026) and the RFC 7489 schema that many reporters still emit; reporting behavior attributed to specific providers follows their published sender documentation. The interpretation patterns for pass/fail combinations are standard DMARC operational practice and labeled as judgment where they go beyond the specification. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on specification and provider documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

8 October 2026. RFC references and provider reporting behavior reviewed quarterly.

Frequently asked questions

How do I open a DMARC report? Decompress the attachment (they arrive as .gz or .zip) and open the XML in any editor, or upload the file as-is to a parser like our DMARC report analyzer, which renders the rows as readable verdicts.

What do the dkim and spf fields in policy_evaluated mean? Those are the aligned results: whether each mechanism passed for a domain matching the From-header domain. They can differ from the raw results in auth_results, and it is the aligned pair that decides the DMARC outcome.

Why do some rows fail SPF but still pass DMARC? DMARC requires one aligned pass, not two. Forwarded mail typically breaks SPF because it arrives from the forwarder's IP, while the DKIM signature remains valid, so the message passes on DKIM alone. This is normal and needs no fix.

How do I identify who a source IP belongs to? Reverse-resolve it and check the operator's published sending ranges; most ESPs document theirs. High-count sources are usually your own services. Persistent low-count sources that match no vendor you use are your spoofing picture.

What is the difference between aggregate and forensic DMARC reports? Aggregate (rua) reports are daily statistical summaries: sources, counts, results, no content. Forensic (ruf) reports, named failure reports in the current standard, are per-message failure samples, sent rarely by major providers for privacy reasons. Day-to-day monitoring runs on aggregate reports.

How long should I collect reports before acting? Long enough to see your full sending calendar; a few weeks captures weekly campaigns and most monthly jobs like invoicing runs. Then fix every legitimate source that fails alignment and use the cleaned-up picture as the basis for policy enforcement.

The XML stops being hostile the third time you read one. Learn the three blocks, memorize the four combinations, and let the DMARC report analyzer do the volume work while you make the calls only you can make.