Once you publish a DMARC record with a rua= tag, the mailbox providers start mailing you back. Within a day or two, gzip-compressed XML files begin arriving from Google, Microsoft, Yahoo, Comcast, and a long tail of providers you have never heard of. Each one describes how your domain authenticated across thousands of messages. This is the most useful data you will ever get about your own email, and almost nobody reads it, because by hand it is unreadable.
The raw problem: reports nobody can read
A DMARC aggregate report is an XML document, usually gzipped, sometimes wrapped in a ZIP. A medium-sized organisation publishing rua=mailto:you@yourdomain.com will receive dozens of these every single day, one batch per provider per reporting window. Open one in a text editor and you get nested tags describing source IP addresses, message counts, and authentication results. Open thirty of them and you have given up.
The reports are also inconsistent. Google sends one large daily file. Some providers send tiny ones. A few send malformed XML that breaks naive parsers. The same sending source shows up under three different provider reports with three different message counts, and you are expected to add them together yourself. The information you actually want, which is "is my legitimate mail passing and is anyone spoofing me", is buried under that mechanical noise.
p=none. The records monitor, the reports arrive, and then they sit in an inbox unread. Without parsing those reports you cannot see who sends as you, so you never gain the confidence to enforce. The reports are the whole point, and they are the part everyone skips.
What is actually inside an aggregate report
An aggregate report is not message content. It contains no subject lines and no bodies. It is a statistical summary of authentication, grouped by sending source. For each distinct source the report records a specific set of facts.
That last column matters more than people realise. A message can have an SPF pass and still fail DMARC, because SPF passed for the wrong domain. DMARC adds alignment: the domain that SPF or DKIM authenticated must match the domain a human sees in the From field. The aggregate report tells you, source by source, whether your mail was both authenticated and aligned, which is exactly the question that decides whether you can safely enforce. For a deeper look at how that mechanism works, see our DMARC product page.
How DMARC Engine ingests and parses them
Point your rua= tag at a reporting address we manage for your domain, and the pipeline starts on its own. There is nothing to download and no XML to touch.
Decompress, validate, parse
Every inbound report is decompressed (gzip or ZIP), validated against the DMARC aggregate schema, and parsed into structured rows. Malformed files that would crash a hand-rolled parser are quarantined and logged rather than silently dropped, so a single broken file from one provider never costs you a day of data.
De-duplicate and reconcile
Providers overlap. The same sending source appears in reports from Google and Yahoo and a regional ISP, each counting the messages it received. We reconcile those by source, by reporting window, and by provider, so you see one honest total per source instead of the same mail counted several times. Reports that arrive twice, which happens, are dropped on a content hash rather than added again.
Resolve and enrich
A raw IP address means nothing to most people. We resolve each sending source to a recognised service where we can: your own mail servers, Google Workspace, Microsoft 365, a marketing platform, a CRM, a ticketing system, a payroll provider. Anything we cannot map to a known service is flagged as unknown, which is precisely where your attention belongs.
What the raw XML turns into
After ingestion you stop looking at files and start looking at answers. The same data, parsed and reconciled, becomes a small number of views that map directly to decisions.
Pass-rate trends over time
A single line, per domain, showing the percentage of your mail that passed DMARC each day. When you onboard a new sending service or fix a misconfigured one, the line moves, and you can see the effect within a day. A sudden dip is a signal that something changed: a vendor rotated infrastructure, a DKIM key expired, or someone started sending without telling you.
Every sending source, named
A list of every source that sent mail claiming to be your domain, with its message volume, its pass rate, and its identity. Legitimate services sit at the top with high pass rates. Below them sits the interesting part: sources we could not identify, and sources failing authentication. This list is usually the moment an organisation discovers a forgotten application still sending invoices, or a department that signed up to a tool nobody told IT about.
Alignment breakdowns
For each source we split the result into SPF alignment and DKIM alignment, separately. This matters because the two behave differently. SPF does not survive forwarding, so a source can pass SPF directly and fail it once a mailing list or a forwarding rule re-sends the message. DKIM, being a signature on the message itself, usually survives. Seeing the split tells you whether a source is safe to rely on for alignment or whether you need to fix its DKIM signing before you tighten policy.
Threat detection
Sources that send as you, fail authentication, and resolve to no service you use are the spoofing and phishing attempts. Picture a fake invoice going out from accounts@yourcompany.com off a server in a country you do not operate in: that source appears in the reports with a failing SPF result, a failing DKIM result, and a disposition that depends entirely on your policy. At p=none the spoof was delivered. We surface these as threats so you can both see the abuse and understand what your policy is, or is not, doing about it.
Multi-domain roll-up
Free and entry-level tools tend to limit you to one domain, or charge steeply per domain, because the cross-domain view is the valuable one. Most organisations do not own one domain. They own the primary brand, a few country variants, a couple of acquired companies, a parked defensive domain or two, and a dedicated sending subdomain for marketing.
DMARC Engine rolls every domain into one view. You see aggregate pass rates across the whole estate, a single list of every sending source touching any of your domains, and which domains are still at p=none versus which have reached p=quarantine or p=reject. A domain you forgot you owned, sitting wide open with no DMARC record, is exactly the one an attacker will choose, and the roll-up is where you spot it.
| View | Single-domain tools | DMARC Engine roll-up |
|---|---|---|
| Pass rate | Per domain only | Per domain and across the estate |
| Sending sources | One list per domain | One consolidated, de-duplicated list |
| Policy status | Checked one domain at a time | Every domain ranked by enforcement stage |
| Unknown sources | Easy to miss across domains | Surfaced wherever they appear |
Alerts that reach you before the next report does
Reading a dashboard once a week is better than nothing, but the useful changes happen between visits. DMARC Engine watches the parsed data and tells you when something moves, by email, Slack, or webhook into your own systems.
- A pass rate drops. A vendor changed sending infrastructure or a DKIM key expired, and your legitimate mail started failing. You hear about it the same day, not at the end of the month.
- A new unauthenticated source appears. A server you have never seen begins sending as your domain and failing authentication. That is either a new internal tool nobody registered or someone spoofing you, and both need a look.
- A policy regresses. Someone edits the DNS and your
p=rejectquietly becomesp=noneagain, or your record disappears entirely. Policy drift is common during DNS migrations, and an alert catches it before the protection is gone for weeks.
Each alert links straight back to the source and the data behind it, so the message is not just "something changed" but "this specific source, this much volume, this result".
How analytics carries you to enforcement
Moving from monitoring to blocking is a sequence, and every step depends on reading these reports. You cannot do it blind without eventually blocking your own legitimate mail.
| Stage | Policy | What the reports tell you |
|---|---|---|
| Discover | p=none | Every source sending as you, and which ones fail |
| Authenticate | p=none | Whether each legitimate source now passes and aligns |
| Quarantine | p=quarantine | That no real mail is being sent to spam by mistake |
| Reject | p=reject | That only spoofing sources are now being refused |
The discipline is simple to state and hard to do by hand: do not raise the policy until the reports show every legitimate source passing. Our monitoring guide walks through that ramp in detail, and the audit walkthrough shows how to read a first batch of reports and turn it into a list of senders to fix. The analytics surface exists to make each of those judgements something you can see rather than guess.
p=reject is evidence, not nerve. When the trend line sits at full pass for your real senders and the only failures left are sources you do not recognise, raising the policy stops being a gamble. That confidence comes entirely from reading the aggregate reports.A note on forensic (ruf) reports
DMARC defines a second report type, the forensic or failure report, requested with the ruf= tag. Unlike aggregate reports, a forensic report is generated per failing message and can include header detail and sometimes redacted content, which makes it useful for investigating a specific spoofing campaign.
In practice forensic reports are rare. Most large mailbox providers do not send them at all, largely for privacy reasons, since the reports can contain personal data about real recipients. Where providers do send them, the data is usually redacted. Treat forensic reports as an occasional bonus for incident investigation, never as your primary signal. The aggregate reports, sent reliably by nearly every provider, are where the day-to-day value lives.
What the analytics surface shows at a glance
Turning your reports on
If you already publish a rua= tag, repointing it takes one DNS edit and reports start flowing within a day. If you have not published DMARC yet, start by running a free scan to see your current record, your SPF lookup count, and your DKIM selectors, then publish a monitoring record and let the reports accumulate. Monitoring is £19 per month on the introductory rate, and a one-time enforcement engagement takes you all the way to p=reject; the details sit on our pricing section. When you are ready to see your own mail clearly, create an account and connect your first domain.
Aggregate reports are not paperwork. They are the only honest record of who sends mail as your organisation and whether it authenticates, and the reason most domains never reach enforcement is simply that nobody reads them. DMARC Engine reads them for you, reconciles the duplicates, names the senders, watches for drops and spoofing, and gives you the evidence to tighten policy without breaking your own mail. That is the difference between publishing DMARC and actually using it.
See where your domain stands today
Run a free DMARC scan, then let us take you to enforced p=reject with no email outage.