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
2. A line-by-line description of your DMARC record, including:
- Header domain/friendly from domain (in the example below it is “returnpath.com”)
- 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)
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
- 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.
- 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.
- 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.
- 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.