DMARC Reports Explained: How to Read RUA Aggregate and RUF Forensic Reports

When you publish a DMARC record with reporting tags, receiving mail servers send you reports about email they've received claiming to be from your domain. These reports tell you which servers are sending as your domain, whether they're passing SPF and DKIM, and whether they're aligned with your DMARC policy.

There are two report types: RUA (aggregate reports) and RUF (forensic/failure reports).

Aggregate reports (specified by the rua= tag) are XML files sent once per day by each receiving domain. They contain: - The reporting organization (e.g., Google, Microsoft) - Date range covered - Your DMARC policy at the time - Records of all email claiming your domain as sender, grouped by source IP - SPF and DKIM pass/fail counts for each source - DMARC policy action applied (none, quarantine, reject)

Example rua tag: rua=mailto:dmarc-reports@yourdomain.com

You'll typically receive RUA reports from Gmail, Outlook, Yahoo, and large ISPs. Volume can be high — use a DMARC report processor like dmarcian, Valimail, or EasyDMARC rather than parsing raw XML yourself.

Forensic reports (ruf= tag) are sent immediately when an email fails DMARC. They contain a copy of the failing message (headers and sometimes body, depending on the sender's policy).

RUF reports help you diagnose specific failures but may contain sensitive email content. Not all providers send RUF reports — many have disabled them for privacy reasons. Gmail does not send forensic reports.

DMARC failure options (fo= tag): - fo=0 (default): Report only if both SPF and DKIM fail - fo=1: Report if either SPF or DKIM fails - fo=d: Report if DKIM fails - fo=s: Report if SPF fails

DMARC aggregate reports are compressed XML files. Key elements:

<record>: Each record represents a group of emails from a specific source IP. <source_ip>: The IP that sent the emails <count>: Number of messages from this IP <policy_evaluated>: Whether DMARC policy was applied (none/quarantine/reject) and what the result was (pass/fail) <spf>/<dkim>: Authentication results for each message type

Look for records with DMARC failures from unexpected IPs — these indicate either unauthorized senders using your domain or legitimate sending sources you haven't configured for authentication.

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1709251200</begin>
      <end>1709337600</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <p>quarantine</p>
    <sp>quarantine</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1842</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourdomain.com</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

The path from p=none to p=reject: 1. Start at p=none with rua= configured 2. Review reports for 2-4 weeks to identify all legitimate senders 3. Ensure each legitimate sender has SPF and DKIM configured 4. Move to p=quarantine at pct=10, then pct=50, then pct=100 5. Monitor reports at each stage for unexpected failures 6. Move to p=reject once 100% quarantine shows no legitimate failures