DMARC Aggregate Reports (RUA) Explained: How to Read XML Reports and Spot Spoofing

When you add rua=mailto:... to your _dmarc DNS record, mailbox providers like Google, Yahoo, Microsoft, and Apple begin emailing you .xml.gz or .zip attachments every 24 hours.

If you open one of those attachments directly in a text editor, you are greeted by hundreds or thousands of lines of dense RFC 7489 XML containing raw IP addresses, policy evaluation blocks, and dual authentication results.

Understanding how to read DMARC Aggregate (rua) reports is the difference between safely moving your domain to p=reject and accidentally blocking your own billing or CRM emails. Here is a practical breakdown of how RUA reports work, how to interpret every XML field, and how to separate real spoofing attacks from legitimate forwarding or misconfigured SaaS tools.

First, verify that your domain's _dmarc record has a valid rua= tag using the Free DMARC Checker.

RUA (Aggregate) vs RUF (Forensic) reports: What's the difference?

DMARC defines two reporting tags (rua= and ruf=), and they serve very different operational and privacy functions:

Engineering recommendation: Always configure rua=. Do not rely on ruf= for visibility, as major inbox providers will not send forensic reports.

Anatomy of a DMARC RUA XML report

Every DMARC aggregate report contains three main XML sections:

1. <report_metadata>: Who sent the report (e.g., google.com, enterprise.protection.outlook.com, yahoo.com) and the 24-hour UTC timestamp window covered (<date_range>).
2. <policy_published>: The exact _dmarc DNS record the receiver saw on your domain during that window (<domain>, <adkim>, <aspf>, <p>, <sp>, <pct>).
3. One or more <record> blocks: One block per unique <source_ip> that sent mail claiming to be from your domain.

Here is an annotated <record> block from a real-world DMARC XML report:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>142</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>
      <selector>google</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>unaligned-forwarder.org</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Crucial distinction: <policy_evaluated> vs <auth_results>

New administrators often misread the XML above because <policy_evaluated> says <spf>fail</spf>, while <auth_results> at the bottom says <spf><result>pass</result></spf>. Why do they disagree?

• <auth_results> (Bottom section) = Raw Authentication: Did SPF pass against whatever domain was in the Return-Path? Did DKIM pass against whatever domain was in d=?
• <policy_evaluated> (Top <row> section) = DMARC Alignment Result: Did SPF or DKIM pass AND align with <header_from> (yourdomain.com)?

In the XML snippet above:

• The email was forwarded by unaligned-forwarder.org.
• Raw SPF passed for unaligned-forwarder.org (<auth_results>), but because unaligned-forwarder.org does not match yourdomain.com, DMARC SPF alignment evaluated to <spf>fail</spf> inside <policy_evaluated>.
• Fortunately, the original google DKIM signature for yourdomain.com survived forwarding (<dkim>pass</dkim> in both sections).
• Because DMARC only requires either aligned DKIM or aligned SPF to pass, all 142 messages passed DMARC (<disposition>none</disposition>).

How to classify every <record> row in 4 categories

When auditing your RUA data before moving to p=quarantine or p=reject, every source IP falls into one of four buckets:

1. Fully Aligned Legitimate Traffic (dkim=pass and/or spf=pass in <policy_evaluated>)

This is your healthy baseline (e.g., Google Workspace, Microsoft 365, or properly configured transactional ESPs). Verify that both DKIM and SPF are aligned where possible so you have redundancy.

2. Misconfigured "Shadow IT" or Marketing Senders

Signature in XML:

• <source_ip> resolves (via reverse DNS / PTR or ASN lookup) to a known SaaS email platform (.sendgrid.net, .mcsv.net, .hubspotemail.net, .amazonses.com, *.zendesk.com).
• <policy_evaluated> shows <dkim>fail</dkim> and <spf>fail</spf>.
• <auth_results> shows raw <spf><result>pass</result></spf> or <dkim><result>pass</result></dkim> against the vendor's shared domain instead of yourdomain.com.

Action: Do not switch to p=reject yet. Contact the team using that SaaS tool and configure custom DKIM signing (selector._domainkey.yourdomain.com) and a custom Return-Path subdomain. See our SPF, DKIM, and DMARC alignment troubleshooting guide.

3. Auto-Forwarded Legitimate Mail

Signature in XML:

• <source_ip> belongs to a university, hospital, partner company, or consumer inbox (outlook.com, pobox.com, icloud.com).
• Volume (<count>) is low (typically 1–15 messages per day).
• <policy_evaluated> shows <dkim>pass</dkim> and <spf>fail</spf>.

Action: No fix required as long as <dkim>pass</dkim> holds! This is normal SMTP forwarding behavior and is the exact reason DKIM signing is mandatory before enforcing DMARC.

4. Unauthorized Spoofing & Phishing Attacks

Signature in XML:

• <source_ip> belongs to residential ISPs, bulletproof VPS hosts, or unknown foreign ASNs.
• Both <policy_evaluated> AND <auth_results> show fail (or softfail/none) for yourdomain.com.
• Often appears in sudden spikes across multiple unrelated source IPs.

Action: Once Categories 1 and 2 are fully aligned, moving your DMARC policy to p=quarantine and p=reject instructs receiving servers to quarantine or drop these spoofed messages automatically.

External domain reporting (_report._dmarc)

When your rua= tag sends reports to an external domain (for example, sending reports for acme.com to mailto:reports@rua.getmailposture.com), RFC 7489 Section 7.1 requires the receiving report processor to publish a DNS verification TXT record authorizing external domains:

acme.com._report._dmarc.rua.getmailposture.com. IN TXT "v=DMARC1"

When you use MailPosture's RUA reporting address ({token}@rua.getmailposture.com), our DNS infrastructure handles external report authorization automatically so Gmail, Yahoo, and Microsoft deliver your daily aggregate reports without drops.

Stop reading raw XML files by hand

Manually decompressing .xml.gz files and running reverse-DNS lookups on dozens of IP addresses every morning doesn't scale. Run a free domain scan to get a copy-paste DMARC record pre-configured with RUA reporting, or explore our Pro and Agency monitoring plans to automatically parse daily DMARC aggregate reports into visual pass/fail analytics and sender inventories.