How to get your reports
Aggregate reports only flow if you ask for them. The rua tag in your DMARC record names the mailbox receivers should report to:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Publish that (the DMARC generator builds the record, the DMARC checker verifies it), and within a day or two the major receivers start sending daily XML attachments to that address — Google as .zip, most others as .xml.gz. Save an attachment and drop it here, or open it and paste the XML. The full lifecycle — who sends reports, how often, what each element means — is in the aggregate reports glossary entry.
What the analyzer computes
- Weighted totals. Every
<record>carries a message count, and all percentages here are weighted by it — one record covering 4,000 messages counts 4,000 times more than one covering a single probe. The headline number is the DMARC pass rate: messages where at least one aligned method passed. - Per-source verdicts. Records are grouped by source IP and each source is classified: fully aligned (DKIM and SPF both pass with alignment), DKIM-only, SPF-only, or failing DMARC outright. The classification uses
policy_evaluated— the receiver's aligned verdicts — not the raw authentication results, because DMARC only counts a pass when the domain aligns with your From domain. The difference is exactly what DKIM alignment and SPF alignment are about. - Forwarding detection. Aligned SPF fail plus aligned DKIM pass is the forwarding fingerprint: the forwarder's IP breaks SPF while the signature inside the message survives. The analyzer marks these sources so you don't chase ghosts — forwarded mail passing on DKIM is DMARC working as designed.
- Policy context. For failing mail, the report's
dispositionfield records what actually happened — delivered underp=none, quarantined, or rejected. If you are mid-rollout, this is the section that tells you whether tightening the policy would have cost you legitimate mail. The staged path from monitoring to enforcement is covered in the DMARC policy guide.
Attribution, honestly
A report identifies senders by IP address and by the domains that produced passing authentication — nothing else. This tool refuses to guess further: it will tell you that 203.0.113.10 sent 4,120 messages that passed DKIM for bounce.example-esp.com, because the report says so, but it will not claim to know who operates the IP. Sources with passing auth domains are effectively self-identifying; for sources with no passing authentication at all, attribution needs lookups (PTR, WHOIS) that are outside this page's no-network design — and a failing, unexplainable source is a finding in itself.
From one report to monitoring
One file is one receiver, one day. The workflow that actually fixes deliverability is: collect reports for two weeks, identify every legitimate sending source, get each one to an aligned pass (SPF alignment for mail sent from your own infrastructure, DKIM alignment for ESPs), and only then move p=none toward quarantine and reject. Re-analyze a fresh report after every change. When the failing remainder is only forwarding artifacts and noise you cannot control, enforcement is safe — and your domain stops being spoofable.
Frequently asked questions
Where do DMARC aggregate reports come from?
From the receivers of your mail. When your DMARC record contains a rua tag (rua=mailto:dmarc@yourdomain.com), providers like Google, Microsoft and Yahoo send a daily XML report to that mailbox summarizing every IP that sent mail claiming to be from your domain: message counts, SPF and DKIM alignment results, and what their policy did with failures. The attachment is usually gzip- or zip-compressed XML — this tool accepts all three forms.
Is it safe to upload a report here?
The report is never uploaded. The parser is JavaScript running on this page: file decompression uses your browser's built-in DecompressionStream, the XML is parsed locally, and no network request is made. That matters because aggregate reports enumerate your sending infrastructure and volumes — data worth keeping to yourself. You can verify in your browser's network tab: analyzing triggers no request.
What does 'SPF fail but DKIM pass' mean for a source?
Usually forwarding. When a recipient auto-forwards your mail, the forwarding server's IP is not in your SPF record, so SPF alignment fails — but the DKIM signature travels inside the message and still verifies. DMARC passes on the DKIM result alone, so forwarded mail is delivered normally. The analyzer marks sources matching this signature as likely forwarding; they need no fixing.
A source is failing both SPF and DKIM — am I being spoofed?
Maybe, and that is exactly what DMARC exists to catch — but check the alternative first: a legitimate service you forgot to authenticate (a CRM, a billing system, an office printer) looks identical in a report. The 'authenticated as' column helps: a failing source that passes DKIM for some other domain is usually a real service signing with its own domain instead of yours. A source with no passing authentication at all and a volume you cannot explain is the spoofing candidate.
Why does one report show so few messages?
Each report covers one receiver's view of (typically) one 24-hour window. If most of your audience is on Gmail, the Google report carries most of your volume and the Yahoo report may show a handful of messages. Conclusions need trends: collect reports for a couple of weeks across receivers before deciding a source is dead or a failure pattern is real.
Can this tool tell me who owns a source IP?
No — and neither can the report. Aggregate reports carry the IP and the authentication results, not ownership. The honest attribution path is the auth domains in the report itself: a source passing DKIM for d=sendgrid.net is SendGrid infrastructure regardless of what the IP looks like. For everything else you would need reverse DNS and WHOIS, which are separate lookups this page deliberately does not make — it makes no network requests at all.