Every domain that publishes a DMARC record can receive daily aggregate reports — called RUA reports — from major mailbox providers (ISPs) like Google, Microsoft, and Yahoo. These reports tell you exactly which IP addresses are sending mail on behalf of your domain, whether those messages passed or failed DKIM and SPF alignment, and how receiving servers handled them.
The problem is that RUA reports are delivered as dense XML files that are nearly impossible to read without a tool to parse them. The viewer below accepts a raw .xml file, a .zip archive, or a .gz compressed file (the three formats providers commonly use), parses the report server-side, and returns a plain-English summary alongside organized detail tables covering every element defined in RFC 7489 — so you can quickly determine whether your email authentication is healthy or whether action is needed.
Paste your DMARC RUA XML report below, or upload an .xml or .zip file, then click Analyze Report.
Upload file (.xml, .zip, or .gz):
Analyze Report
Analyzing report…
How to Use The RUA Viewer
Your DMARC RUA reports are delivered to the address you specified in your DNS record’s rua= tag — typically something like rua=mailto:dmarc@yourdomain.com. Check that inbox for messages with subjects like “Report domain” from providers such as Google, Microsoft, Yahoo, or your ESP. Each message will contain an attachment in one of three formats: a plain .xml file, a .zip archive containing an XML file, or a .xml.gz gzip-compressed file. All three formats are supported here.
To analyze a report, either upload the attachment directly using the file picker — no need to decompress it first — or open the file in a text editor, copy the full XML contents, and paste them into the text area. Then click Analyze Report. The tool will validate the XML, confirm it is a properly structured DMARC aggregate report, and return four sections: a plain-English summary with a pass or fail verdict at the top, a Report Metadata table identifying who sent the report and the time window it covers, a Published DMARC Policy table showing your current DNS configuration as the receiving server read it, a Message Records table listing every source IP and its alignment outcome, and an Authentication Results table breaking down individual DKIM and SPF checks per message.
Note: Uploaded files are analyzed on the server and deleted immediately — nothing is stored.
Understanding DMARC, RFC 7489, and RUA Reports
DMARC — Domain-based Message Authentication, Reporting, and Conformance — is an email authentication protocol that allows domain owners to specify how receiving mail servers should handle messages that fail authentication checks, and to request reports about what is happening with mail that claims to come from their domain. It builds on two older protocols, SPF and DKIM, by adding a layer of policy enforcement and a feedback mechanism that closes the loop between senders and receivers.
Without DMARC, a bad actor can send an email that displays your domain in the From address and there is nothing preventing it from reaching an inbox. SPF and DKIM can individually verify parts of a message’s path, but neither alone tells receiving servers what to do when those checks fail, and neither provides the sender with visibility into abuse. DMARC solves both problems: it gives domain owners control over unauthenticated mail and provides data on how their domain is used across the internet.
RFC 7489
DMARC is formally defined in RFC 7489, published by the Internet Engineering Task Force (IETF) in March 2015. The specification was authored by a working group of email infrastructure experts from Google, PayPal, Yahoo, Microsoft, and several other organizations, and it superseded earlier industry drafts that had been circulating since around 2012.
RFC 7489 defines the full lifecycle of DMARC: how a domain owner publishes a policy in DNS, how a receiving mail server retrieves and applies that policy, how alignment between the RFC5322 From domain and the authenticating domain is evaluated, how aggregate and forensic reports are generated and delivered, and exactly what XML schema those reports must follow. The specification is precise enough that any two conforming implementations — whether from Google, Microsoft, Proofpoint, or an open-source MTA — should produce interoperable results.
The DMARC DNS Record
A domain enables DMARC by publishing a TXT record at _dmarc.yourdomain.com. A typical record looks like this:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r;
The v=DMARC1 tag identifies the record as a DMARC policy. The p= tag sets the policy — none means monitor only and take no action, quarantine directs failing mail to the spam folder, and reject instructs the receiving server to refuse the message entirely at the SMTP gateway. The pct= tag specifies what percentage of failing mail the policy applies to, which allows operators to gradually ramp up enforcement. The rua= tag tells receiving servers where to send aggregate reports. The adkim= and aspf= tags control alignment mode — r for relaxed and s for strict, which determines how closely the authenticated domain must match the From domain.
SPF and DKIM Alignment
DMARC does not re-run SPF or DKIM. Instead, it checks whether the domain that passed SPF or DKIM matches the domain in the RFC5322 From header—the one the recipient actually sees. This alignment check is the heart of what makes DMARC meaningful.
SPF verifies the envelope sender, an SMTP-level address that is invisible to the end user and trivially spoofable. DKIM on its own verifies a cryptographic signature tied to a signing domain, but that domain does not have to match the From address. DMARC’s alignment requirement ties authentication back to the visible sender identity. In relaxed mode, the authenticated domain only needs to share an organizational domain with the From domain — so mail.example.com aligns with example.com. In strict mode, the domains must match exactly.
Critically, DMARC passes if either SPF or DKIM alignment succeeds — not both. This means that a message sent through a third-party ESP that uses its own domain as the envelope sender (causing SPF misalignment) will still pass DMARC as long as the ESP is configured to sign with a DKIM key belonging to your domain. This is why SPF alignment failures are common in RUA reports and frequently represent no actual problem.
What an RUA Report Contains
Aggregate reports are generated by receiving mail servers and delivered once per day, typically covering a 24-hour UTC window. Each report is an XML document whose structure is defined precisely in the appendix of RFC 7489. The root element is
The <report_metadata> block identifies the organization that generated the report, provides a contact email, assigns a unique report ID, and specifies the <date_range> with Unix timestamps for the beginning and end of the reporting period. Any processing errors encountered by the reporter are recorded here in <error> elements.
The <policy_published> block is a snapshot of your DMARC DNS record as the reporting organization read it at the time of the report. It records the <domain>, the <p> policy, the <sp> subdomain policy, <pct>, <adkim>, <aspf>, and <fo> (failure reporting options). This is valuable because it confirms what policy was actually in effect — DNS propagation delays or configuration errors can mean the policy being applied differs from what you intended.
The bulk of the report is made up of one or more <record> elements, each representing a group of messages that share the same source IP address and authentication outcome. Within each record, <row> contains the <source_ip>, a <count> of messages, and <policy_evaluated> with the final <disposition> applied and the alignment results for <dkim> and <spf>. If a policy override was applied — for example, because the receiving server has a local whitelist — it is recorded in <reason>. The <identifiers> block captures the <header_from>, <envelope_from>, and <envelope_to> addresses. The <auth_results> block then provides the raw authentication results, with one <dkim> entry per signature found in the message (including the <domain>, <selector>, and <result>) and one <spf> entry per SPF check performed.
Reading the Reports in Practice
A healthy domain at full reject enforcement should produce reports where every record shows a disposition of none (no action needed) or where the few failing records are from identifiable third-party senders that use their own envelope domains. A domain that is being actively spoofed will show unfamiliar source IPs with both DKIM and SPF alignment failures and a disposition that matches the policy level. A domain migrating to a new ESP or adding a new sending system will often show temporary SPF failures from the new source until DNS records are updated.
The aggregate reporting mechanism is intentionally designed to be non-invasive — RUA reports contain no message content, no subject lines, and no recipient addresses. They are purely statistical records of authentication outcomes, making them safe to receive and analyze without any privacy concerns.
Moving from Monitoring to Enforcement
Most domain owners begin with p=none to collect data before taking action. The recommended path is to start at none, analyze RUA reports until all legitimate sending sources are passing alignment, then move to p=quarantine; pct=10 and gradually increase the percentage over days or weeks while monitoring reports for unexpected failures, and finally advance to p=reject; pct=100 once confident that no legitimate mail is being caught. This graduated approach ensures that a misconfigured ESP or a forgotten outbound mail path does not cause legitimate messages to be rejected before the problem is discovered and corrected.
©2026 DK New Media, LLC, All rights reserved | DisclosureOriginally Published on Martech Zone: App: DMARC RUA Report Viewer