What this analysis does
Upload or paste a DMARC aggregate report. Mailybox recognizes current RFC 9990 reporting metadata such as tree-walk policy discovery as well as useful legacy report fields, then summarizes total volume, aligned authentication outcomes, policy disposition, failure reasons and the highest-volume source IPs.
Aggregate reports are the only routine feedback showing which sources send as your domain and how receivers evaluated them. They arrive as compressed XML on a daily cadence from many receivers, which is why the data that should drive enforcement decisions is so often left unread.
Group by source before reading anything else
A report is a set of rows, each covering messages that shared a source address and evaluation outcome. The useful first step is grouping by source and calculating an aligned pass rate for each, because that immediately separates well-configured senders from those that need attention.
Volume then determines priority. A source responsible for a large share of traffic with a low alignment rate is the change that unblocks enforcement. A source sending a handful of messages with the same failure rate is a lower priority even though the percentage looks identical.
- Group by source address and evaluate alignment per source.
- Weight findings by volume, not by failure percentage alone.
- Separate SPF-only, DKIM-only and fully aligned sources.
Alignment and authentication are reported separately
Each row records SPF and DKIM results together with their alignment status. A source can authenticate successfully and still fail DMARC because neither identity aligned with the visible From domain. Reading only the authentication columns hides that entirely.
A source passing through one path only is worth flagging even when DMARC succeeds. If the sole path is aligned SPF, forwarded copies of that mail will fail, and if the sole path is DKIM, any content modification in transit removes the last passing path.
Test alignment for a specific sourceRead the aggregate reporting guide
Use the data to sequence enforcement
The path from monitoring to rejection should be driven by these reports rather than by a calendar. Attribute every meaningful source, fix alignment for the legitimate ones, then increase policy strength in stages while watching for sources that appear only at longer intervals.
Percentage-based rollout is the safety mechanism, applying the policy to a fraction of messages so unexpected failures surface at limited scale. Reports covering several weeks are what reveal quarterly and annual senders that a short observation window would miss entirely.
Example: a high-volume source with one fragile path
Evidence supplied
A report where one source accounts for most traffic, passing DMARC through aligned SPF only.
How to read the result
The analysis reports that source as passing but single-path, and identifies forwarded mail as the case where it will fail. Adding aligned DKIM signing for that platform is the change that makes the result durable.
Known limits
- Aggregate reports summarize counts and outcomes; they contain no message content or recipient detail.
- Not every receiver sends reports, so coverage is partial.
- Reports describe a past window and lag current configuration by at least a day.
Common questions
Why do reports show sources we do not recognize?
They may be forwarders, legitimate services nobody documented, or genuine spoofing. Attribution is required before the source can be dismissed.
Do these reports contain message content?
No. Aggregate reports carry counts, source addresses and evaluation outcomes only.
How long should reports be collected before enforcing?
Long enough to include infrequent senders. Several weeks is a common minimum, and a full quarter is safer for organizations with periodic billing cycles.