Your DMARC Reports Are Screaming Quietly: A Monthly Triage for the Sender You Never Approved

Somewhere in your DNS, there is a line that says rua=mailto:[dmarc](https://en.wikipedia.org/wiki/DMARC)@yourdomain.co.uk. It looks tidy. It looks responsible. And for most UK organisations it is the email equivalent of installing a burglar alarm and then bricking up the window that shows the camera feed.

The reports are arriving. They arrive every day, from Gmail, from Microsoft, from a scattering of mailbox providers you have never heard of and a few security appliances that decided to join in. They are gzipped XML attachments, they are dull, and they are almost never opened. Which is a shame, because a rua report is one of the few pieces of email infrastructure that tells you the truth about who is sending as you — without asking the sender.

What a rua report actually contains

Aggregate reports are not samples of messages. They are counts. For each reporting receiver and each day, you get a tidy little ledger: the source IP address, how many messages it sent, which envelope sender it used, which header From domain it claimed, whether SPF passed, whether DKIM passed, which DKIM domain signed it, and what the receiver did with it under your published policy.

That is it. No subject lines, no bodies, no attachments. If you were hoping for a forensic dump of the scam email that spoofed your finance director, this is not it. Aggregate reports are telemetry, not evidence. They tell you that an IP in a country you cannot place sent forty messages claiming to be from yourdomain.co.uk, that both authentication checks failed, and that the receiver delivered them anyway because your policy is still p=none.

That single line is worth more than a hundred phishing awareness posters.

Why the mailbox fills and nobody looks

The format is the first barrier. XML was designed for machines, and it shows. A month of reports from a mid-sized domain can run to thousands of files, each with a naming convention that looks like a randomised CAPTCHA. The second barrier is volume: once you start forwarding reports to a shared mailbox, it becomes a second spam folder, except this one contains genuinely useful information buried under genuinely tedious information.

The third barrier is psychological. Most teams set up DMARC once, ticked the compliance box, and moved on. The record exists. The policy is published. Job done. But a p=none record with an unread rua mailbox is not monitoring. It is a suggestion box nailed shut.

Filter first, read second

You do not need to read every report. You need a pipeline. The practical shape is: collect, decompress, parse, store, then aggregate. There are commercial dashboards that will do this for you, and there are open-source parsers that will happily churn through a mailbox and stuff the results into a database. Either is fine. The point is to stop looking at individual XML files and start looking at grouped rows.

Group by source IP, then by the header From domain, then by the DKIM signing domain. Sort by volume, then by authentication failure. What you are looking for is not the noisiest sender — it is the sender you cannot explain.

A legitimate marketing platform will produce a lot of rows. That is expected. A single IP in an unfamiliar netblock, sending a modest number of messages with a header From of your domain and a DKIM signature from a domain you have never registered, is not expected. That is the row you want.

The surprises live in the subdomains

If your DMARC record uses a relaxed alignment mode and your DNS has a wildcard, every subdomain under your domain is potentially a sender. That includes the staging environment someone spun up in 2022, the SaaS ticketing tool that generates its own tenant subdomain, the survey platform that sends password resets as [email protected], and the forgotten proof-of-concept that still has an A record.

Aggregate reports surface these because the header From domain is reported verbatim. A subdomain you do not recognise, sending mail you did not authorise, is either a misconfiguration or an impersonation. Either way, you want to know before a customer does.

The third parties you forgot you had

The other rich vein is third-party senders. CRM platforms, payroll providers, ticketing systems, the marketing agency you parted ways with in 2023, the events tool that still has an admin login for a former employee. These senders often authenticate with their own DKIM domain while putting your domain in the header From. Under relaxed alignment that can pass. Under strict alignment it will fail — and the report will tell you which.

That is not necessarily an attack. It is often just a sender you have not inventoried. But an uninventoried sender is an unmanaged sender, and an unmanaged sender is exactly what an attacker wants to blend in with.

A monthly triage routine that actually happens

Block forty-five minutes on the first Tuesday of each month. That is the whole ritual. Then:

1. Export the last thirty days of aggregate data, or open your parser's dashboard filtered to the same window.
2. Group by source IP and authentication domain. Ignore anything you can match to a known sender in your inventory.
3. List every new or unexplained source. For each one, note the volume, the header From domain, the DKIM domain and the SPF result.
4. Check the legitimate ones against DNS. Does the SPF include still exist? Is the DKIM key current? Is the sender aligned with your policy?
5. Decide what to do with the rest: fix the DNS, retire the subdomain, add a filter rule, or move your policy from p=none to p=quarantine and eventually p=reject.
6. Write it down. A simple spreadsheet with sender, purpose, owner and last reviewed date is enough. Future you will be grateful.

From checkbox to early-warning system

The UK's public-sector push towards stronger email authentication, and the bulk-sender rules that major mailbox providers have enforced since 2024, have made DMARC records commonplace. That is progress. But a published record is not the same as a monitored one. The rua mailbox is where the useful, awkward, specific truth lives: the subdomain nobody owns, the agency nobody sacked properly, the IP nobody can explain.

Open the reports. Filter them down. Read the handful of rows that do not fit. It is not glamorous work, but it is the difference between a compliance tick and an early-warning system that earns its keep.