DMARC Report Analyzer
Paste a DMARC aggregate (RUA) report or drop the .xml, .gz or .zip a receiver sent you. Everything is parsed in your browser. The file is never uploaded.
What a DMARC report actually tells you
Every receiver that gets mail claiming to come from your domain can send back a daily aggregate report: a list of sending IPs, how many messages each one sent, whether SPF and DKIM aligned with your From domain, and what the receiver did as a result. Read together, those reports are a complete inventory of who sends as you, including the services you have forgotten about and anyone spoofing you.
The catch is the format. Reports arrive as compressed XML, one per receiver per day, so a week of mail across a handful of domains is hundreds of files. Reading one by hand is workable; keeping up with all of them is not, which is where either a monitoring platform or a self-hosted parser like parsedmarc comes in. This tool covers the case in between: one report, open now, readable in a few seconds, without handing your sending data to anyone.
Read a DMARC XML report in evidence order
| Evidence | What it tells you | How to use it |
|---|---|---|
| Report metadata | The reporting organization, report ID, and UTC date range identify who produced the file and the period it covers. | Confirm the date range and keep the report ID when comparing duplicate or delayed files. |
| Published policy | The report records the DMARC policy the receiver discovered, including alignment modes and subdomain handling. | Compare it with the current public record before assuming the historical result reflects today's policy. |
| Source IP and count | Each row groups messages by source and reports the number observed during the period. | Prioritize high-volume unknown or failing sources, then identify the service owner before changing policy. |
| DMARC alignment | The evaluated row shows whether SPF and DKIM aligned and which disposition the receiver applied. | Remember that either an aligned SPF pass or an aligned DKIM pass is enough for DMARC. |
| Underlying authentication | Auth results show the domains and selectors used for SPF and DKIM beneath the summarized DMARC decision. | Use these fields to trace the exact sender; do not treat an unaligned SPF pass as a DMARC pass. |
Why the disposition can differ from the policy
A report's disposition is the action the receiver recorded for that row. It can differ from the published policy because the message passed DMARC, the receiver applied local policy, or the report covers an older policy window. Treat the XML as receiver evidence, not as a message log or proof that an unfamiliar IP is malicious.
From one XML file to ongoing monitoring
One report is enough to investigate a source or validate the file structure. It is not enough to inventory every legitimate sender or judge an enforcement change. Review a complete business sending cycle, group the same source across receivers, and confirm important paths with real message headers before changing policy. Use the DMARC checker to verify the public record behind the report.
Related DMARC report workflows
Email authentication knowledge base
What is a DMARC report analyzer?
It's a parser for the aggregate (RUA) reports that receiving mail servers send back about your domain. Those reports arrive as compressed XML (one per reporting organisation per day) listing each IP that sent mail claiming to be you, how many messages it sent, and whether SPF and DKIM aligned. An analyzer turns that into something readable: which services are sending as your domain, which are failing authentication, and what the receiver did about it.
Is this DMARC analyzer free?
Yes, with no account and no limit. It runs entirely in your browser (there is no upload and no server involved) so there is nothing to meter.
Is it safe to upload a DMARC report to an online analyzer?
A DMARC report contains your sending IP addresses, message volumes, and which services send on your behalf. That is useful competitive and reconnaissance information, so it is worth caring where it goes. This tool parses the file locally in your browser: nothing is uploaded, logged, or stored, and you can confirm that by opening your browser's network tab while you run it. Most online analyzers do upload the file, check before pasting.
How do I get my DMARC reports?
Reports go to whatever address is in the rua tag of your DMARC record, for example rua=mailto:dmarc@yourdomain.com. Receivers send them daily, as .zip or .gz attachments containing XML. If your record has no rua tag you are not receiving any, and adding one is the first step. If reports are going to a mailbox nobody reads, that mailbox is where to look.
Why does a row show SPF fail but DMARC pass?
DMARC only needs one aligned identifier. If DKIM passes and its domain aligns with the From domain, the message passes DMARC even with an SPF failure. This is normal for forwarded mail, which breaks SPF by design while leaving the DKIM signature intact, and it is the single most misread part of an aggregate report.
Why does a row show a source IP I don't recognise?
Three usual explanations. It's a legitimate service sending on your behalf that you had forgotten about: a billing system, a ticketing tool, a marketing platform. It's a forwarder relaying your mail. Or it's someone spoofing your domain. The volume column usually distinguishes them: real services send consistently, spoofing tends to spike. Until every legitimate source is identified and aligned, moving to p=reject risks blocking your own mail.
Can I analyse DMARC reports with open-source software instead?
Yes. parsedmarc is the established open-source option: Apache 2.0, self-hosted, and it feeds Elasticsearch or OpenSearch with Kibana or Grafana dashboards. It is a good fit if you want to retain history yourself and are happy running the infrastructure. This tool is for the case where you have one report in front of you and want to read it now.
What file formats does this accept?
Raw .xml pasted in, or an .xml, .gz or .zip file. Gzip and single-entry ZIPs (which is how receivers actually send them) are decompressed in the browser. If an unusual archive is rejected, extract the .xml and paste that.
What is the difference between aggregate (RUA) and forensic (RUF) reports?
Aggregate reports are the daily statistical summaries this tool reads: counts per sending source, with authentication results, and no message content. Forensic reports are individual failed-message samples sent to the ruf address, they can include headers and sometimes content, and most large receivers do not send them at all for privacy reasons. Aggregate reports are what you build a DMARC rollout on.
What should I do about the failures this shows?
Work down the list by volume. For each failing source, decide whether it is yours. If it is, fix alignment: add it to SPF, or better, get it signing with an aligned DKIM key. If it is not yours and the volume is meaningful, that is spoofing, and it is an argument for moving toward enforcement. Only once every legitimate source passes should you step the policy up from none to quarantine to reject.
The tags and terms you'll meet inside an aggregate report.
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.