How to Read DMARC Reports

Report Types: RUA vs. RUF

DMARC produces two types of reports, and understanding the difference matters for how you approach monitoring:

Most DMARC monitoring focuses on aggregate reports because they provide the broadest picture of your sending ecosystem. Forensic reports are a supplement, not a replacement.

Anatomy of an Aggregate Report

Aggregate reports arrive as gzipped or zipped XML files attached to emails sent to your RUA address. Here is a simplified example showing the structure you will see in every report:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>[email protected]</email>
    <date_range>
      <begin>1712534400</begin>
      <end>1712620800</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>198.51.100.25</source_ip>
      <count>1542</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>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Here is what each section tells you:

• report_metadata — Who sent this report (the receiving organization) and the time range it covers. The timestamps are Unix epoch format.
• policy_published — Your DMARC policy as seen by the receiver at the time they processed the messages. If you recently changed your policy, older reports may still reflect the previous one.
• source_ip — The IP address of the server that sent the messages. This is what you use to identify the sending service.
• count — How many messages came from this source IP during the reporting period. In this example, 1,542 messages were sent from 198.51.100.25 as example.com.
• disposition — What the receiver actually did with the messages: none (delivered normally), quarantine (sent to spam), or reject (blocked).
• dkim and spf — Whether each authentication mechanism passed or failed. The policy_evaluated section shows the DMARC-level result (after alignment), while auth_results shows the raw authentication results.

Fields That Matter Most

When you are reviewing reports, focus on these five data points:

How to Identify Legitimate Senders

The primary goal of reading DMARC reports is building a complete inventory of everything that sends email as your domain. Here is the process:

1. Collect 1–2 weeks of reports. A single day is not enough. Some services send infrequently—weekly digests, monthly invoices, triggered notifications. You need enough time for them all to appear.
2. Group by source IP. Aggregate all reports and extract unique source IPs with their message counts and authentication results.
3. Reverse DNS each IP. This identifies the sending service. Google Workspace, SendGrid, Mailchimp, HubSpot, Amazon SES, Postmark—they all have recognizable reverse DNS patterns.
4. Cross-reference with your known sending services. Compare the list against what your IT, marketing, sales, and support teams know about. Every service should be accounted for.
5. Investigate unknowns. Any IP you cannot identify is either shadow IT (a team using a service without IT's knowledge), a misconfigured service, or unauthorized sending. Contact internal teams before assuming the worst.

How to Spot Abuse or Misalignment

Not everything in your reports is benign. Watch for these warning signs:

• •High volume from IPs you do not recognize. If an IP sent thousands of messages as your domain and you cannot identify it through reverse DNS, it is likely spoofing or a compromised service.
• •SPF or DKIM failing consistently from a known service. This is a misconfiguration, not an attack. Common causes: you forgot to add the service's include to your SPF record, or the service is not signing with DKIM for your domain.
• •Messages passing SPF but failing DKIM (or vice versa). This is partial alignment. It might be enough for DMARC to pass (only one mechanism needs to align), but it is fragile. If the passing mechanism breaks, DMARC will fail entirely.
• •Disposition showing "none" for messages you would want quarantined. This means your policy is too loose. If you see spoofing attempts being delivered normally because your policy is p=none, that is a clear signal to start planning your move to enforcement.

When to Move Toward Enforcement

Reading reports is not an end in itself—the goal is to reach a point where you can safely enforce your DMARC policy. You are ready when:

1. You have identified all legitimate senders and they all pass DMARC alignment. No known service should be failing.
2. You have fixed misconfigurations. Missing SPF includes have been added. DKIM signing has been enabled for services that support it. Alignment issues have been resolved with vendors.
3. You understand the volume and sources of unauthorized mail. You know what spoofing looks like for your domain and you are ready to block it.
4. You have tested with a low percentage. Set your policy to p=quarantine; pct=10 and monitor for a week. If no legitimate mail is affected, increase gradually.

Reading Reports at Scale

Manual XML parsing works for a single domain with low email volume. You can use command-line tools like xmllint or simple scripts to extract the data you need.

Beyond that, a monitoring platform automates report collection, sender identification, and trend tracking. The value is not just visualization—it is the historical record that lets you confidently tighten policy over weeks. A platform shows you whether a sender that appears today was also present last month, or whether it is new and needs investigation.

For organizations managing multiple domains or operating as an MSP, manual parsing is not feasible. You need automated ingestion that handles decompression, XML parsing, IP resolution, and sender classification across all your domains simultaneously. The alternative is spreadsheets and guesswork, which is how legitimate mail gets blocked during enforcement rollouts.

Frequently Asked Questions