Free DMARC Report Analyzer

What a DMARC Report Is

A DMARC aggregate report (a rua report) is a daily summary that mailbox providers send to the address in your DMARC record's rua= tag. Google, Microsoft, Yahoo and many others send them.

Each report covers one provider and usually 24 hours. It lists:

• Every IP address that sent mail with your domain in the From address
• How many messages each IP sent
• Whether each one passed SPF and DKIM, and whether it passed DMARC

It's the only place you see what really happens to mail sent as your domain, including senders you forgot about and anyone spoofing you.

Why you need a DMARC report reader

The report is an XML file, usually zipped. It's built for machines, so most people publish a DMARC record and never read a single report.

Whether you call it a DMARC analyzer, analyser, XML reader or report viewer, the job is the same: turn the XML into a list of senders and what to fix.

How to Read a DMARC Report

Every aggregate report has the same structure. Read it top to bottom:

1. <report_metadata>: who sent the report (org_name, for example google.com) and the period it covers (date_range, in Unix time).
2. <policy_published>: your DMARC record as the provider saw it: p=, sp=, pct= and the alignment modes adkim and aspf.
3. One <record> per sending source, with three parts:

• <row>: the source_ip, the message count and policy_evaluated, the DMARC result: dkim and spf say pass or fail after alignment, and disposition is what the provider did (none, quarantine, reject).
• <identifiers>: the header_from domain, the one your readers see.
• <auth_results>: the raw SPF and DKIM results, with the domain each one checked.

The part that confuses everyone

A record can show SPF pass in auth_results and SPF fail in policy_evaluated. That's not a contradiction: SPF passed for some other domain (for example amazonses.com), but that domain isn't yours, so it doesn't count for DMARC.

DMARC passes when at least one of policy_evaluated dkim or spf is pass. The analyzer above reads exactly that, so the pass rate it shows is your real DMARC pass rate.

What to Do With Each Failing Source

The analyzer gives every source a verdict. These are the four cases you'll meet:

• Passes with DKIM for your domain. Nothing to do. This is the strongest result: DKIM survives forwarding.
• Passes with SPF only. Works today, but breaks when the mail is forwarded. Add DKIM for your domain in that service.
• Signed with DKIM for another domain. A service you use (a help desk, a CRM) sends as you but signs with its own domain. Set up DKIM for your domain in that service, or a custom return-path for SPF.
• Fails SPF and DKIM. Either a service you never set up, or someone spoofing your domain. Look up who owns the IP before deciding.

To fix a legitimate sender, add it to your SPF record with the SPF record generator, or publish its DKIM key and check it with the DKIM lookup tool.

Moving From p=none to Reject With Your Reports

DMARC rolls out in three steps: none (monitor), quarantine (spam folder), reject (blocked). Most teams get stuck at none because they never read the reports that would let them move on.

A common rule of thumb before moving to quarantine: about 95% of your legitimate mail passes DMARC, and every remaining failure is either fixed or known spoofing.

A safe rollout

1. Stay at p=none and read reports for 2 to 4 weeks.
2. Fix every legitimate sender that fails.
3. Move to p=quarantine with pct=10, then 50, then 100.
4. Move to p=reject once the reports stay clean.

At each step, read the next reports before going further. The DMARC record generator builds the record for each stage.

Reading Reports at Volume

Each mailbox provider sends its own daily report, so the number of reports grows with every provider your readers use.

• Small senders: reading a report when it arrives, in a DMARC report viewer like this one, is enough.
• Higher volume: a DMARC monitoring service collects every report from your rua= address and shows trends over time. This tool reads one report at a time and doesn't store anything.

Forensic (ruf) reports

ruf= asks for a report per failing message. Many large providers don't send them for privacy reasons, so rely on the aggregate reports. For the wider picture, see our email deliverability best practices.