Email authentication tool

DMARC Report Parser

Upload a DMARC aggregate report — XML, .gz, or .zip — and see which senders are passing, which are failing, and exactly what to do next. No XML to read.

What this tool does

A DMARC aggregate report is useful, but it is not written for a human trying to make an enforcement decision. It is an XML file full of source IPs, counts, DKIM domains, SPF domains, and receiver dispositions. This parser turns that report into the operational view you actually need: which named senders were seen, how much mail each sender sent, whether the receiver delivered that mail, and what action to take next.

The important part is the layer above XML. A raw record might say an IP sent through sendgrid.net with DKIM failure and quarantine disposition. That is not just a row. It is a SendGrid setup problem you can assign to the team that owns the marketing sender. A record might show a Google Workspace DKIM pass with disposition none. That sender is probably ready. A record might show a source IP with no known catalog match and failing volume. That is not something to ignore; it is a candidate for vendor discovery or spoofing review.

This tool names the senders it recognizes from authentication evidence and gives each one a confidence level. It does not claim to identify every source on the internet. Unknown senders stay visible as unknown senders by IP, which is the right behavior when you are preparing for quarantine or reject.

How to get your DMARC reports

Reports arrive only after your DMARC record includes a rua= address. A simple monitoring record looks like v=DMARC1; p=none; rua=mailto:reports@example.com. Mailbox providers that process mail from your domain can send daily aggregate reports to that address. Some providers send plain XML. Many compress the XML as .gz. Some send .zip. This parser accepts all three forms.

If you do not have reports yet, use the DMARC generator to create a monitoring record with a reporting mailbox, then use the DMARC checker to confirm DNS published the value you intended. Give mailbox providers time to observe mail and send reports. Once reports arrive, download one attachment and drop it here.

Use a mailbox or report processor that you control. Aggregate reports can include source IPs and domains that reveal parts of your email operation. Treat them as operational security data, not marketing collateral.

Reading the results

Named sender is the service this parser can infer from DKIM, SPF, envelope-from, or header-from evidence. Passing DKIM evidence is preferred, then passing SPF evidence, then non-passing authentication domains, then envelope and header domains. A known service with passing authentication gets higher confidence than a known service found only in failing evidence.

Aligned means the receiver delivered the message, shown in the report as disposition none. That definition is deliberate. It matches the report pass rate and avoids the common mistake of averaging raw SPF and DKIM results. Raw DKIM and SPF still matter as evidence, but the headline pass/fail split follows the receiver disposition. Failing means the receiver applied quarantine or reject.

Confidence tells you how strong the attribution is. High confidence means a known service authenticated. Medium means the service was recognized but the matching evidence did not pass. Low means the sender is unknown and grouped by source IP. Low confidence is not a cosmetic problem. A high-volume unknown sender is one of the main reasons to stay in monitoring mode until you know whether that traffic is legitimate.

Source IPs are still available under the disclosure on each sender. They are secondary because IPs alone rarely tell the owner what to fix. Names drive action. IPs support investigation.

From report to enforcement

The normal enforcement path is monitoring, then quarantine, then reject. Monitoring with p=none gives you visibility without asking receivers to block mail. During that phase, your job is to identify every legitimate sender, make sure each one passes through an aligned DKIM signature or aligned SPF return path, and watch for unknown traffic that should not be allowed to use your domain.

When known senders are aligned and unknown failing volume is understood, move to p=quarantine. Quarantine is a pressure test. It tells receivers to treat failing mail suspiciously while giving you one more stage to catch operational mistakes. After quarantine is clean, move toward p=reject. Reject is the goal for blocking direct domain spoofing, but it should be the result of evidence, not hope.

The next-action list is intentionally conservative. If the report shows unknown failing sources, it tells you to identify them before raising policy. If a known sender fails under an enforcing policy, it calls out the risk that legitimate mail may be getting blocked.

Common things reports reveal

The first surprise is usually forgotten SaaS. A billing platform, CRM, survey tool, helpdesk, or old marketing account may still send as your domain. The second surprise is a vendor that can pass SPF but never set up aligned DKIM. That can work until forwarding or a different bounce path breaks SPF alignment. DKIM is usually the better long-term fix for third-party mail.

Forwarding artifacts also appear in aggregate reports. A forwarded message may keep your DKIM signature and fail SPF because the forwarding server is now the connecting IP. That is one reason the tool separates raw SPF and DKIM evidence from the disposition-based aligned count. You need to know both what authenticated and what the receiver did.

Some reports reveal outright spoofing: unknown IPs, no aligned authentication, and failing dispositions. That is the mail you eventually want quarantine or reject to stop. The safe move is to separate spoofing from legitimate but misconfigured mail before increasing policy.

How this differs from the DMARC checker

The DMARC checker looks up the DNS record at _dmarc and tells you whether the published policy is valid. This parser reads aggregate reports generated after mail flows. Use the checker to validate what you told receivers. Use the parser to understand what receivers saw.

Parsed in your browser

The file is read by your browser tab and the result is kept in React state. There is no report history and no local storage. Telemetry, when sent, is counts-only and does not include report content, names, domains, IPs, filenames, report IDs, or dates.