DMARC Report
Viewer.

What a DMARC aggregate report actually is

When you publish a DMARC record with a rua= tag, you are asking every participating mailbox provider to mail you a summary of the messages they received claiming to be from your domain. Those summaries are the aggregate reports, and they usually arrive once a day, one per provider. A domain with normal mail flow might get reports from Google, Microsoft, Yahoo, Fastmail and a dozen smaller operators, each covering the same 24 hours from its own vantage point.

The content is deliberately narrow. Each report says: this IP address sent us this many messages claiming to be from your domain, SPF and DKIM came out like this, and here is what our DMARC evaluation decided to do about it. There are no subject lines, no recipients and no message bodies — an aggregate report is a count, not a copy. That is the whole design: it gives a domain owner enough visibility to find unauthorised senders and misconfigured legitimate ones, without handing anyone a feed of other people's mail.

What makes them hard to use is not the concept but the packaging. They arrive as compressed XML attachments, one file per provider per day, and the interesting parts are buried in nested elements that mean nothing at a glance.

Why it arrives as compressed XML

The report format is defined as XML, and the specification expects it to be sent as a mail attachment. Because a busy domain can generate a report with hundreds of rows, senders compress it — most commonly with gzip, producing a .xml.gz, though some large providers send a .zip instead. There is no single convention, so this tool decides what it is holding by reading the file's own leading bytes rather than trusting the extension. That matters more than it sounds: mail clients rename attachments freely when saving them, and a file called report.xml that is really gzip is common enough to be worth handling silently.

Reading the numbers: disposition is not authentication

Two different things in a report look similar and are constantly confused.

The authentication results record what happened when the receiver checked SPF and DKIM against the message. The policy evaluation records what the receiver's DMARC check concluded, and what it then did — deliver normally, quarantine, or reject. The second is not simply a copy of the first, and the gap between them is where most of the useful information lives.

The disposition also tells you about your own policy, not about the message's legitimacy. If your record says p=none — where every sensible rollout starts — the disposition on a failing message will still read none, because you asked the receiver to take no action while you watch. A page of failures under p=none is not a page of successfully blocked attacks. It is a page of things that would be affected the day you move to quarantine, which is exactly the list you need before you do.

The alignment trap

This is the single most common source of "but SPF passes, why is DMARC failing?", so it is worth being precise about.

DMARC does not simply ask whether SPF or DKIM passed. It asks whether a passing mechanism authenticated the same domain the reader sees in the From: header. That is alignment. A message can pass SPF perfectly — the sending IP really is authorised for the envelope domain — and still fail DMARC, because the envelope domain was the mailing platform's bounce domain and the From: header said your domain. Both facts are true at once, and only one of them is what DMARC measures.

In the report, this shows up as a row where the authentication results say pass and the policy evaluation says fail. This tool flags those rows explicitly rather than leaving you to compare two columns by eye, because the fix is specific and different from the fix for a real failure: you do not need to add the sender to SPF, you need the sender to align — usually by signing with DKIM using your domain, or by using a custom bounce domain under your own name.

The same trap exists for DKIM. A signature that verifies is not automatically an aligned signature; a platform that signs with its own domain gives you a valid DKIM signature that DMARC will not accept.

What the source IP does and does not tell you

Each row is keyed by the IP address that connected. That is genuinely useful — it is how you recognise your own mail servers, your CRM, your invoicing system, and the one marketing tool somebody signed up for without telling anyone.

It is also weaker evidence than it looks. Large senders operate enormous shared pools, so an IP belonging to a major cloud or ESP tells you which platform sent the message, not which customer of that platform. Forwarding muddies it further: when a recipient auto-forwards your mail, the forwarding server appears as the source, SPF fails because that server was never authorised, and the row looks like abuse while being entirely benign. A DKIM signature usually survives forwarding, which is why a domain relying on SPF alone sees far more alarming reports than one that also signs.

Treat an unfamiliar IP as a question, not a verdict. Our IP address lookup and ASN explorer are useful next steps for turning one into an actual operator name.

A worked example

Suppose a report covering one day shows 1,240 messages from three sources. Two are your mail servers, both fully aligned, and they account for 1,180 messages. The third is a single IP with 60 messages, SPF result pass, aligned SPF fail, and disposition none.

Read in order, that is not an attack. Something authenticated correctly for a domain that is not yours, which means a legitimate platform sending on your behalf without alignment — the shape of a newsletter tool or a helpdesk. The action is to find which system sends 60 messages a day and configure DKIM signing with your domain. The disposition reading none is not reassurance; it is the consequence of your policy still being p=none. Move to quarantine before fixing that sender and those 60 messages start landing in spam folders.

What this tool does not do

It does not upload your file. The report is read in your browser and no part of it is sent to our servers. This is not a courtesy — an aggregate report is a map of your mail infrastructure and its volumes, and there is no good reason for a web tool to collect that.

It does not store anything. Nothing is saved, so reloading the page clears it. There is no account and no history; if you want to compare two days, open them one after the other.

It reads one report at a time. Aggregate reports are per-provider and per-day by design. This tool shows you one file, faithfully, rather than merging several into a trend — merging correctly across providers is a different job with its own pitfalls.

It does not read forensic (RUF) reports. Those are a separate format sent to the ruf address, they contain individual message data rather than counts, and most providers no longer send them at all.

It is not a deliverability verdict. DMARC tells you about authentication and alignment. A domain can be perfectly aligned and still land in spam for reasons — reputation, content, list hygiene — that no aggregate report can see.

Common questions

I have no reports to open. Where do they come from? They only arrive if your DMARC record has a rua= tag pointing at an address you can read. Check yours with the DMARC checker; if there is no rua, the record generator will build one that has it.

Can I open a report for a domain I do not own? Mechanically yes — it is just a file. But you will only ever receive reports for domains whose DMARC record names your address, so in practice the files you have are for your own domains.

Why do different providers disagree about the same day? Each reports only the mail it received, so volumes differ by provider and by your audience. Disagreement about a specific sender is more interesting: it usually means forwarding, or a sender whose alignment is intermittent.

My report has one row and one message. That is normal for a low-volume domain, and it is still worth reading — the first report after publishing a record is how you confirm reporting works at all.

The file will not open. If it is a .zip containing several files, this tool reads the first entry; extract the XML and open that directly if the archive is unusual. A file that fails to parse is nearly always a mail client having saved the attachment partially.

Once the reports make sense, the next move is usually tightening the record itself — grade your current DMARC policy and plan the step from none to quarantine.