DMARC Report Analyzer

Drop in the aggregate reports sent to your rua address (.xml, .gz or .zip) and see every sending IP, how many messages it sent, and whether DKIM and SPF aligned. The file never leaves your browser.

The file never leaves your browser. Unzipping and XML parsing run in this page's JavaScript, and nothing is uploaded or stored. You can disconnect from the internet after the page loads and it still works.

No report to hand? from the walkthrough below (example.com, made-up data).

How to read a DMARC aggregate report

An aggregate report is one XML file per receiver, per day, per domain. RFC 9990 defines the format. It has three parts: who reported, the policy they found, and one record for each sending IP and result combination.

The sample below is made up. It uses example.com and documentation IP ranges, and it is the same file the “Load the sample report” link above feeds into the analyzer.

  1. <report_metadata>
  <org_name>Sample Reporter</org_name>
  <email>[email protected]</email>
  <report_id>example.com-20261029-7f3a</report_id>
  <date_range>
    <begin>1793232000</begin>
    <end>1793318399</end>
  </date_range>
</report_metadata>

    Part 1

    Who wrote the report, and for which day

    org_name is the mailbox provider that received your mail, not a sender. The two dates are Unix seconds in UTC: 1793232000 is 29 October 2026, 00:00 UTC, so this file covers one day. Keep report_id; a provider that resends a file uses the same ID, and the analyzer drops the copy.

  2. <policy_published>
  <domain>example.com</domain>
  <discovery_method>treewalk</discovery_method>
  <p>none</p>
  <sp>none</sp>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

    Part 2

    The record the receiver saw

    This is your _dmarc record as the reporter read it. If p here is not what you think you publish, the receiver cached an older record or found a different one. discovery_method and testing come from RFC 9990 (May 2026). Older reports leave them out and may still show pct.

  3. <row>
  <source_ip>198.51.100.25</source_ip>
  <count>268</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>

    Part 3

    One sending IP, one set of results

    268 messages came from 198.51.100.25. The dkim and spf values here are the aligned results DMARC used. One aligned pass is enough, so these messages passed DMARC. disposition is what the receiver did: none because the policy is none.

  4. <identifiers>
  <envelope_from>bounces.newsletter-esp.example</envelope_from>
  <header_from>example.com</header_from>
</identifiers>
<auth_results>
  <dkim>
    <domain>example.com</domain>
    <result>pass</result>
    <selector>esp1</selector>
  </dkim>
  <spf>
    <domain>bounces.newsletter-esp.example</domain>
    <result>pass</result>
  </spf>
</auth_results>

    Part 4

    Raw results, before alignment

    SPF passed, but for the newsletter service's bounce domain. That domain is not example.com, so the aligned SPF result above is fail. This is the usual answer to “SPF says pass, why does DMARC say fail?” The DKIM signature uses d=example.com with selector esp1, which is what carries this sender.

The sample, summarised per source

The full sample has four records. Reading them side by side is the whole job: 720 messages, 680 of them passed DMARC, and the 40 failures split into one mailing list and one sender nobody recognises.

Per-source summary of the sample report
Source IPMessagesDKIM alignedSPF alignedDMARCWhat it probably is
192.0.2.10412passpasspassYour own mail server. Both checks align. Nothing to do.
198.51.100.25268passfailpassA newsletter service that signs with your domain but bounces to its own. DKIM carries it; adding the service to your SPF would not change the result.
203.0.113.7731failfailfailA mailing list. The envelope is the list's domain and your signature broke when the list edited the message. Do not add the list to SPF; this is the mail p=reject would cost you.
203.0.113.2009nonefailfailUnknown IP, no signature, SPF fail for example.com itself. Most likely spoofing. Quarantine or reject stops it.

Real reports name no services, only IPs. The “Look up host names” button in the analyzer adds reverse DNS, which often shows the provider behind an address.

Who sends rua reports

  • Only receivers that choose to. RFC 9989 says receivers SHOULD send aggregate reports at least once every 24 hours, and lists why some opt out: resource limits, local policy and user privacy.
  • Nobody, if your record has no rua tag. RFC 9989 forbids receivers from sending aggregate reports without one.
  • Microsoft Outlook.com: “We send RUA to the addresses specified in your DMARC record,” per its April 2025 post on high-volume senders.
  • Google recommends always setting rua and says reports usually arrive once a day by email. Gmail does not support ruf.
  • Yahoo's sender rules strongly recommend a working rua address for bulk senders.

Sending reports to a mailbox on another domain needs an authorisation record on that domain, for example example.com._report._dmarc.reports.example.net with the value v=DMARC1;. Without it, a receiver following RFC 9990 cannot confirm the arrangement, so expect no reports there. Failure (ruf) reports are rarer still; the FAQ explains why.

Sources: RFC 9990, RFC 9989 section 5.3.8, Microsoft, Google: set up DMARC, Google: about DMARC reports, Yahoo. Checked 30 October 2026.

Frequently Asked Questions

Next: check the record itself with the DMARC checker, or build a new one with the DMARC record generator.

Stop reading XML every morning

DMARC+ receives your aggregate reports, maps each sending source and alerts you by SMS or email, from p=none through to p=reject.

Request a 14-Day Trial