# DMARC report viewer: read aggregate reports without a paid dashboard > Open the DMARC aggregate report files your mailbox providers send and see which sending IPs pass or fail, why each failing source fails (SPF or DKIM failed, or passed for another domain), and what to fix before you tighten your policy. Runs in your browser with no network requests. By MailSetupCheck. Updated 16 October 2026. Canonical URL: https://mailsetupcheck.com/dmarc-report-viewer/ > **Interactive viewer.** On the HTML version of this page (https://mailsetupcheck.com/dmarc-report-viewer/), open or paste one or more DMARC aggregate report files (the XML your mailbox providers send to your `rua=` address). The page, running only in your browser, totals the messages, groups them by sending IP address, shows how many passed or failed DMARC, explains for each failing source whether SPF or DKIM failed or only failed to align with your From domain, and gives a short fix list in two tiers (fix first, worth fixing) plus what already looks right. Nothing is uploaded and no network request is made. ## 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](https://www.rfc-editor.org/rfc/rfc9990) (earlier [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489) 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](/dmarc-p-none-to-reject/) has the order and the Gmail and Yahoo [sender requirements](/gmail-yahoo-bulk-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](/email-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)](https://www.rfc-editor.org/rfc/rfc9989), [RFC 9990 (DMARC aggregate reporting)](https://www.rfc-editor.org/rfc/rfc9990), [RFC 7208 (SPF)](https://www.rfc-editor.org/rfc/rfc7208), [RFC 6376 (DKIM)](https://www.rfc-editor.org/rfc/rfc6376), [Google's sender guidelines](https://support.google.com/mail/answer/81126).