DeliverSight Run a free test
· 6 min read

DMARC reports explained: reading aggregate (RUA) XML

DMARC aggregate reports are dense XML, but they hold the truth about who sends mail as your domain. Here is how to read them — and what to do next.

DMARCreportingmonitoring

Once you publish a DMARC record with a rua= address, mailbox providers start emailing you daily aggregate reports. They are gzipped XML — unfriendly at a glance, but they answer the question that matters: who is sending mail as my domain, and does it pass?

Anatomy of a report

Each report has metadata, your published policy, and one or more records:

<record>
  <row>
    <source_ip>203.0.113.10</source_ip>
    <count>128</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

Read it as: from this IP, this many messages, with these authentication outcomes.

What to actually look for

  • Volume by source IP — group records by source_ip. Recognize your ESPs; investigate anything you do not.
  • Alignment, not just pass — SPF or DKIM can “pass” yet fail DMARC alignment if the authenticated domain differs from your From domain.
  • Failing legitimate sources — a forgotten app or CRM sending unauthenticated mail. Add it to SPF or set up DKIM for it before tightening policy.
  • Spoofing — unknown IPs failing authentication are exactly what DMARC exists to stop.

From reports to action

The workflow is always the same:

  1. Start at p=none and read reports until you recognize every legitimate source.
  2. Bring each source into alignment.
  3. Move to p=quarantine, then p=reject.

Parsing this XML by hand does not scale past a few sources. DeliverSight’s DMARC aggregation ingests your RUA stream and turns it into readable trends — pass rates over time, a ranked source list, and alerts when an unknown sender appears — so you can reach p=reject with confidence instead of crossing your fingers.