What DMARC reports are actually telling you

You publish `p=none` with a reporting address, and within a day XML files start arriving from Google, Microsoft, and a dozen providers you have never heard of. Most people glance at one, decide it is unreadable, and leave the policy at none forever. That is the expensive outcome, because the whole point of the monitoring phase is finding out who else sends as your domain before you start refusing their mail.

2 August 2026 · 5 min read

What a report contains#

An aggregate report covers a day of mail claiming to be from your domain, as seen by one provider. Each row is a sending source with a count, and for each one: the IP that sent it, whether SPF and DKIM passed, which domains they passed for, and what your policy told the provider to do.

Note what is not in there. No subjects, no recipients, no message content. Aggregate reports are counts and verdicts, which is why they are safe to route to a shared address and why they cannot tell you which specific message failed.

The rows fall into three groups, and sorting them is the entire exercise.

The three failures you will actually see#

A forwarder. Mail you sent, forwarded by a recipient, arriving with a broken DKIM signature because the forwarder modified it. High volume from mailing lists and university addresses. This is expected, is not an attack, and is one reason DKIM alignment on your own domain matters more than SPF, per SPF, DKIM, and DMARC for an agent subdomain.

A service nobody told you about. A ticketing tool, a payment provider, an events platform someone signed up for in 2023, all sending as your domain and failing alignment because nobody published their DKIM record. This is the single most valuable thing the monitoring phase finds, and it is exactly what would have broken if you had gone straight to reject.

Someone spoofing you. Low volume, IPs from nowhere near your infrastructure, failing everything. Usually harmless background noise on any domain that exists. It becomes interesting when volume is sustained or targeted, which is the subject of brand impersonation and lookalike domains.

Reading them without becoming a full-time job#

Do not parse the XML by hand. Any DMARC reporting service will aggregate across providers and give you a table, and for a dedicated agent subdomain with one legitimate sender the volume is small enough that a free tier covers it.

For a subdomain that only agents send from, you can also read them manually, because the correct picture is almost boring: one source, passing, plus a trickle of forwarders and noise. That simplicity is a benefit of the subdomain approach rather than a coincidence. On a root domain with a decade of history, use a service.

When it is safe to advance the policy#

The criteria, in order:

1. Every source in group two is either fixed or stopped. Fixed means its DKIM is published and aligning; stopped means it no longer sends as you.
2. Two clean weeks at `p=none`, with no new legitimate sources appearing.
3. Move to `p=quarantine`, and watch for a fortnight. If something you missed exists, this is where it shows up as a support question rather than as lost mail.
4. Move to `p=reject`. This is the destination. A subdomain used only by agents should never acquire new senders, so there is no reason to sit at quarantine indefinitely.

Two refinements worth knowing. sp= sets the policy for subdomains independently, so a cautious root domain can carry p=none; sp=reject while you tighten the parent separately. And pct= ramps enforcement gradually on high-volume domains, which is rarely needed at agent volumes and is worth skipping if your traffic is small enough to just watch.

What reports will not tell you#

They answer authentication, not deliverability. A domain can pass DMARC on every message and still land in spam, because alignment says the mail is really from you and says nothing about whether recipients want it. If reports are green and placement is bad, the problem is reputation or content, and the diagnostic order is in deliverability for agent senders.

They also lag. Reports arrive daily, so they are a review tool rather than an alert. The things worth alerting on in real time are bounces, complaints, and volume changes, per what to monitor in production.

A workable routine#

• rua pointed at an address a person or a service actually reads, not a black hole.
• A look at the first week's reports, sorting sources into the three groups.
• One decision per group-two source: fix or stop.
• Policy advanced on the schedule above, deliberately, rather than left at none.
• A quarterly glance afterwards, because new sources appear when someone signs up for something.

That is perhaps two hours in total for a new agent subdomain, and it is what stands between you and the Friday afternoon where legitimate mail stops being delivered.

Questions#

What is in a DMARC aggregate report?

Counts and verdicts per sending source for one day, as seen by one provider: the sending IP, whether SPF and DKIM passed, which domains they passed for, and what your policy asked for. No subjects, recipients, or content.

Why is my own mail failing DMARC in the reports?

Usually forwarding, which breaks the DKIM signature, or a third-party service sending as you without its DKIM published. The second is what the monitoring phase exists to find.

Do I need a DMARC reporting service?

For a root domain with history, yes. For a dedicated agent subdomain with one sender, the reports are small enough to read directly, though a free tier still saves time.

When can I move to p=reject?

Once every legitimate source is aligned or stopped, after about two clean weeks at none and a fortnight at quarantine. For an agents-only subdomain, reject is the destination rather than an optional extra.

What is `sp=` for?

It sets the policy for subdomains independently of the parent, so a cautious root domain can enforce strictly on subdomains while you tighten the parent separately.

Reports are clean but mail still lands in spam. Why?

DMARC answers whether the mail is really from you, not whether recipients want it. Clean reports plus poor placement means reputation or content, not authentication.