Free tool

Free DMARC report analyzer, read aggregate XML in your browser.

Name: DMARC Report Analyzer
Author: DMARCTrust

Drop in one aggregate report and this DMARC analyzer turns the raw XML into a readable summary: source IPs, SPF and DKIM results, alignment, and the action each receiver took. It runs the same open-source parser we use to read real reports for our own customers. Your report never leaves your browser.

Drop your DMARC report here

or click to select a file

Analyze Report

Supports .xml, .xml.gz, and .zip files

Ready to analyze

Report Analysis

Total Messages

DMARC Pass Rate

SPF

Pass Fail

DKIM

Pass Fail

Message Disposition

None (delivered)

Quarantine

Reject

Report Information

Report From
Report Period
Reported Domain

Your DMARC Policy

Policy (p)
Subdomain Policy (sp)
Non-existent Subdomain Policy (np)
Percentage (pct)
Test Mode (t)
Discovery Method
DKIM Alignment
SPF Alignment

Top Sending Sources

Source IP	Messages	Passed	Failed	Auth Methods

What is a DMARC aggregate report?

A DMARC aggregate report, also called a rua report, is an XML file that an email receiver such as Gmail, Microsoft, or Yahoo sends you about once a day for each of your domains. It summarizes the messages that claimed to come from your domain that day: which IP addresses sent them, whether SPF and DKIM passed and aligned, and what the receiver did with mail that failed. The format started in RFC 7489 Appendix C. RFC 9989 (DMARCbis) now obsoletes RFC 7489 as the core standard, and RFC 9990 specifies the aggregate report schema: pct left the record, and the np, testing, and discovery_method elements were added.

There are two kinds of DMARC report, and this analyzer reads one of them. Aggregate reports (rua) are the daily statistical XML summaries described above. They carry counts, not message content. Failure reports (ruf), formerly called forensic reports and now specified in RFC 9991, are a separate per-message format sent the moment a message fails. This tool parses aggregate reports, which is what nearly every receiver sends and what you need to see how your domain is being used.

DMARCbis, published in May 2026, reworked this stack across RFC 9989, 9990, and 9991. Our DMARCbis explainer walks through what changed.

How to read a DMARC report, field by field

Every aggregate report is one <feedback> element with three parts: who sent the report, the policy you published, and one record per group of messages that shared the same result. Here is what each field means, in the order the analyzer above reads them.

<report_metadata>, who sent this report and when

org_name: The receiver that generated the report, for example google.com.
email: The reporting mailbox at that receiver.
report_id: A unique id for this report. Use it to deduplicate if you store reports yourself.
date_range / begin, end: The 24-hour window the report covers, written as Unix epoch seconds. The analyzer converts these to readable dates for you.

<policy_published>, the DMARC policy you had live that day

domain: The domain the policy applies to.
p: Your main policy: none, quarantine, or reject. This is the assessment you published for mail that fails DMARC.
sp: The policy for subdomains, if you set one.
np: The policy for non-existent subdomains. RFC 9989 (DMARCbis) added the np tag to the record, and RFC 9990 carries its value as a report element. The analyzer shows it only when present.
pct: The percentage of failing mail the policy applies to. RFC 9989 removed pct from the DMARC record in favor of the t test-mode flag, so the analyzer shows pct only when a legacy report still carries it, and never invents a default.
adkim / aspf: DKIM and SPF alignment mode: r is relaxed (the organizational domains must match), s is strict (the full domains must match).
testing: The report element that carries the value of the RFC 9989 t (test mode) flag. When yes, the receiver evaluates DMARC but does not enforce it, so you can watch before turning policy on. Reports keep flowing while you test.
discovery_method: An RFC 9990 report field that names how the receiver found your policy: psl (Public Suffix List) or treewalk (the new DNS Tree Walk).

<record>, one row per group of messages with the same result

Each record has four child blocks. The first two carry the verdict; the last two carry the evidence.

row / source_ip, count: The IP address that sent the mail and how many messages it sent in this group. count is the number you multiply everything else by.
policy_evaluated / disposition: What the receiver actually did: none means delivered, quarantine means routed to spam, reject means blocked.
policy_evaluated / dkim, spf: The DMARC verdict the receiver already computed for each mechanism, pass or fail, after alignment. This is the result that decides whether DMARC passed.
identifiers / header_from: The domain in the visible From header, the address DMARC protects.
auth_results / dkim, spf: The raw SPF and DKIM check (domain, selector, result) before alignment is applied. This is where you diagnose why a verdict came out the way it did. Under RFC 9990 the DKIM selector is required whenever a DKIM signature is reported.

For the meaning of each tag in the policy you publish (the p, sp, adkim, aspf values above), see our DMARC record tags guide, or build a record with the DMARC record generator.

Worked example: a real report, decoded

Here is a healthy report read line by line. It is a synthetic sample (the IPs and report id are not real), but it is the exact shape Google sends. Drop it into the analyzer above and you get the summary below.

A trimmed sample report (one of two records shown):

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>14987236590123456789</report_id>
    <date_range><begin>1717200000</begin><end>1717286400</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>reject</p><sp>reject</sp><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.41</source_ip>
      <count>128</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim><spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
  </record>
</feedback>

Reading it in plain English

