Why monitor DMARC reports? What the data tells you

Publish a DMARC record with a rua= address and receiving mail servers start sending you data: daily reports listing every server that sent mail claiming to be your domain, how much, and whether it passed authentication. That data answers the one question nothing else can — is it safe to turn enforcement on? — because it is the only complete view of who sends as you, including the senders you forgot and the spoofers you have never seen.

Monitoring is what turns those reports from XML attachments piling up in a mailbox into that answer. This guide covers what actually arrives, what a monitor extracts from it, and what "ready to enforce" means in concrete numbers.

There is also now a deadline-shaped reason to have the reports flowing: since February 2024, Google and Yahoo have required DMARC from bulk senders, with Microsoft's Outlook following in May 2025 — and every one of those requirements stops at p=none, which is exactly the monitoring stage. Who requires DMARC now? maps the mandates; this guide covers what to do with the reports they made you collect.

What arrives at your rua address

Aggregate reports (standardized in RFC 9990, originally part of RFC 7489) are XML files, usually gzip- or zip-compressed, sent by participating receivers — Google, Microsoft, Yahoo, and many others — typically once per day each. A report covers the mail that receiver saw from your domain during the period. For each sending IP, it records the message count, the SPF and DKIM results, whether they aligned with your domain, and what the receiver did with the mail.

Here is one record from a real-world-shaped report — one source IP, as one receiver saw it:

<record>
  <row>
    <source_ip>203.0.113.44</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <spf>
      <domain>mailer.esp-example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Notice there are no message contents — no subjects, no bodies, no recipient addresses. Aggregate reports are infrastructure data: who sent, how much, and whether it authenticated.

Why the raw XML doesn't work

That fragment is readable on its own. Now multiply it: one report per receiver per day, each containing a record per sending IP, every day, indefinitely. A small domain quickly accumulates thousands of records across hundreds of files — compressed XML attachments, in a mailbox, in a format built for machine parsing rather than human reading.

And the questions you actually need answered are cross-report questions. Look again at the record above: SPF passed — for mailer.esp-example.net, not for example.com — so DMARC evaluated it as a fail. Is that IP a spoofer, or your own ESP with its default (unaligned) signing? One record cannot tell you. The answer lives in the aggregate: does this IP send steadily every day (a real sender, misconfigured) or in bursts to one receiver (spoofing)? Does its volume correlate with your campaign schedule? No one reads their way to those answers across a mailbox of XML files. This is a parsing and aggregation job, which is why monitoring exists as a category.

What monitoring extracts

Parsed, aggregated over time, and grouped by source, the same data becomes a short list of findings:

• Sources you forgot. The invoicing platform, the HR system, the support desk, the office scanner — every organization's reports surface senders nobody had on the list. Each one found before enforcement is an outage avoided; each one is also usually one SPF or DKIM fix away from aligning.
• Spoofers, in the same table. Unknown IPs sending unaligned mail as your domain — visible with volumes and timelines. This is the mail your eventual policy will stop, made concrete.
• Alignment rate per sender. Not "is DMARC passing" in the aggregate, but which source is at 100%, which is at 92% and why. Enforcement readiness is a per-sender property; a healthy average can hide one broken sender.

The shadow-IT sender problem

The case for doing this before enforcement comes down to one recurring failure. Some team, at some point, signed up for a tool that sends mail as your domain — and nobody responsible for DNS knows it exists. At p=none its mail is delivered normally, so nothing looks wrong; the sender itself sees no error, because DMARC failures are invisible to the sending service. Then the policy tightens, and that mail — invoices, password resets, offer letters — starts silently going to spam or vanishing.

Nothing about DMARC warns you first. The only place that sender is visible in advance is the aggregate reports, where it has been showing up all along as a modest, steady, unaligned source. Enforcement without report data is a bet that no such sender exists. Report data replaces the bet with a checklist: here are the sources, align these three, then move.

What "ready to enforce" means in numbers

"Watch your reports until it looks safe" is where most guidance stops. It can be made concrete. A domain is ready for the next policy step when, over a full observation window:

• Every known source is aligned — ≥99% of its volume. Not the average across all sources: each sender individually. One misconfigured system inside a healthy average is exactly the mail enforcement will break. (The residual sliver below 100% is ordinary noise — forwarding artifacts and transient DNS failures, not senders.)
• Unknown-source volume is near zero — under 0.5% of the total. Some unattributed residue always exists (forwarders, tiny relays). If it is more than a trace, you have either an unidentified legitimate sender — find it first — or active spoofing worth watching.
• The window is long enough — 30 days, with data in it. Monthly invoicing runs, quarterly statements, low-volume systems: short windows miss them. And no data is not a pass — an empty window means nothing has been demonstrated, not that nothing is wrong.

These are the thresholds DNS Doctor's readiness engine applies, and each policy step re-earns them: the same bar holds at p=none → quarantine and at quarantine → reject, following the staged ladder from the DMARC guide.

Record drift: the part reports can't see

Reports tell you how mail is authenticating. They do not tell you when the records themselves change — and records change more often than expected. A new service's setup guide says "add this include," pushing SPF over its 10-lookup limit. A DKIM key is rotated away, or deleted in a DNS cleanup. Someone edits the DMARC record by hand and drops a tag. A migration rewrites the zone.

Each of these can quietly undo months of alignment work — an SPF PermError, for instance, means SPF can no longer produce an aligned pass for any sender, and at p=reject that is a live outage for every source that depended on it. Drift is invisible until the failure data arrives in reports a day or more later, which is a day of lost mail at enforcement. The countermeasure is mechanical: re-check the records themselves daily and alert on any change, so drift is caught when it happens rather than when it hurts.

What DNS Doctor's monitoring does — and doesn't

Plainly, so you can judge the fit:

• Ingests your aggregate reports. You add one address to your record's rua= tag; parsed results appear as per-source volumes, alignment rates, and timelines, with 12 months of retention. Fresh reports take 24–48 hours to start arriving, so you can also upload the reports you already have — exported from another tool, or the attachments piling up wherever your current rua= points — and start with the history you already have, from your very first day.
• Re-scans your records daily and alerts on change — a new sender in your reports, an edited SPF or DMARC record, a vanished DKIM key, a blacklist appearance, an approaching domain or certificate expiry.
• Computes the readiness verdict against the thresholds above, and when they are met, generates the exact next-step record — deterministically, by the same rule-based engine that validates records against the RFC grammar. The LLM never writes your DNS record.
• Never touches your DNS. Every record is applied by you, in your DNS panel, after your own review. The monitor's job is evidence and a prepared record, not access.

What it does not do: read your mail (aggregate reports contain none), fix anything on its own authority, or move you up the policy ladder automatically.

Where to start

Monitoring presumes reports, and reports presume a rua= tag — so the first step is the free one: check whether your DMARC record exists and where it points, with the DMARC record checker or a full scan of your domain below. If you are at p=none with no one reading the reports — or no rua= at all — that is the gap: the data that makes enforcement safe is either unread or not being collected.