← Back to Guides

Reading DMARC Aggregate Reports

How to interpret DMARC aggregate report data — sources, pass rates, disposition, and alignment.

What Are Aggregate Reports?

When you publish a DMARC record with a rua= tag, receiving mail servers send you aggregate reports (also called RUA reports). These are XML files, typically compressed as ZIP or GZIP attachments, that summarise authentication results for all email they received claiming to be from your domain during a reporting period (usually 24 hours).

Aggregate reports do not contain message content or subject lines. They contain metadata: which IP addresses sent email as your domain, how many messages each sent, and whether those messages passed or failed SPF, DKIM, and DMARC.

XML Structure Overview

A DMARC aggregate report has two main sections: metadata about the report itself, and one or more records describing mail sources. Here is a simplified example:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>17293847561234567890</report_id>
    <date_range>
      <begin>1709164800</begin>
      <end>1709251199</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>yourcompany.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1524</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourcompany.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>yourcompany.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>yourcompany.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Understanding Source IPs

The <source_ip> field tells you the IP address of the server that delivered the message. This is the single most important field for identifying who is sending email as your domain. Each unique IP address appears as a separate record with a <count> of how many messages it sent during the reporting period.

To interpret source IPs effectively:

  • Look up the IP owner. Use a reverse DNS lookup or WHOIS query to determine who owns the IP. DMARCWatch does this automatically and displays the organisation name alongside each IP.
  • Match IPs to known services. Google Workspace, Microsoft 365, Amazon SES, SendGrid, Mailchimp, and other major services send from well-known IP ranges. If you recognise the owner as a service you use, the traffic is likely legitimate.
  • Flag unknown senders. IPs that belong to hosting providers, VPS services, or unknown organisations — especially those failing authentication — are often spoofing attempts or misconfigured systems.

Interpreting SPF and DKIM Results

Each record contains two sets of authentication results that are important to understand separately:

Raw Authentication Results (<auth_results>)

These show whether SPF and DKIM passed on their own terms, regardless of alignment:

  • <spf><result>pass</result> — The sending IP was listed in the SPF record of the envelope sender domain.
  • <dkim><result>pass</result> — A valid DKIM signature was found for the specified domain and selector.

Possible result values include pass, fail, softfail, neutral, temperror (temporary DNS error), permerror (permanent error, such as a malformed record), and none (no record found).

Policy Evaluation (<policy_evaluated>)

This section shows the DMARC-level result after alignment is considered:

  • <spf>pass</spf> — SPF passed and the SPF domain aligns with the From header domain.
  • <dkim>pass</dkim> — DKIM passed and the DKIM signing domain aligns with the From header domain.

A message passes DMARC if either the SPF or DKIM policy evaluation shows pass. Both do not need to pass — one aligned pass is sufficient.

Disposition Values

The <disposition> field tells you what the receiving server actually did with the message based on your published DMARC policy:

  • none — The message was delivered normally. This is expected when your policy is p=none, or when the message passed DMARC.
  • quarantine — The message was placed in the recipient's spam or junk folder.
  • reject — The message was rejected and not delivered at all.

Note that the disposition reflects what the receiving server chose to do, which may not always match your published policy exactly. Some receivers apply local overrides — for example, a message might show disposition=none even when your policy is p=quarantine if the receiver decided the message was legitimate based on other signals.

Identifying Legitimate vs. Unauthorised Senders

When reviewing your aggregate report data in DMARCWatch, apply this framework to each source IP:

Legitimate and Properly Configured

The source IP belongs to a known service, and both SPF and DKIM pass with alignment. No action needed — this is the ideal state.

Legitimate but Misconfigured

The source IP belongs to a service you use, but SPF or DKIM is failing. Common causes include:

  • The service's sending IPs are not in your SPF record. Add the appropriate include mechanism.
  • DKIM is not configured for the service, or it is signing with the service's own domain instead of yours. Set up custom DKIM signing in the service's settings.
  • The service uses an envelope sender domain that does not align with your From domain. Check the service's documentation for custom return-path settings.

Unauthorised Senders

The source IP belongs to an unknown hosting provider, VPS, or residential ISP, and authentication is failing. These are likely spoofing attempts. Once your policy is set to p=reject, these messages will be blocked automatically.

Forwarded Mail

Mail forwarding (e.g., university alumni addresses, legacy domain redirects) often breaks SPF because the forwarding server's IP is not in the original sender's SPF record. DKIM typically survives forwarding if the message body is not modified. These sources will show SPF fail but DKIM pass. If DKIM alignment passes, DMARC still passes. If you see legitimate forwarded mail failing both, consider the impact before tightening your policy.

Using DMARCWatch to Simplify This

Reading raw XML reports is tedious and error-prone. DMARCWatch parses all incoming reports automatically and presents the data as clear, actionable dashboards. You can see at a glance which sources pass or fail, track your authentication rates over time, and identify the specific issues that need to be fixed before you can safely move to a stricter policy.

For more on the policy progression, see our DMARC Policy Guide. For help setting up authentication for your sending sources, see Understanding SPF Records and DKIM Explained.

← Back to Guides