Drop in the XML, gzip or zip files your DMARC reports arrive in and read what they actually say: how much of your mail is passing, which sources are failing, and which of those failures is a sending platform to configure rather than someone to block. Every file is parsed in your browser, with no signup and nothing uploaded.
Drop your DMARC aggregate reports here
Reports arrive by email as .xml, .xml.gz or .zip attachments. Add as many as you have: one report is one receiver for one day. They are read in this browser and never uploaded.
Create a free Unspam account to save your results and re-run these checks anytime, so you catch a broken setup before it costs you. No credit card.
Once your DMARC record carries a rua address, mailbox providers start sending you one XML file a day each. Each file lists every IP address that sent mail claiming to be your domain, how many messages came from it, whether SPF and DKIM authenticated, whether either of them lined up with the address in the From header, and what the receiver did about it. That is the only view you will ever get of who is sending as your domain, and it is the reason DMARC has a reporting half at all. The files are also unreadable by eye: a single day from one large provider is thousands of lines of XML, in a schema that has just been revised, with two columns that look like the same question and are not. This tool reads both revisions, sums the message counts rather than the rows, and keeps those two columns apart, because the difference between them is the difference between a broken record and a working one you have not aligned yet.
The alignment result, and it takes exactly two values: pass or fail. It answers one question only, whether an authenticated identifier matched the domain in the From header. This is what DMARC acts on, and a domain passes if either leg passes, not both.
The raw authentication result, and it takes seven or eight values including softfail, temperror and permerror. It answers a different question: did SPF or DKIM succeed at all, for whatever domain it was checked against. A row showing SPF pass here and SPF fail above is not a contradiction, it is the signature of a platform sending with its own return path.
The number of messages a row stands for, from one to tens of thousands. Every total on this page is a sum of these, never a count of rows. Row counting is the most common way an aggregate report gets read wrong, because the answer stays plausible and moves in the right direction while being off by whatever the volume distribution happens to be.
The address that connected. This is the list to work down: sorted by volume, the top few sources are usually your mail platform, your website, your ticketing system and your own mail server, and recognising them is most of the work of getting to a policy you can enforce.
The commonest misreading, and it sends people to edit DNS that is already correct. If the raw SPF result is pass and the alignment result is fail, SPF worked: it authenticated the envelope domain, which belongs to the platform sending for you. The fix is a custom return path on your own domain, or DKIM alignment. Nothing you add to your SPF record changes it.
One file is one receiver for one day. A provider that sends no reports at all is invisible in it, and so is every message that never reached the one provider you are holding a report from. Load a couple of weeks from your largest receivers before drawing conclusions about a source you do not recognise.
A high pass rate says the mail you know about is authenticated. It says nothing about the mail you have forgotten, and the systems people forget are the ones that send rarely: invoicing, password resets, the CRM somebody set up two years ago. Work down the source list until every entry is one you can name, then change the policy.
RFC 9989 removed pct from DMARC. A receiver following the current specification applies your policy to every failing message rather than to the share you asked for, so a record left at p=reject with pct=25 now rejects four times as much mail as it did, with no edit to DNS. If a loaded report shows a pct tag, that record needs revisiting.
Aggregate reports carry counts, addresses and results. They carry no subjects, no bodies and no recipient addresses, which is what makes them safe to send at all. If you need to see a failing message itself, that is a failure report, a separate and far rarer thing that most providers do not send.
When a receiver does something other than your policy asked for, it says so and gives a reason: a mailing list, a forwarder it trusts, its own local policy. Those rows are not failures of your setup and chasing them wastes the time better spent on the sources above them.
