How to read a DMARC aggregate report without misreading SPF and DKIM

A DMARC aggregate report is a receiver's summary of mail it saw using your visible From domain. It is usually delivered to the address in your rua tag as compressed XML. The current format is defined by RFC 9990. You do not need to read every XML element to find the next sender to investigate.

The key is to separate three questions: how many messages the receiver grouped together, which domain each authentication method checked, and whether either method aligned with the domain people saw in the From address.

Start with the report, then the row

report_metadata identifies the reporting organization and the reporting period. Its date_range values are Unix timestamps for that period, not the first and last messages observed. policy_published records the DMARC policy the receiver found. Compare it with your current DNS only after checking the report's dates: a policy may have changed since then.

Each record describes a group of messages with a sending IP and the same reported results. Within its row, source_ip is the connecting IP and count is the number of messages represented. A count of 400 is 400 messages, not one event or 400 distinct people. The RFC says receivers count messages even when other filters ultimately block delivery; this report is not an inbox-placement record.

The two result sections answer different questions

Under row.policy_evaluated, dkim and spf report the DMARC alignment tests. A pass in either one is enough for DMARC authentication to pass. disposition records the action taken under DMARC policy: none, quarantine, or reject. It is not a guarantee of final delivery. A reasoncan explain why the reported disposition differed from the published policy, such as a local override.

Under auth_results, DKIM and SPF show the underlying authentication checks, including the domains checked. Those results are deliberately uninterpreted with respect to DMARC. A vendor's SPF can pass for mailer.vendor.example while the visible From is example.com; the SPF alignment result can still be fail. Read identifiers.header_from to see that visible domain, then inspect the domains in auth_results to understand the mismatch.

<record>
  <row>
    <source_ip>192.0.2.25</source_ip>
    <count>40</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim><spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>example.com</header_from></identifiers>
  <auth_results>
    <spf><domain>mailer.vendor.example</domain><result>pass</result></spf>
  </auth_results>
</record>

This illustrative row says 40 messages connected from the same IP. SPF authenticated a vendor domain, but SPF did not align with example.com; DKIM did not provide an aligned pass either. The none disposition means the receiver reported no DMARC policy action for this group. It does not prove the messages reached inboxes.

Turn the report into a sender decision

1. Group rows by visible From domain, sending source, and the alignment results. Use count to prioritize volume, but keep the reporting period and receiver attached to each group.
2. For an expected service, identify its owner and check real message headers from a mailbox you control. Configure an aligned DKIM signing domain or aligned SPF return path, then verify new mail and later reports.
3. For an unknown source, investigate before authorizing it. The IP alone may belong to a shared provider or forwarder; the report does not identify the business owner.
4. Watch whether failing, legitimate traffic falls after the fix. Only then use the report trend to inform a stricter DMARC policy.

Receivers may decline to send reports, and aggregate data can still reveal sensitive sending patterns. Protect the rua mailbox and avoid treating one receiver's report as a complete inventory. For a single-message investigation, use the trusted receiver's Authentication-Results headeralongside the aggregate trend. RFC 9990 explains the report fields; RFC 9989explains how report review supports a staged enforcement rollout.

Disclosure: AI tools were used in the process of creating this blog post.