How to Read Your First DMARC Reports (Part 1)

Have you published a DMARC (Domain-based Message Authentication Reporting and Conformance) record? If the answer is yes, then you receive DMARC reports that reveal crucial information about your email ecosystem—including authentication results, domain alignment, potential email threats, and more. But understanding these reports is not intuitive.

That’s why, in this two-part blog series, we break down how to read the two types of DMARC reports at your disposal: aggregate reports and forensic reports. We’ll start with aggregate reports.

What Are DMARC Aggregate Reports?
DMARC aggregate reports provide information about which emails are authenticating against SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC, and which are not.

While aggregate reports do not provide much information about the email messages themselves, they can provide valuable visibility into the health of your email program by helping you identify potential authentication issues and/or malicious activity.

How to Request DMARC Aggregate Reports
To start collecting data on your email streams, publish a simple DMARC record in monitor mode (tag: p=’none’), with a request for aggregate reports (tag: rua=mailto:[email protected]). Need help to create a DMARC record? This post along with our DMARC Creation Wizard will help you build one.

Once your DMARC record is in place, participating mailbox providers will send daily aggregate reports to the destination you defined in the rua tag.

Below is an overview of what is—and what is not—included in these DMARC aggregate reports, along with real-world examples so you can become more familiar with the format.

What Is Included in the DMARC Aggregate Report

1. ISP information, including: 

  • Mailbox provider name (tag: org_name)
  • Mailbox provider’s sending email address and additional contact information
  • Report ID number
  • Beginning and ending date range in seconds

pasted image 0

2. A line-by-line description of your DMARC record, including:

  • Header domain/friendly from domain (in the example below it is “”)
  • Alignment settings for both DKIM and SPF (tag: adkim and aspf)
  • Domain policy (tag: p)
  • Subdomain policy, if applicable (tag: sp)
  • Percentage of messages to which the DMARC policy is to be applied (tag: pct)

pasted image 0 (1)

3. Summary of authentication results, including:

  • IP identified in the legitimate and/or fraudulent email (tag: source_ip)
  • Count of IP addresses identified (tag: count)
  • Disposition of the message, to show if policy was applied (tag: disposition)
  • DKIM authentication results–lists the domain and result (e.g. none, pass, or fail)
  • SPF authentication results–lists the domain and result (e.g. neutral, pass, or fail)



What is Not Included in the DMARC Aggregate Report

  1. Trends across ISPs: Identifying trends on IP addresses reporting across different ISPs is a great way to troubleshoot authentication issues and help ensure your legitimate email is getting delivered. However, aggregate reports do not contain trends. Your organization must have the capacity (or work with an organization that does) to analyze bulk data across many different aggregate reports to glean actionable insights.
  2. Sender Score (reputation data): If an authentication failure is due to an IP address not within your infrastructure (e.g. belongs to a third-party sending email on your behalf), you will have to do additional research on the reputation of that IP address to determine whether or not it is a legitimate sender. Return Path’s Sender Score tool can help.
  3. Message samples: Aggregate reports do not contain message-level data. Forensic reports do. If you identify a dubious IP address within an aggregate report and need to find message-level data to troubleshoot it, you have to search both the aggregate and forensic report and make those connections manually.
  4. Alerting capabilities: Once you move your domain to reject, you want to ensure your legitimate mail is not negatively affected by the new policy. Since aggregate reports do not contain trend data, there is no way to tell if your legitimate messages are getting blocked in bulk due to the reject policy.

As you can see, the information not included in DMARC reports is just as, if not more, important than the data that is included. Data is just data until you can organize it in a way that provides value. Working with a partner like Return Path can deliver value with comprehensive and digestible insights into your sending domains’ policy readiness and performance.

In part 2, I’ll walk you through how to read your DMARC forensic reports. And contact us now if you want help making sense of your DMARC reports.



minute read

Popular stories



BriteVerify email verification ensures that an email address actually exists in real-time


The #1 global data quality tool used by thousands of Salesforce admins


Insights and deliverability guidance from the only all-in-one email marketing solution

GridBuddy Cloud

The most productive user experience in the Salesforce ecosystem

Return Path

World-class deliverability applications to optimize email marketing programs

Trust Assessments

A revolutionary new solution for assessing Salesforce data quality


Email deliverability, design, validation, DMARC, and analytics, all in one.


Validity for Email

Increase inbox placement and maximize subscriber reach with clean and actionable data

Validity for Data Management

Simplify data management with solutions that improve data quality and increase CRM adoption

Validity for Sales Productivity

Give your sales team back hours per day with tools designed to increase productivity and mitigate pipeline risks in real-time