DMARC Report Analyzer
Read the DMARC aggregate reports your receivers send: who is sending as your domain, how much, and what passes.
Related tools
- Email SecurityCheck SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI for a domain and get the records to fix them.
- Email Header AnalyzerTrace delivery hops, read SPF, DKIM and DMARC results, and see whether they actually cover the From address.
- Record BuildersBuild SPF, DMARC, BIMI, MTA-STS and TLS-RPT records, meta tags and robots.txt with live checks as you type.
- MX & SMTPCheck a domain's mail servers and test SMTP connections, STARTTLS and open relay.
About this tool
DMARC Report Analyzer opens the aggregate (rua) reports receivers send you every day and turns the XML into something a person can read. Drop in the attachments as they arrived - .xml, .xml.gz or a .zip of several - and it decompresses and parses them in your browser, merges the reports from different receivers and different days into one view, and lists every sending source with its volume, the DMARC verdict, and the SPF and DKIM results with the domains they were checked against. The distinction the raw XML hides is the one it puts first: a source can pass SPF on its own bounce domain and still fail DMARC, because DMARC only counts a pass when SPF or DKIM aligns with the domain in the From header (RFC 7489 §3.1). Nothing is uploaded - the reports carry the addresses of everyone who sent mail as your domain, and they stay on your machine. The one exception is the per-source lookup button, which sends only that one IP address to the XGM server for reverse DNS and the network owner, and it is never pressed for you. It reads aggregate reports, not forensic (ruf) reports, and it does not collect the reports from your mailbox.
A DMARC record with rua= asks every large receiver to send you one XML report a day listing every address that sent mail claiming to be your domain, how many messages it sent, and whether SPF and DKIM passed. The attachment arrives as .xml, .xml.gz or .zip and is written for machines. This page opens those files and turns them into the two things worth knowing: which senders are yours and passing, and which are failing and why.
DMARC does not ask whether SPF or DKIM passed. It asks whether they passed for the domain in the From header, which is called alignment. A mailing service that sends with its own envelope domain will pass SPF and still fail DMARC, and that is the single most common finding in these reports; the table names the domain each mechanism authenticated so the difference is visible.
Strict alignment (adkim=s, aspf=s) requires the authenticated domain to be exactly the From domain. Relaxed alignment, the default, accepts the same organisational domain. This page treats relaxed alignment as satisfied when one domain is a subdomain of the other; it does not carry the Public Suffix List, so two unrelated names under one registry suffix are reported as unaligned rather than guessed at.
Privacy: aggregate reports contain the IP addresses of everyone who sent mail as your domain, including your own servers and any forwarder. The files are unpacked and parsed by this page with the browser's own gzip and deflate support, are never uploaded, are never written into the URL and are never stored - reloading the page clears them. The one request this page can make is the “Who is this?” button next to an address, which sends that single IP address to the XGM server for a reverse DNS and ASN lookup and is never pressed for you.
How to use it
- Save the report attachments from the mailbox your rua address delivers to.
- Open the analyzer and drop the files in - .xml, .xml.gz and .zip all work, and several at once are merged.
- Read the per-source table from the top: the largest senders first, with what passed and what aligned.
- For a source you do not recognise, press the lookup button to see the reverse DNS and network owner.
- Fix the sources that fail: add a legitimate sender to SPF, turn on DKIM signing at the provider, or leave a forgery to be rejected once the policy is enforced.
FAQ
Are my reports uploaded anywhere?
No. The files are decompressed and parsed by your own browser with DecompressionStream and the built-in XML parser; nothing is sent to the XGM server, written into the URL or stored. That matters more here than on most pages, because an aggregate report lists the IP addresses of every machine that sent mail claiming to be your domain, including your own infrastructure. The only request the page can make is the per-source lookup, which sends exactly one IP address and only when you press the button.
SPF passed but DMARC failed. How?
SPF authenticates the envelope sender - the domain in MAIL FROM, which is what a bounce goes to - and DKIM authenticates the domain in the signature's d= tag. DMARC only counts a pass when one of those domains aligns with the domain your reader sees in the From header (RFC 7489 §3.1). A mailing service that sends with its own bounce domain passes SPF on that domain and fails DMARC alignment, which is why the table shows the domain each check was made against rather than a bare pass or fail.
Can I open a .zip with several reports in it?
Yes. A .zip is read entry by entry in the page, and a .xml.gz is decompressed the same way; you can also drop a whole folder of files at once. Reports from different receivers and different days are merged into one view, and the same report arriving twice is counted once - it is matched on the reporting organisation and the report id, which is what the standard requires to be unique.
What should I do about a source I do not recognise?
Look at the volume and the results before doing anything. A handful of failing messages from an address you do not know is usually a forwarder or an old form-mail script, not an attack, and forwarding breaks SPF by design while DKIM usually survives it. A large aligned-and-passing source you do not recognise is normally a provider a colleague set up. The page suggests what the evidence supports and nothing more: it will not tell you to add an address to SPF just because it appeared in a report, because that is how a domain ends up authorising a spammer.
Why are there no message contents in the report?
Aggregate reports are counts, not messages: per source IP, per day, how many messages were seen and what the checks returned. There is no subject, no recipient and no body, which is what makes them safe for a receiver to send. Message-level detail is the job of forensic (ruf) reports, which most large receivers stopped sending for privacy reasons, and which this tool does not read.