DMARC Report Analyzer
Turn the confusing DMARC report your mailbox received into a clear, readable table of who is sending email as your domain — and whether it passed. Upload the .gz, .zip, or .xml file, or paste the XML. Everything is read inside your browser and nothing is uploaded.
New to DMARC reports? Start here
What is a DMARC report?When you turn on DMARC (Domain-based Message Authentication, Reporting & Conformance) for your domain, mailbox providers like Google and Microsoft start emailing you a daily file. That file lists everyone who sent email using your domain name and whether it looked genuine. The file is XML — basically a wall of computer code that is impossible to read by hand. This free tool turns one of those files into a clear table.
Why it matters. The report is the only way to see who is actually sending mail “from” you — including scammers spoofing your domain to trick your customers. Just as importantly, it confirms that your real email (your newsletter tool, your invoicing system, your support desk) is passing the checks. You want to confirm that before you tighten your policy, otherwise you could accidentally send your own legitimate mail to the spam folder.
How to use this tool
- 1Find the report in your inbox. It arrives at the address you put in your DMARC record’s
rua=tag (RUA = the aggregate reporting address — the mailbox where the daily summaries are sent). The subject usually contains the word “Report Domain” and your domain name. - 2Grab the attachment. The report is almost always a small compressed attachment ending in
.gzor.zip. You do not need to unzip it first — save it to your computer as-is. - 3Drop it into the box below. Drag the file onto the upload area, or click to pick it. (Already have the raw XML on screen? You can paste it instead.)
- 4Read the table. The dashboard shows each sender, how many messages it sent, and a green “pass” or red “fail”. Red rows are the ones worth looking into — the What the results mean section explains every column in plain English.
Your file never leaves your computer
This is not a website that quietly uploads your data. The file is opened, unzipped, and read 100% inside your own browser. Nothing is sent to us or to any server — no upload, no copy, no logging of the IP addresses in your report. Once this page has loaded you could even disconnect from the internet and it would still work.
Upload a report
…or paste the XML
Paste the contents of a decompressed DMARC aggregate report (its root element is <feedback>).
In depth: how to read a DMARC aggregate report
The plain-language version is above. This section is the full technical explanation if you want to understand exactly what the report contains.
A DMARC aggregate report (often called a RUA report, after the rua= aggregate reporting address it is sent to) is an XML document that a receiving mail provider sends you once per day, one per receiver. You start getting them the moment you publish a DMARC record with a rua= tag — for example v=DMARC1; p=none; rua=mailto:[email protected]. Each report summarises every message that claimed to come from your domain during a 24-hour window: the sending IP, the message count, the SPF and DKIM outcomes, whether those outcomes aligned with your From domain, and the disposition the receiver applied (none, quarantine, or reject). Crucially, it contains no message content — only authentication metadata — so it is safe to analyse and is the feedback loop you use to move a policy from monitoring to enforcement without breaking real mail.
The reports arrive compressed, usually as a .gzor .zip attachment, and the raw XML is hard to read by eye. This analyzer decompresses and parses the file entirely in your browser using the native DecompressionStreamand DOMParser APIs, then renders a dashboard: who sent the report and for which domain, your published policy, a pass/fail summary, and a sortable table of every source IP with its DKIM and SPF alignment, disposition, and the header-From it used. Nothing is uploaded to a server.
The single most important thing to understand is alignment. DMARC does not care merely that SPF or DKIM passed — it cares that the domain which passed aligns with the visible From address. A message passes DMARC if at least one of aligned SPF or aligned DKIM passes. That is why a source can show raw SPF=pass yet DMARC SPF=fail (the SPF domain did not align), and why a forwarded message can show SPF=fail but aligned DKIM=pass and still be perfectly fine: forwarders rewrite the envelope and break SPF, but a DKIM signature survives forwarding and keeps the message aligned. The rows that actually matter for a p=quarantine or p=reject policy are the ones where both aligned methods fail — those are highlighted in red above.
Use the dashboard to inventory your legitimate senders. For each failing source, decide whether it is yours (an ESP, CRM, ticketing system, or newsletter tool that needs SPF or DKIM configured) or spoofing you can safely reject. Once every legitimate source aligns, you can confidently raise your policy. When you are ready, build or adjust the record with the DMARC generator, validate the live record with the DMARC checker, read the full background in the DMARC guide, and explore the rest of the free email-security tools.
What the results mean
Each row in the table is one sender. Here is what every column tells you, in plain English:
- Source IP
- The internet address of the computer that sent the mail. Think of it as the return address on an envelope — it tells you where the message physically came from.
- Count (message count)
- How many emails that sender sent with this exact result during the day. A big number next to a red row means a lot of mail is failing and deserves attention first.
- SPF result
- SPF (Sender Policy Framework) is a list of servers you have approved to send mail for your domain. A “pass” means the sender was on your approved list. SPF often breaks when a message is forwarded, so an occasional SPF “fail” is not automatically bad.
- DKIM result
- DKIM (DomainKeys Identified Mail) is a tamper-proof digital signature added to your outgoing mail. A “pass” means the signature was valid and the message was not altered in transit. Unlike SPF, DKIM normally survives forwarding.
- Alignment
- The most important idea, and the easiest to miss. DMARC does not just ask “did SPF or DKIM pass?” — it asks “did they pass for your domain, the one your customers see in the From line?”. That match is called alignment. A message passes DMARC if at least one of SPF or DKIM passes and aligns with your domain. This is why a forwarded email can fail SPF but still be perfectly fine: its DKIM signature still aligns.
- DMARC disposition
- What the receiving provider actually did with mail that failed, based on the policy you published:
- none — delivered as normal. You are in “just watching” mode and nothing is being blocked yet.
- quarantine — sent to the spam/junk folder.
- reject — blocked entirely and never delivered.
none to quarantine or reject.Field reference: what the dashboard shows
| Column | XML source (RFC 7489) | Meaning |
|---|---|---|
| Source IP | record/row/source_ip | The IP that sent the messages. No reverse-DNS lookup is performed. |
| Count | record/row/count | How many messages this IP sent with this exact result. |
| DMARC | derived from policy_evaluated | Pass if aligned DKIM or aligned SPF passed; otherwise fail. |
| DKIM / SPF (aligned) | policy_evaluated/dkim · /spf | DMARC’s evaluated alignment result, not the raw check. |
| Disposition | policy_evaluated/disposition | What the receiver did: none, quarantine, or reject. |
| From (header) | record/identifiers/header_from | The visible From domain DMARC aligns against. |
| Auth details | auth_results/dkim · /spf | Raw per-signature/per-domain DKIM (domain, selector) and SPF results. |
The report header also surfaces report_metadata (org_name, email, report_id, date range) and the full policy_publishedrecord (domain, p, sp, np, adkim, aspf, pct, fo).