DMARC Aggregate (RUA) Report Viewer
Read the XML reports DMARC sends you, without the squinting
📊 DMARC Aggregate (RUA) Report Viewer
Upload a DMARC RUA aggregate report (.xml or .xml.gz) 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.
Frequently Asked Questions
Common questions about DMARC aggregate (RUA) reports.
What is a DMARC aggregate (RUA) report?
When you publish a DMARC record with rua=mailto:…, 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 usually arrive as .xml.gz attachments and are unreadable without a viewer like this one.
What does "aligned" mean?
DMARC requires SPF or DKIM to do more than pass. They have to be 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 DKIM signature. Either one passing in alignment is enough for DMARC to pass.
Why are some IPs sending mail I don't recognise?
Usually one of three things. Shadow IT: a department signed up for a SaaS that sends from your domain and didn't tell you. Forwarding: a mailbox is forwarding your mail and the receiver attributes the source to the forwarding server. Or actual spoofing: 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.
Is my report stored anywhere?
No. The XML is read in your browser, posted to our parser as JSON, parsed in PHP memory, and thrown away as soon as the response goes out. We do not 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.
Why was my upload rejected?
Common reasons: the file is not 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 (we refuse those to defend against XXE). If a real RUA report keeps hitting these limits, it has probably been mis-bundled. Open the underlying daily XML instead of a multi-month archive.