DMARC report analyzer

Turn one DMARC aggregate report into sentences: who sent as your domain, what passed, and what the receiver did about the rest. No account, and nothing is stored.

What a DMARC aggregate report is

What does a DMARC report analyzer tell you? It names every IP that sent mail as your domain in one day at one receiver, how many messages each one sent, whether DKIM or SPF passed and aligned, and what the receiver did with the mail that failed.

An aggregate report is an XML file a receiving mail provider writes about your domain, usually once a day, and mails to whatever address the rua= tag of your DMARC record names. It is not a copy of anyone's mail. It carries no subjects, no bodies and no recipients: one <record> per sending IP and result combination, with a count of messages, what SPF and DKIM said about them, and what the receiver did as a result. Google, Microsoft, Yahoo and a few hundred smaller providers all send them, each in its own file.

The file is machine-readable rather than human-readable, it arrives gzipped or zipped with a name like google.com!example.com!1754956800!1755043199.zip, and one day of a small domain's mail can run to hundreds of records. This page unpacks one file and prints what it says.

How to read a DMARC report analyzer result

Start with the sources that failed. A message passes DMARC when DKIM or SPF passed and the domain that passed matches the domain in the From line, which is the part called alignment. That is why a source can show spf=pass in the SPF column and still fail DMARC: the SPF check passed for the sending platform's own domain rather than for yours. The DMARC column is the one that decides.

Then read the disposition. It is what the receiver did, which usually follows the policy it saw, but a receiver that recognised the mail as forwarded or overrode the policy on its own judgment says so in the record, and that reason is shown beside the disposition: none means the message was delivered anyway, quarantine means it went to spam, and reject means it never arrived. A report full of failures under p=none costs you nothing yet, and the same report under p=reject is mail your customers never received.

Where the report carries DKIM selectors, they are shown beside the signing domain. A selector is the fastest way to identify which platform a source belongs to, because each one signs with its own. The DKIM checker confirms whether the matching key is still published, and the SPF, DKIM and DMARC checker reads all three of your records at once.

A report covers one day at one receiver

A platform that sends your invoices on the first of the month is absent from every report for the other thirty days, and the day it appears failing is the day it matters. Two reports from the same day cover different mail, because Google saw what you sent to Gmail and Microsoft saw what you sent to Outlook. The judgment you need before tightening a policy comes from weeks of them, read together, per source. Reading an aggregate report by hand covers the patterns, and the DMARC setup guide covers the ramp from p=none to p=reject.

What happens to the file you upload

Nothing is stored. The file is parsed in memory to build the page you are reading, and dropped when the response is sent. It is not written to disk, not logged, not attached to an account, and there is no account to attach it to: this page asks for nothing else. If you go on to sign up from the card above, the From domain out of the report is filled into that form so you do not retype it, and it reaches us only if you submit it. Aggregate reports describe other people's sending infrastructure as well as your own, which is exactly why we do not keep the ones strangers paste into a public form.

The other tools