How to Read DMARC Reports: A Field-by-Field Guide to RUA Data

You published a DMARC record with a rua address, and now your inbox fills up with compressed XML attachments from Google, Yahoo, Microsoft and providers you've never heard of. Those files are the most useful deliverability data you'll get for free: a list of every server that sent mail claiming to be your domain, and whether it passed. This guide explains what's inside an aggregate report, how to read one record, and how to turn the data into a fix list that gets you to p=reject.

AI Automation for Accounting Firms, Explained Step by Step · 3:03 Subscribe

What an aggregate report is

When your DMARC record includes rua=mailto:..., receivers that support DMARC reporting send you a summary of the mail they saw from your domain, usually once a day. Google describes it this way: each report contains metadata and one or more records, and each record summarizes the messages from a single IP address with their SPF, DKIM and DMARC results and the action the receiver took.

What reports don't contain: message content, subject lines or individual recipient addresses. They're aggregate counts. (Per-message failure reports, set with ruf, are a separate thing, and few large mailbox providers send them.)

Format details, now specified in RFC 9990:

• XML, typically compressed. RFC 9990 specifies gzip (.xml.gz), though you'll also see .zip attachments from some receivers.
• File names follow the pattern receiver!your-domain!begin-timestamp!end-timestamp.xml.gz, for example google.com!example.com!1760227200!1760313599.zip.
• The period is usually one UTC day.

Anatomy of a report

Here is a trimmed but realistic report:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>8473920184756392017</report_id>
    <date_range>
      <begin>1760227200</begin>
      <end>1760313599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
  </policy_published>
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>412</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

The three sections

report_metadata: who sent the report and the time period. begin and end are Unix timestamps (seconds since 1970). Convert them with date -u -d @1760227200 on Linux or any epoch converter.

policy_published: the DMARC record the receiver found for your domain. Check this first. If it doesn't match what you think you published, you have a DNS problem.

record (one or more): the actual data. Each record groups messages that share a source IP and the same results.

Reading a record

The most important thing to understand is the difference between policy_evaluated and auth_results:

• auth_results says whether SPF and DKIM passed for whatever domain was used.
• policy_evaluated says whether they passed and aligned with your From: domain. That's what DMARC uses.

So this record:

<policy_evaluated>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
...
<auth_results>
  <dkim><domain>esp-example.net</domain><result>pass</result></dkim>
  <spf><domain>bounces.esp-example.net</domain><result>pass</result></spf>
</auth_results>

means the service authenticated correctly, but as its own domain, not yours. DMARC fails. The fix is to set up that service's custom DKIM for your domain, not to change your SPF record.

Sorting sources into four buckets

Work through your reports by source, ideally after loading them into a DMARC reporting tool or a spreadsheet. Group by source_ip and look up who owns each IP (reverse DNS and the auth_results domains usually give it away). Every source falls into one of four buckets.

1. Legitimate and passing

DKIM pass with your domain in policy_evaluated, high volumes, IPs belonging to your mailbox provider or known tools. Nothing to do.

2. Legitimate but failing alignment

You recognize the service (your CRM, newsletter tool, help desk, invoicing app), but policy_evaluated shows fail and auth_results shows the vendor's domain. These are the sources you must fix before moving to quarantine or reject:

• Complete the vendor's domain authentication (DKIM records for your domain).
• If offered, set a custom return-path or bounce domain on a subdomain you control so SPF aligns too.

3. Forwarded mail

Small counts from IPs belonging to other mailbox providers, university servers or mailing list software, with SPF failing but DKIM often still passing. The receiver may list forwarded or mailing_list as the reason. If DKIM survived, DMARC passes and you don't need to do anything. If a mailing list modified the message and broke DKIM, that's a known limitation of DMARC, and you generally can't fix it from your side.

4. Spoofing and abuse

Unrecognized IPs, often in hosting ranges or countries where you don't operate, failing both checks, sometimes in large bursts. This is the traffic DMARC enforcement exists to block. Don't try to "fix" it. Once buckets 2 and 3 are under control, moving to p=quarantine and then p=reject takes care of it.

What to look for each week

• DMARC pass rate by volume. Of all messages using your From: domain, what percentage passed? Track the trend, not single days.
• New sources. A new IP block with significant volume usually means someone in your company signed up for a new tool. Catch it before it hurts at enforcement.
• Sudden drops in DKIM pass rate for a known source. That often means an expired or rotated key, a DNS change that dropped a record, or a vendor change.
• policy_published mismatches. If a receiver reports a different policy than you published, check for duplicate records or a DNS host serving stale data.
• disposition after enforcement. At p=quarantine or p=reject, confirm that legitimate sources show none (delivered) and spoofed ones show your policy.

Practical tips for handling the volume

• Use a dedicated address such as dmarc-reports@example.com, not a person's inbox. Google recommends a dedicated group or mailbox.
• Use a parser for anything beyond a handful of reports. Free and paid DMARC reporting services, and open-source parsers, turn the XML into dashboards grouped by source.
• Authorize external report addresses. If rua points to another domain, that domain must publish example.com._report._dmarc.<their-domain> with v=DMARC1, or receivers will silently skip it. Reporting services set this up for you. If you use your own second domain, you need to add it.
• Expect reports only from receivers that send them. Not every mailbox provider reports, so treat the data as a large sample rather than a complete census.

Frequently asked questions

Why am I not receiving any DMARC reports?

Check that your record has a valid rua=mailto: tag and is published at _dmarc.yourdomain. If the address is on a different domain, confirm the external authorization record exists. Also allow a day or two: reports cover a full day and are sent after it ends.

What does "SPF pass but DMARC fail" mean in a report?

SPF passed for the envelope domain, but that domain isn't aligned with your From: domain. It's common with ESPs that use their own bounce domain. Fix it with aligned DKIM or a custom return-path on your domain.

Can I see which person or message failed?

Not from aggregate reports. They group messages by source IP and results, without subjects or recipients. Failure (ruf) reports can include message details, but few large providers send them, partly for privacy reasons.

How long should I keep DMARC reports?

There's no rule. Keeping a few months of summarized data lets you spot trends and compare before and after changes, such as moving to p=reject. Reporting services usually handle retention for you.

What to do next

Pick one week of reports and make a list of every source with meaningful volume. Mark each one as passing, failing alignment, forwarded or spoofed, then fix the "failing alignment" list one vendor at a time. When that list is empty, you're ready for the next step in the DMARC rollout plan. If you haven't published a reporting address yet, run a free audit to see your current DMARC record, and check the SPF lookup limit while you're there.

Related reading

• Automate DMARC Report Monitoring: Free Tools and Alert Rules: Automate DMARC aggregate report monitoring with free tools like parsedmarc, Postmark's digest or Cloudflare, set useful alerts and move from p=none to reject.

Sources

• RFC 9990: DMARC Aggregate Reporting
• RFC 9989: DMARC
• Google Workspace Admin Help: About DMARC reports
• RFC 7489: DMARC (original specification)