Every server that sent mail claiming to be your domain yesterday may already be listed in a report addressed to you. Most owners have never opened one.
If your domain has a DMARC record with a reporting address — the "rua" tag — the world's large mail receivers already send you reports, typically one per receiver per day. Each report lists every server that sent mail claiming to be your domain: the volumes, the IP addresses, and whether each source passed the SPF and DKIM checks. You do not have to buy anything or sign up anywhere to receive them. They arrive because you asked for them, possibly years ago, in a DNS record somebody set up and forgot.
And then almost nobody reads them, which is understandable rather than negligent. The reports arrive as zipped XML attachments, built for machines, not people. Opening one in a mail client shows you an attachment with a fifty-character filename; opening the file itself shows you nested tags and IP addresses. The information inside is genuinely useful — it answers a question no other tool answers, namely "who is out there sending email in my name?" — but the format guarantees that the answer sits unread in a mailbox.
What is in a DMARC aggregate report?
A DMARC aggregate report is a daily summary from one mail receiver, listing every server that sent mail claiming to be your domain: how many messages came from each source, from which IP addresses, and whether each source passed the SPF and DKIM checks. It is not a copy of the messages themselves — it is a count of who sent, from where, and whether the mail authenticated.
That distinction matters for expectations. An aggregate report will tell you that a particular server sent forty messages as your domain on Tuesday and that none of them passed authentication. It will not show you the messages, the subject lines or the recipients. It is a census, not a wiretap — which is also why receiving and reading these reports raises none of the privacy questions that reading actual mail would.
One practical caveat if you ever parse them yourself: real-world reports deviate from the specification in small ways. Different receivers compress the files differently, name them differently, and occasionally omit or rearrange fields the specification says should be there. Any tool that reads them has to be tolerant of this, and a strict parser will choke on perfectly genuine reports from major providers.
Are unknown senders in a DMARC report a sign of attack?
Usually not. In a first report, most senders you do not recognise turn out to be your own services: the invoicing system, the newsletter tool, the booking platform, a CRM — legitimate senders that nobody ever registered in SPF or DKIM. Finding and authorising them is the main early win, because a stricter policy would otherwise start rejecting your own invoices.
This happens to almost every business, because sending services accumulate. The accounting package was set up in one year, the newsletter tool in another, the booking system by an agency that has since been replaced. Each one sends mail "from" your domain, and each one needed to be listed in your SPF record or given a DKIM key at the time — a step that is easy to skip because the mail usually gets delivered anyway while your policy is permissive. The DMARC report is often the first complete inventory the business has ever seen of its own senders.
So the correct first reaction to a report full of unfamiliar sources is curiosity, not alarm. Work through them one by one: an IP range that belongs to your newsletter provider is your newsletter, and the fix is to authorise it properly — the SPF and DKIM setup guide covers how. Only what remains after that exercise deserves suspicion.
What does actual abuse look like in DMARC reports?
Sustained volume from sources that fail both SPF and DKIM, often sent from networks with no relation to your business — a hosting range you have never used, in a country you have never traded with, sending mail as your domain day after day. That pattern is someone borrowing your domain name for spam or phishing, and it is exactly what the reports were designed to expose.
Note the shape of the signal: it is the combination that matters. Failing both checks, at volume, repeatedly, from somewhere unconnected to you. Any single element on its own is weak evidence — plenty of legitimate mail fails one check for boring reasons, as the next section explains. But a server that fails everything and keeps sending has no innocent explanation, because a genuine sender of yours would be failing to reach inboxes and someone would have complained by now.
When you see this pattern, the response is not to chase the sending network — it is to tighten your policy so that receiving servers refuse the mail. That is the lever DMARC gives you: you cannot stop anyone from typing your domain into a From field, but you can instruct the world's mailbox providers not to accept it when they do.
Why do some legitimate emails fail SPF in the reports?
Because forwarding breaks SPF by design. When a message is auto-forwarded, or passes through a mailing list, it arrives at the final receiver from the forwarder's server rather than yours, so the SPF check fails even though the message is genuine. Scattered single failures in a report are normal life, not an attack.
This is worth internalising before you read your first report, because otherwise every line with a failure in it looks like an incident. A customer who auto-forwards their work mail to a personal mailbox produces an SPF failure in that provider's report. A recipient on an old-style discussion list produces another. These show up as one or two messages from an unfamiliar server, once, and then a different unfamiliar server next week. DKIM often survives forwarding when SPF does not — the signature travels inside the message — which is one of the reasons to set up both rather than relying on SPF alone.
It also bears repeating that these are daily summaries, not alarms. A report is not telling you that something went wrong today; it is telling you what the world saw. The reading you care about is the trend across weeks, not any single line.
When should I tighten my DMARC policy?
Only after you have read the reports and authorised every legitimate sender they reveal. The safe path is stepwise: stay in monitoring mode until the reports are clean, then move to quarantine, then to reject. Tightening before reading is how businesses end up rejecting their own invoices and order confirmations.
The three policy levels — "none", "quarantine", "reject" — form a deliberate ladder. "None" changes nothing about delivery and exists purely so you can watch the reports. "Quarantine" asks receivers to treat failing mail with suspicion, typically filing it as spam. "Reject" asks them to refuse it outright, which is the destination: at that point, mail that fakes your domain and fails authentication simply does not arrive. The ladder only works climbed in order, because each step assumes the previous one showed you a clean picture. A domain that jumps straight to "reject" with an unauthorised invoicing system still sending is a domain whose invoices stop arriving — silently, and only for some recipients, which makes it miserable to diagnose.
So the sequence is fixed: read the reports, authorise the legitimate senders they reveal, watch until the failures that remain are the forwarding noise described above, and then tighten one step at a time. Weeks at each step is normal. There is no prize for arriving at "reject" quickly, and a real cost to arriving there early.
What to do this week
Check whether your DMARC record has a reporting address. If it does not, add one — the reports cost nothing and start arriving within days. Then actually open one: unzip the attachment, look at the sources, and ask of each unfamiliar one "is this a service we use?" before asking anything darker. Authorise what is yours, watch what remains, and only then start climbing the policy ladder.
If unzipping XML by hand does not sound like your idea of a week well spent, this is a job monitoring exists for. MailControl receives and reads your DMARC reports for you, shows who is sending as your domain in plain language, separates your own unauthorised services from genuinely unrelated senders, and tells you when the picture is clean enough to tighten the policy. It sits alongside the rest of the TrustCtrl checks on your domain, and the wider context — why authentication decides whether you reach the inbox at all — is covered in why emails go to spam.