DMARC report reader

Runs in your browser

Publish a DMARC record with a rua address and mailbox providers start sending you XML — daily, from each of them, compressed, and unreadable. Open one here and it becomes a table: who sent mail as your domain, how much of it was believed, and what the receiver did with the rest.

The file is read in this page, on your machine. It is not uploaded. That matters more here than on most of these tools: an aggregate report is a map of everything that sends mail as your domain, and handing that to a third party to make it readable is a strange trade.

Read a report

Paste the XML, or open the .xml, .gz or .zip you were sent. Pasting the whole email it arrived in works too.

Nothing you paste or open here is uploaded. The work happens in this page, on your machine.

The report will appear here.

Reading a report without panicking

A failure row is usually a forwarder, not an attacker

This is the thing worth knowing before anything else, because it is what makes people set p=reject too early or abandon DMARC entirely.

When a message is forwarded, the forwarding server sends it from its own address. SPF checks the sending address, so SPF fails — correctly, because the message genuinely did not come from your servers. DKIM signs the message itself, so the signature survives forwarding intact. That is why you will see rows with spf=fail and dkim=pass, and why DMARC passes them: DMARC needs one identifier to align, not both.

Rows where both fail are the ones to look at. Even then, the first question is “is this a service I forgot I use?” — a helpdesk, an invoicing tool, a newsletter platform — rather than “is someone spoofing me?”.

Alignment is not the same as passing

A report carries two layers and they are easy to confuse. The auth_results block is the raw check: did this DKIM signature verify, did this SPF record authorise this sender. The policy_evaluatedblock is DMARC’s question: did the domain that passed match the domain in the From line the reader sees.

A bulk sender can hold a perfectly valid SPF pass on their own bounce domain and still fail DMARC, because that domain is not yours. This page shows both layers for each row, with the evaluated result first, because that is the one your policy acts on.

adkim and aspf control how strict the match is. r is relaxed and accepts a subdomain; s is strict and requires the exact domain. Relaxed is the default and is almost always what you want.

What the policy tags do

p=none means the receiver changes nothing and just reports. p=quarantine means spam folder. p=reject means the message is refused at the door and the sender gets a bounce. sp is the same choice for subdomains, and pct applies the policy to a sample rather than everything.

The order that works is the boring one: p=none, read reports until you recognise every source that passes, fix or authorise the ones that should, then tighten. Going to p=reject with an unrecognised row in the report means bouncing real mail, and you will find out from a colleague rather than from a dashboard.

The files arrive compressed

Google sends .xml.gz, Microsoft and Yahoo send .zip. This page opens both, and it decides by looking at the bytes rather than the file name — a report saved out of a mail client routinely loses its extension or gains a second one. You can also paste the whole email the report arrived in and let the page find the attachment.

Why this runs in your browser

XML parsers are a classic way to turn a file upload into a file read: a document that declares an external entity can ask the parser to fetch a local path and put it in the output. This page refuses any document that declares an entity at all, before parsing begins, and a DMARC report has no legitimate reason to declare one.

But the stronger protection is structural. The report never reaches a server of ours, so there is no server to attack with it, nothing to log, and nothing to produce if someone asks us for it.

What this cannot tell you

It cannot tell you who an IP address belongs to, and it does not look one up — that would be a DNS request, and this page makes none. It also only shows one report. A single day from a single receiver is a sample, and a source that appears once is usually less interesting than one that appears every day.

If you are setting a policy for the first time, the other tools here cover writing the record itself.

One of the free email tools.