DMARC Report Analyzer
Drop the aggregate report files receivers send you — .xml, .xml.gz, or a .zip holding several — and get back what the XML buries: which sources send as your domain, how much of it passes SPF and DKIM alignment, what failed both, and what to fix first, in plain language. Everything is decompressed and parsed in your browser; the files never leave your browser, because a DMARC report is a map of who sends your mail — and who pretends to.
Or drop the files anywhere in this box. Reports from different receivers and different days merge into one table, grouped by source.
Reports read
What to fix
Sources
| Source IP | From domain | Messages | Disposition | SPF alignment | DKIM alignment | DMARC |
|---|
A row passes DMARC when either alignment passes — that is the definition receivers apply. Rows failing both are highlighted. To check the records themselves rather than the reports they generate, use the email deliverability check.
What an aggregate report actually is
DMARC has two halves. The first is the record you publish — policy, alignment modes, reporting address — and it is the half every checker, including the email deliverability check on this site, can read. The second half is the feedback loop: every large receiver that sees mail claiming to be from your domain summarises what it saw and mails the summary to your rua address, usually once a day, as XML. That file is the only evidence of who else sends as you. Spoofing campaigns, a marketing platform a colleague connected two years ago, the monitoring service still using a decommissioned server — all of it appears in aggregate reports weeks before it appears anywhere else, if anyone reads them. Almost nobody reads them, because raw XML with nested policy_evaluated elements is close to illegible, and the files pile up gzipped in a mailbox. That is the gap this analyser fills: the same file, turned into a table of sources and verdicts, with the failures translated into the fix each one needs. The companion guide, reading your DMARC reports, explains the format's vocabulary — disposition, alignment, the difference between an authentication result and an aligned one — with a full worked example.
Two habits make the reports worth more. First, read them before enforcing: a p=none policy with reporting is a surveillance system, and the weeks it runs are how you learn every legitimate sender, so that the move to quarantine and reject breaks nothing real. Second, treat every unknown source as a ticket, not a curiosity — identify it, align it or watch enforcement kill it, but never let an unrecognised stream sit in the "probably fine" pile, because that pile is exactly where spoofing hides. Note what aggregate reports deliberately do not contain: no message bodies, no subject lines, no recipient addresses. They are counts and verdicts per source, which is why they can be shared with a provider's support team — as a file you hand over deliberately, not as an upload to a tool. This page keeps that property: the analysis happens where the file already is, on your machine.
Frequently asked questions
What is a DMARC aggregate report?
It is the daily feedback file receivers (Google, Microsoft, Yahoo and the rest) send to the address in your DMARC record's rua tag. For every source that sent mail claiming to be your domain, the report lists the source IP, the message count, the disposition the receiver applied, and whether SPF and DKIM aligned with your From domain. It is the only place where spoofing of your domain becomes visible as data rather than as a complaint from a confused customer. The guide reading your DMARC reports walks through a real report line by line.
How do I get these reports for my own domain?
Publish a DMARC record with a reporting address — v=DMARC1; p=none; rua=mailto:[email protected] — and receivers start sending within a day or so. If you have no record yet, or want to check the one you have, run the email deliverability check first: it reads the record, the policy and whether a reporting address is published. The reports arrive as small XML files, usually gzipped or bundled in a zip, which is exactly what this analyser opens.
Is it safe to open a report here? Where does the file go?
Nowhere. The file is decompressed and parsed in your browser, in this page; nothing is uploaded, transmitted or stored. That is a deliberate design, because aggregate reports are a map of your mail infrastructure — every sending service you use, every IP, and any spoofing aimed at you. Uploading that map to a stranger's server, or pasting it into an AI chat that keeps logs, hands the map to people it was never meant for.
A source I do not recognise fails both SPF and DKIM. Is that spoofing?
It is either spoofing or a sender nobody told you about — and the report alone cannot separate the two, which is why the analyser phrases it as a question to run down, not a verdict. Work it in order: does the IP belong to a provider your organisation pays (a CRM, a support desk, an old marketing tool, a forgotten monitoring service)? Is the volume steady and small (a misconfigured internal system) or bursty and large (a campaign)? While your policy is p=none that mail is delivered either way; once every legitimate source aligns and you enforce quarantine or reject, the unrecognised stream is refused regardless of which of the two it was.
My own legitimate mail is failing. What do I fix first?
Alignment, almost always at the provider. SPF fails to align when the provider sends from its own bounce domain — fix it with a custom return-path subdomain so the envelope domain is yours. DKIM fails to align when the provider signs with its own domain or does not sign at all — fix it by turning on DKIM signing with your domain in the provider's settings. One aligned mechanism is enough to pass DMARC, but DKIM is the sturdier of the two because it survives forwarding. Fix senders in volume order, watch the next reports go clean, and only then raise the policy.