What a DMARC aggregate report is
Once your DMARC record includes a rua= tag, every mailbox provider that received mail claiming to be from your domain sends you a daily summary: which IP addresses sent that mail, how many messages each one sent, whether SPF and DKIM passed and aligned, and what the provider did with the mail that failed. The summaries arrive by email as XML files, usually compressed — one report per provider per day, with subjects like Report domain: yourdomain.com Submitter: google.com.
The format (defined in RFC 7489 and carried forward by DMARCbis) was designed for machines, not people. A single report can contain dozens of <record> blocks, each a nest of IPs, counts and verdicts — and you might receive ten of them a day from different providers. This page turns one of those files into something you can actually read.
How to read the table
Each row is one sending IP address, with failing senders sorted first:
- Sender IP — the address that delivered mail claiming to be your domain. Your ESP, your mail server… or an address you've never seen.
- Messages — how many messages the reporting provider received from that IP in the report window.
- Aligned — the share of those messages where SPF or DKIM passed and matched your From domain. This is the number DMARC actually judges.
- SPF / DKIM — the aligned verdict per mechanism: pass means every message passed, partial means some did, fail means none.
- DMARC — the overall result: a message passes DMARC when either aligned mechanism passes.
- Action taken — what the provider did under your policy: delivered, sent to spam, or rejected.
Why SPF says fail here when your mail "passes SPF"
The columns above are aligned results, and this is the single most common confusion in DMARC reports. Mail sent through an email service provider usually passes raw SPF — but it passes as the ESP's own bounce domain, not yours. Since that domain doesn't match your From address, it doesn't align, and the report records SPF fail for DMARC purposes. That's normal and healthy as long as DKIM, signed with your own domain, carries the pass. A sender showing DKIM pass and SPF fail is usually fine; a sender showing both as fail is the one to investigate. Why SPF and DKIM fail goes deeper.
What to do about senders that never authenticate
A sender with zero alignment is one of two things: a service you forgot to authenticate — a billing tool, a CRM, a newsletter platform someone signed up for — or someone spoofing your domain. One file can't tell you which; the IP alone rarely can either. The working method: check whether the volume and timing match a service your business uses, look up the IP's owner, and fix the legitimate ones by adding them to SPF or setting up their DKIM signing. What's left over is the reason your policy should eventually say p=reject. Moving from p=none to p=reject covers that path.
A worked example
Here's what this analyzer shows for a typical small report — from Google, covering one day of mail for yourdomain.com (the same report the sample button loads):
Most mail aligned, but something needs attention
94.2% aligned| Sender IP | Messages | Aligned | SPF | DKIM | DMARC | Action taken |
|---|---|---|---|---|---|---|
185.234.219.85 | 3 | 0% | fail | fail | fail | delivered |
209.85.220.41 | 42 | 100% | pass | pass | pass | delivered |
149.72.123.24 | 7 | 100% | fail | pass | pass | delivered |
Three stories in three rows. The Google IP (209.85.220.41) is the domain's own outbound mail: everything passes. The SendGrid IP (149.72.123.24) shows the classic ESP pattern — SPF fails alignment, DKIM carries the pass, all fine. And 185.234.219.85 sent three messages as this domain that passed nothing — under p=none, all three were delivered anyway. That last row is why the policy eventually needs to say reject.
Your report never leaves your browser
Everything on this page — decompressing the attachment, parsing the XML, building the table — happens locally in your browser. There's no upload, no server, no account. DMARC reports contain your sending infrastructure and your mail volumes; that's not something you should paste into a random website that stores it. If you want to verify: open your browser's network tab and analyze a report — no request is made.
From one file to a feed
Reading one report is a good way to understand the format. Reading ten a day, every day, from six providers, is not a job for a human — and the interesting signal is the change: the sender that appeared yesterday, the alignment that broke after a DNS edit, the spoof spike that started on Tuesday. That's what DMARC monitoring automates: point rua= at us once, and every report lands parsed, senders identified, with threat analysis on every IP and an alert when something needs you. How DMARC reporting works explains the pipeline.
Common questions
Why am I getting DMARC report emails?
Because your domain's DMARC record has a rua= tag pointing at your address. Every provider that received mail claiming to be from your domain sends a daily XML summary there. The reports are a feature, not a problem — they're the only visibility you have into who sends as your domain.
Is my report uploaded anywhere?
No. The file is read, decompressed and parsed entirely in your browser and never leaves your machine.
Who sends these reports?
Any provider that received mail for your domain and honours rua=: google.com, Microsoft (enterprise.protection.outlook.com), Yahoo, Amazon SES, Mimecast and many smaller ones. One per provider per day is typical.
What's the difference between aggregate and forensic reports?
Aggregate (rua) reports are daily summaries of counts and results per IP, with no message content — that's what this tool reads. Forensic (ruf) reports are per-message failure copies, which most providers stopped sending for privacy reasons.
The report says a message failed but was still delivered. Why?
Your policy is p=none — monitor only. The provider reports the failure but takes no action. Failing mail starts being quarantined or rejected only when your policy asks for it.