DMARC report viewer: read aggregate reports without a paid dashboard

What an aggregate report is

When your domain publishes a DMARC record with a rua= address, mailbox providers that check mail claiming to be from your domain send you a daily XML summary. It lists, per sending IP address, how many messages arrived, what SPF and DKIM concluded, and whether DMARC passed. It contains no message bodies or subject lines. The format is defined in RFC 9990 (earlier RFC 7489 appendix C).

Raw XML is hard to read, and a busy domain gets dozens of files a day. Paid services turn them into dashboards. For a small domain, opening a few files is often enough to find the one or two senders that are misconfigured.

How to read the result

• Passed DMARC. A message passes when SPF or DKIM passes and the domain it verified matches the visible From domain (alignment). One is enough.
• Failed, "SPF passed but for a different domain". Very common with email services: SPF passed for the service's own bounce domain, not yours. Set up a custom return-path or "authenticated domain" in the service.
• Failed, "DKIM passed but the signing domain is not the From domain". The service signs with its own key. Add your own DKIM record for that service.
• Failed from an IP you do not recognize. Either someone is spoofing your domain, or the mail was forwarded. Forwarding often breaks SPF, and mailing lists change messages and break DKIM; these are the cases p=quarantine and p=reject are designed for, and receivers may mark them with a reason such as forwarded or mailing_list.
• Disposition. none means delivered normally, quarantine means spam folder, reject means refused. At p=none the disposition is always none, even for failures.

Before you tighten the policy

1. Read at least two weeks of reports, so monthly mailers (invoices, newsletters) appear.
2. Fix every source you recognize until it passes on its own domain, preferably through both SPF and DKIM.
3. Move to p=quarantine with pct= set low, raise it step by step, then repeat for p=reject. The DMARC rollout guide has the order and the Gmail and Yahoo sender requirements explain why bulk senders need this anyway.

What it cannot tell you

• It reads only the files you open. It does not fetch DNS, so it cannot say whether your records are right today; use the DNS checker for that, and the header analyzer to see how one real message was judged.
• It cannot tell a legitimate service from a spoofer. It lists IP addresses and counts; deciding who owns an IP (a reverse DNS lookup, or the service's published sending ranges) is up to you.
• Each provider reports only what it saw, so counts are a sample of your mail, not a total. A provider with no report that day sent none.
• Reports can be wrong or forged, and large ones are cut off at 20,000 rows. Treat them as evidence, not proof.
• Forensic (ruf=) reports are a different format and are not read here.

File handling

The viewer reads each file as plain text in the page, or decompresses a .gz file with the browser's own decompressor. Nothing is uploaded. XML with a DOCTYPE declaration is refused, files over 5 MB are refused, and only the five standard XML entities are expanded.

Sources: RFC 9989 (DMARC), RFC 9990 (DMARC aggregate reporting), RFC 7208 (SPF), RFC 6376 (DKIM), Google's sender guidelines.

Also available as Markdown.