Reading DMARC Reports

Two report types

Aggregate reports (RUA) are the primary reports. They're XML documents sent daily by participating receivers like Google, Microsoft, Yahoo, and others. They summarize all mail they saw from your domain during a reporting period: the sending IP, whether SPF and DKIM passed, and whether those results aligned with your From domain.

Failure reports (RUF) are per-message reports sent when a specific message fails DMARC. They can contain message headers or content. Because of privacy concerns around potentially including personal data, many receivers don't send them. Stick with aggregate reports.

You configure reporting addresses in your DMARC record:

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com"

What's in an aggregate report

Each aggregate report covers one 24-hour reporting period and contains multiple records. Each record represents a group of messages from a single sending IP to that receiver. For each group, the report tells you:

• The sending IP address
• How many messages came from that IP
• The header From domain
• SPF result and the domain SPF authenticated
• DKIM result and the d= domain that signed the message
• Whether SPF aligned with the From domain
• Whether DKIM aligned with the From domain
• The overall DMARC disposition (none, quarantine, reject)

Reading the raw XML

The files arrive as gzip-compressed XML, often inside a ZIP. Manually reading them is tedious but possible. A simplified record looks like this:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>1204</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <auth_results>
    <dkim>
      <domain>yourcompany.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>yourcompany.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

This record shows 1,204 messages from Google's IP, with both DKIM and SPF passing and aligning. This is what you want to see.

What to look for

IPs you recognize with alignment failures — These are legitimate senders that need to be fixed. Look up the IP, identify the service, and configure DKIM or SPF alignment for that sender before you enforce.

IPs you don't recognize — These may be spoofing attempts. Cross-reference the IP against known hosting providers or spam networks. These are the sources DMARC enforcement is designed to block.

High volume from unexpected sources — A vendor you forgot about, a staging environment sending real mail, or a legacy system still active in production. These surface in reports before they cause problems.

Drop in pass rate — If your pass rate was 99% last week and is 85% this week, something changed. A vendor rotated keys, an SPF record broke, or a new system started sending without authentication.

Why a reporting tool matters

You may receive dozens or hundreds of aggregate reports per day from different receivers. At any real mail volume, reading raw XML is not practical. A DMARC reporting tool normalizes them into readable dashboards, groups results by sender, highlights failures, and tracks trends over time.

The standard for aggregate reports is defined in RFC 9990. dmarcdemon receives, parses, and stores those reports with up to 36 months of retention — so when something surfaces months later, you have the history to trace it.

How long to keep reports

Most DMARC tools keep 90 days of reports. That's usually not enough. Security incidents are often discovered weeks or months after they begin. An alignment failure that starts in month two may not surface as a deliverability problem until month four. 90-day retention means you don't have the data to understand when it started or which senders were involved.