DMARC Aggregate (RUA) Report Viewer

100% client-side · files never leave your browser Accepts .xml and .xml.gz

Upload a DMARC RUA aggregate report or paste the XML directly. We render it as a readable table: source IP, disposition, and SPF/DKIM alignment. Reports are parsed in memory and never written to disk.

Limits: 1 MB compressed upload, 8 MB after decompression. Files are read in your browser, posted as JSON, parsed in memory, then thrown away. Nothing is written to disk.
Try an example: Google report (p=quarantine) · Spoofing attacks (Outlook, p=reject) · Mixed senders & misconfigs (Yahoo, p=none)

How this DMARC report viewer works

A DMARC aggregate report (RUA) is an XML file. Receivers that publish DMARC results send one to the address in your rua= tag once a day. It lists every IP that sent mail claiming to be from your domain, and what the receiver did with it. Reading the raw XML by hand is miserable. Upload the report or paste the XML above and the viewer renders it as a table you can scan.

For each source IP you get the message volume, the receiver's disposition (none, quarantine, or reject), and whether SPF and DKIM aligned with the From header. Forgotten subdomains and shadow-IT senders show up as IPs you don't recognise still passing or failing. The file is parsed in memory and discarded. Nothing is written to disk, no third party sees the contents.

Where do these reports come from?

Any receiver that honours DMARC. Google, Microsoft, Yahoo, Comcast, Mail.ru and most large hosts send daily. Smaller receivers send sporadically or not at all. The address you publish in your DMARC record decides where they land: 

v=DMARC1; p=quarantine; rua=mailto:[email protected]

They arrive as .xml.gz attachments. Open the gzip, get the XML, drop it in above.

What is alignment, and why does it matter here?

DMARC doesn't care that SPF or DKIM passed in isolation. It cares that one of them passed against the same domain a human sees in the From header. SPF alignment checks the From domain against the envelope Return-Path. DKIM alignment checks the From domain against the signature's d= tag. Either one in alignment is enough for the row to pass DMARC.

That's why the viewer shows SPF and DKIM as two separate alignment columns, not one combined pass/fail.

What should I be looking for in a report?

Three patterns are worth your time:

Why this matters

Most domains publish p=none and never read a report. The record is decorative. RUA reports are the only feedback loop telling you whether moving to p=quarantine or p=reject will break legitimate mail. Reading them is how you find the SaaS tools nobody told you about before they start bouncing.

Our take: if you haven't looked at a report in three months, you don't actually know what's sending as your domain.

What to do: load a recent report, identify every source, and fix alignment on anything you recognise. Once the table is clean for two reporting cycles, step the policy up.

Where to go next

For a tag-by-tag breakdown of the XML, see the DMARC tags reference. To confirm your published policy matches what receivers are reporting on, run the DMARC record checker. For unfamiliar source IPs, the IP info lookup identifies the operator so you can decide if it's a sender you know.

Frequently Asked Questions

Common questions about DMARC aggregate (RUA) reports.

Three real reports you can load into the viewer above:

Publish a DMARC record with rua=mailto:… and receivers like Gmail, Outlook and Yahoo send you XML reports each day. Each report summarises every IP that sent mail claiming to be your domain, whether SPF and DKIM aligned, and what the receiver did about it. The reports arrive as .xml.gz attachments and are unreadable without a viewer like this one.

DMARC needs more than SPF or DKIM passing. One of them has to pass aligned with the domain in the message's From header. SPF alignment compares the From domain against the envelope-from (Return-Path) domain. DKIM alignment compares the From domain against the d= tag of the signature. Either one in alignment is enough for the row to pass DMARC.

Usually shadow IT. A department signed up for a SaaS that sends from your domain and didn't tell you. Sometimes it's forwarding, where a mailbox forwards your mail and the receiver attributes the source to the forwarding server. Sometimes it's actual spoofing, where someone is putting your From address on their mail. Run each unfamiliar IP through /ip-info to identify the operator before you decide which case it is.

No. The XML is read in your browser, posted to the parser as JSON, parsed in PHP memory, and thrown away as soon as the response goes out. We don't write the file to disk, log its contents, or retain any per-record data. You can audit this in the source. The parser never calls move_uploaded_file() or any filesystem write.

A few common reasons. The file isn't gzip or XML (header bytes don't match). The compressed size is over 1 MB. The decompressed size is over 8 MB. The XML has more than 50,000 nodes. Or the document declares a DOCTYPE, which we refuse to defend against XXE. If a real RUA report keeps hitting these limits, it has probably been mis-bundled. Open the underlying daily XML rather than a multi-month archive.