Every domain with a DMARC record that includes a rua address receives aggregate reports, and most of them go unread. They arrive as compressed XML from Google, Microsoft, Yahoo and dozens of smaller receivers, once a day each, and a single file can list fifty sending sources. The information inside is the only direct evidence of who is sending mail as your domain and whether it authenticates. This tool turns those files into something you can act on.
What the analyzer does
Select one or more report attachments, or paste the XML of a single report. The tool decompresses .gz and .zip files in your browser, parses each <feedback> document, and merges every record into one view:
- Pass rate: the share of all messages that passed DMARC, meaning SPF or DKIM passed with a domain aligned to the From header.
- Four buckets: aligned on both, DKIM only, SPF only, and unauthenticated.
- Every sending source by IP address, with message counts, the percentage that passed SPF and DKIM alignment, the verdict, what the receiver did with failures (none, quarantine or reject), and the domain each source signed with.
- Reverse DNS for the twelve largest IPv4 sources, resolved through public DNS so that
mail-sor-f41.google.comoro1.ptr1234.sendgrid.nettells you which service is behind the number. - A prioritised check list: whether your published policy is still monitoring, which unauthenticated sources carry real volume, and whether the DKIM-only traffic looks like forwarding or like a service missing a custom Return-Path.
Nothing is uploaded. The XML stays in the page, and the only network requests are DNS lookups for the source IPs.
How to read the sending sources table
Each row is one IP address that sent mail with your domain in the From header during the report period. The columns that matter:
| Column | What it tells you |
|---|---|
| SPF aligned | The share of messages whose Return-Path domain passed SPF and matched the From domain |
| DKIM aligned | The share whose DKIM signature validated and whose d= domain matched the From domain |
| Verdict | Aligned (either or both passed), DKIM only, SPF only, mixed, or unauthenticated |
| Failures disposed | How receivers treated the failing messages under your published policy |
| Signed as | The d= domain of any passing DKIM signature, which exposes services signing with their own domain instead of yours |
A source that signs as crm-vendor.example while sending From your domain is the most common failure. The fix is to turn on DKIM for your own domain in that service’s settings, which publishes a key under selector._domainkey.yourdomain.com and makes the signature align. Check the key afterwards with the DKIM checker.
The path from monitoring to reject
The reports exist to make enforcement safe. The sequence that works:
- Publish
p=nonewith aruaaddress using the DMARC generator and wait two weeks for reports to accumulate. - Analyze the reports here. List every source. For each one you recognise, make sure it passes on DKIM with your domain and, where possible, on SPF with a custom Return-Path. Our email authentication guide covers both.
- Explain every remaining failure. Small DKIM-only sources are forwarders and are fine. Unauthenticated sources with real volume are either an unconfigured tool or abuse.
- Move to
p=quarantinewhen the pass rate is above 98% and stays there for two more weeks of reports. - Move to
p=reject. Keep reading reports afterwards: the next tool someone connects without authentication will show up here before customers notice their mail is missing.
Reading the four buckets
Aligned on both is the goal for every service you control. DKIM only at low volume from many IPs is forwarding and needs no action; at high volume from one IP it means a service without a custom bounce domain, which still passes DMARC but is fragile. SPF only means mail that is not signed, which fails as soon as it is forwarded or your SPF record exceeds ten lookups; turn on DKIM at that source. Unauthenticated is the bucket to empty, one source at a time.
The disposition column shows the policy in action. While you are at p=none, every failure shows “none” because receivers delivered it anyway. Once you move to quarantine or reject, the same column tells you how much mail you are now sending to spam or refusing, which is the number to watch during a rollout.
Common patterns and what they mean
- One big aligned source and a long tail of tiny DKIM-only sources: healthy. The tail is forwarding.
- A large source signing as another domain: a connected tool with default authentication. Fix it before enforcing.
- Unauthenticated traffic from residential-looking hostnames: spoofing or a compromised machine somewhere. Enforcement stops it.
- Your own mail server passing SPF but not DKIM: install a signing key on the server. The DKIM key generator produces the pair.
- Everything fails after a migration: the new platform’s DKIM is not set up on your domain yet, or the SPF include changed. The ESP migration playbook lists the records to update.
Limits of aggregate reports
Reports arrive a day late, carry no subject lines or recipients, and come only from receivers that choose to send them. Gmail, Outlook.com, Yahoo and most large providers do; many corporate mail systems do not. Use them to see the authentication picture, not to measure inbox placement. For the complete view of your domain, run the sender reputation checker, and for a single suspicious message, the header analyzer shows the verdicts one receiver reached.