google.com sent this report for example.com, covering one day.
The published policy is p=reject with relaxed alignment (adkim=r, aspf=r).
Record one: 198.51.100.41 sent 128 messages. DKIM and SPF both passed and aligned, so DMARC passed.
Record two (not shown above): 198.51.100.12 sent 47 messages, also all passing.
Total: 128 + 47 = 175 messages, a 100% DMARC pass rate.

Notice every disposition is none even though the policy is p=reject. That is correct, not a contradiction. p=reject is the assessment a receiver weighs for mail that fails DMARC. Every message here passed, so the receiver had no reason to act and delivered it normally.

A spoofing attempt looks different. You would see an unfamiliar source_ip with dkim=fail and spf=fail in policy_evaluated, and because the policy is reject, its disposition would typically read reject. That row is mail someone sent as your domain that the receiver blocked. Those are the rows worth watching.

policy_evaluated vs auth_results, the part most tools get wrong

A report carries the SPF and DKIM result twice, and the two are not the same thing. Inside auth_results you get the raw check: did SPF authorize the sending IP, did the DKIM signature verify. Inside policy_evaluated you get the DMARC verdict: the receiver took that raw result and also checked whether the authenticated domain aligns with the domain in the visible From header. DMARC passes when SPF or DKIM passes and aligns with that From domain.

This is why raw SPF can read pass while DMARC still fails. A message sent through a forwarder or an unconfigured bulk-mail provider can pass plain SPF on the provider's own domain, yet fail DMARC because that domain does not align with yours. The aligned verdict in policy_evaluated is the one that decides handling, so it is the number this analyzer counts.

We are precise about what the tool does: it reports the aligned verdict the receiver already computed in policy_evaluated. It does not re-run alignment on your raw results. That matches RFC 7489 Section 7.2 (carried into RFC 9989), where the receiver evaluates identifier alignment, not the report reader.

Why use a DMARC report analyzer?

Verify your email sources

See which IP addresses send mail in the name of your domain, and whether they are authorized to.

Monitor SPF and DKIM

Track pass rates so your real mail stays authenticated as you move toward p=reject.

Detect spoofing

Spot unfamiliar senders trying to send mail as your domain, and confirm your policy is doing its job.

100% in your browser, nothing uploaded

Your report never leaves your machine. The analyzer reads the file with your browser's built-in DOMParser and decompresses .gz and .zip archives in memory with fflate. There is no upload, no server round-trip, and no logging. The parser makes zero network calls, which you can check yourself: it is open source under the MIT license. That is the difference between this tool and analyzers that ask you to upload a report to their servers first.

Want automated DMARC monitoring?

Reading one report by hand is fine. New reports arrive every day from every receiver, and that does not scale. DMARCTrust collects, parses, and tracks them for you automatically, using this same parser server-side.

Start free monitoring Create a DMARC record Create an SPF record

Open source and self-hostable

The engine behind this analyzer is open source under the MIT license, and it is the same parser that reads real reports for our customers. It runs entirely in your browser, so reports never leave your machine. Read the code, run it on your own infrastructure, or send a pull request.

View on GitHub

Frequently asked questions

Is my DMARC report data secure?

Yes. The analyzer runs entirely in your browser. Your report is parsed locally with the built-in DOMParser and never uploaded, logged, or sent to any server.

What file formats can I analyze?

Plain .xml, gzip-compressed .xml.gz or .gz, and .zip archives. Inside a .zip, the first XML file is used. The size limit is 10 MB, far larger than any real aggregate report.

What does a DMARC aggregate report contain?

A daily summary of mail claiming to be from your domain: the reporting receiver and date range, the policy you published, and one record per group of messages with the same result, each carrying the source IP, message count, SPF and DKIM verdicts, and the disposition the receiver applied.

How do I open a .gz or .zip DMARC report?

Drop the file straight onto the analyzer as it arrived in your inbox. It decompresses .gz and .zip in your browser automatically, so you do not need to unzip it first.

Why is the disposition none when my policy is reject?

Because p=reject is the assessment a receiver weighs only for mail that fails DMARC. A message that passed SPF or DKIM and aligned passes DMARC, so the receiver delivers it and records the disposition as none. You only see reject on rows that actually failed.

What is the difference between aggregate and failure reports?

Aggregate reports (rua) are daily statistical XML summaries with counts, not message content. Failure reports (ruf), formerly called forensic and now specified in RFC 9991, are a separate per-message format. This analyzer reads aggregate reports, which is what nearly every receiver sends.

Why does SPF pass in auth_results but DMARC still fail?

auth_results holds the raw SPF check, which can pass on a sending provider's own domain. DMARC also requires alignment with the domain in your From header. If the passing domain does not align with yours, DMARC fails. The aligned verdict in policy_evaluated is the one that counts.

How often do receivers send DMARC reports?

Typically once per day per domain by each receiver, for example one daily report from Google and one from Microsoft. DMARCbis (RFC 9989 §8) now recommends a daily interval and dropped the older ri tag, though a receiver may report more or less often. Because reports arrive every day from every receiver, reading them by hand stops scaling quickly, which is what automated monitoring solves.

Protect Your Email Reputation

DMARC monitoring doesn't have to be complicated. Let us handle the technical details while you focus on your business.

Start Monitoring View Pricing