How to read DMARC aggregate (rua) reports

Publishing rua= is the easy part. Opening the attachment is when people bounce off DMARC. Aggregate reports are designed for machines. Reading them by hand is possible for a day or two and miserable as a habit.

What a rua report is

Receivers that see mail claiming your domain periodically email you an XML summary (often gzip- or zip-compressed). Each report covers a time window and breaks volume down by source. The goal is to answer:

• Who is sending as us?
• Are those sends authenticating and aligning?
• What did the receiver do with failures under DMARC (no DMARC action, quarantine, or reject)?

That data is how you move from p=none to enforcement without guessing. For how SPF, DKIM, and DMARC relate, see SPF vs DKIM vs DMARC. For the pass-but-fail case, see DMARC alignment explained.

rua vs ruf

Report type	What you get	Start here?
rua (aggregate)	Daily counts by source, SPF/DKIM results, disposition	Yes
ruf (forensic)	Failure samples that may include message content	Later, if ever

Most teams never need ruf. Aggregate rua is enough for setup and enforcement decisions.

External reporting addresses

If rua= points at a domain you do not control (including a monitoring vendor), that destination must authorize receiving reports for your domain (DMARC external destination verification). Without authorization, many receivers simply do not send the reports. Publishing the record is not enough.

How to open the attachment

1. Find the message from a reporter (Google, Microsoft, Yahoo, and others each send their own).
2. Download the attachment. It is often .xml.gz or a .zip containing XML.
3. Decompress to a .xml file and open it in a text editor or feed it to a parser.
4. Expect many reporters and many files. One quiet day in Gmail’s reports does not mean Microsoft agrees.

Cadence is usually about daily, not realtime. After a DNS change, wait for the next reporting cycle before judging success.

A minimal report shape

Exact tags vary, but the skeleton is stable:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range><begin>...</begin><end>...</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>1200</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>yourdomain.com</domain><result>pass</result></dkim>
      <spf><domain>bounces.esp.example</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Read identifiers (what From claimed), auth_results (what passed and for which domain), then policy_evaluated (what DMARC decided). A pass under auth_results for the wrong domain is the alignment story again.

Fields worth reading first

When you open a report (or a tool that parsed one), prioritize:

1. Source (source_ip and/or reporting org). Is this your ESP, your office MTA, a forwarder, or something you do not recognize?
2. Count. One weird message is noise. Thousands from an unknown host is a project.
3. SPF and DKIM results, plus whether they were aligned to the From domain (header_from).
4. Disposition. none means DMARC did not quarantine or reject. It does not mean the message reached the inbox. Other filters can still divert mail. quarantine and reject mean the published policy asked for stronger handling.

A source that fails authentication but shows disposition none under p=none is expected. The same source under p=reject should usually stop landing, subject to pct=, subdomain policy (sp=), reporting lag, and receivers that soften policy.

Spoofing vs your own broken sender

This is the judgment call raw XML does not make for you:

• Likely your tool: known ESP hostname or documented sending IP ranges, steady volume, SPF/DKIM almost configured, alignment missing. Fix the ESP’s DKIM for your domain and SPF include.
• Likely spoofing: random consumer ISPs, scattered IPs, no relationship to your vendors, often failing both checks. Enforcement is the fix, not another include.

Mislabeling spoofing as “fix SPF” wastes time. Mislabeling a new CRM as an attacker gets the CRM blocked when you enforce. Never authorize attacker IPs in SPF to make a report row turn green.

Can I move to quarantine?

Before you leave p=none, confirm:

1. Every high-volume source is identified.
2. Legitimate senders show aligned SPF or DKIM (preferably both).
3. Remaining failures are low volume or clearly spoofing.
4. You have watched a full business week of sending patterns.
5. You know how to roll policy back if a forgotten tool appears.

Optional: raise enforcement gradually with pct= (for example quarantine at 10%, then 50%, then 100%) so a missed sender is a partial outage, not a total one.

Then move p=none → p=quarantine → p=reject as confidence grows. Jumping straight to reject without this evidence is how invoice mail disappears for a week.

Why people stop reading XML

• Reports arrive as compressed attachments from many receivers, each with slightly different shapes.
• Volume grows with every domain and every vendor.
• The question you care about (“can I move to quarantine?”) needs a trend, not one file.

Email Watch ingests the rua stream, classifies sources in the UI, and surfaces issues instead of a folder of XML. Email Watch does not block or filter mail; receivers apply the DMARC policy you publish.

What to do next

1. Confirm DMARC is published with a working rua= (free DMARC checker). If rua is a third party, complete external destination authorization.
2. Skim a few days of reports for unknown high-volume sources and unaligned ESPs.
3. Fix alignment on legitimate senders before tightening policy.
4. When the XML stops being readable, start a trial and point rua at Email Watch (with authorization) so the same reports become a dashboard.