This article will help to clarify what types of data are being collected by our platform.
dmarcian Data Processing
The two forms of feedback reports (Aggregate and Forensic) that DMARC can provide are very different.
Domain owners are afforded a great deal of control over both the types, conditions and destination they would like DMARC reports delivered to. Domain owners should be intimately aware of their related policies in sharing ‘any’ type of data with external 3rd parties.
When interpreting how those policies should be applied to DMARC, its is recommended that the domain owner understand in great detail the different report types and under which conditions having readily available access to this data can aid in bringing about improved security, visibility and control.
This document aims to describe and illustrate the various report types and context for how to establish value each against each type.
Aggregate Reports
These XML-based aggregate reports are generated on a 24 hour cycle and include comprehensive statistics on how an email receiver sees your domain being used — including all email that fully passed DMARC. No personally Identifiable Information (PII) is included within these report types.
Aggregate Reports are consumed by the dmarcian application and presented in canned, meaningful report views so that domain owners can quickly identify authentication successes, gaps and statistical evidence to support findings. It is common for anyone who is embarking on a DMARC project to enable Aggregate Reports.
Of note, most all of the major mailbox providers emit Aggregate Reports (the same cannot be said about Forensic Reports, more info below). This dmarcian provided resource illustrates reporting activity by provider: https://us.dmarcian.com/dmarc-data-providers/
Visual representation of an Aggregate Report:
https://codeshare.io/amvXnw
Forensic Reports
The second kind of feedback consists of redacted copies of individual emails that failed SPF, DKIM or both. These reports are rarely available due to privacy concerns, volume concerns, or the view that they’re not required to get DMARC deployed accurately.
There are 3 primary reasons why report generators do not send them:
-
Privacy concerns: Even though the reports can be redacted, some report generators do not send them simply to avoid any issue related to privacy. That is, the individual Forensic/Failure reports can contain Personally Identifiable Information (PII), and some major email receivers are incredibly sensitive to any potential privacy-related issues.
-
Volume: Generating Forensic/Failure reports can result in the generation of a huge amount of email… one inbound email can cause one Forensic/Failure report to be generated. If a system is the target of a botnet-based attack, it might end up generating hundreds of thousands or even millions of Forensic/Failure reports. This ends up utilizing real resources.
-
Not Required: Organizations have demonstrated an ability to deploy DMARC without having access to Forensic/Failure reports. In fact, some organizations do not even ask for Forensic/Failure reports due to privacy concerns… if they’re not enabled, there is no chance of accidentally introducing privacy-based liability
Today, Forensic/Failure reports mainly come from NetEase, LinkedIn, and a few smaller sites. Therefore, if someone spoofs your domain in emails that are delivered to any of these receivers, you’ll get Forensic/Failure reports. If the spoofing is flowing into environments such as Google, Yahoo, or Microsoft, you won’t get any insight from Forensic/Failure reports as those entities and many others do not generate them.
Visual representation of a Forensic Report:
https://codeshare.io/5NdQL1
In some cases, more complete message bodies can be included.
dmarcian has aided a great number of organizations reach their stated DMARC project goals withOUT enabling forensic reports. The concern over privacy around forensic reports is real and warranted.
