Blog
DMARC Reports: Embrace Them! (Part II)
Last week, in Part I of our series on DMARC reports, we discussed their value and importance. This week, we’re going to focus on the two types: aggregate and forensic.
Aggregate Reports
Aggregate reports are the most important and contain information of the authentication status for SPF, DKIM, and DMARC. Setting up your policy to send aggregate reports is simple – just add the RUA tag to your DMARC policy.
Here is an example of what your policy can look like sending to multiple addresses:
But they do contain the below information:
(We have marked the information in the example provided below)
Generally, these reports are extremely difficult to read as they are sent in XML format, there are free and paid services that can help translate these into human readable format.
This is how aggregate reports may be presented when using a reporting service. As we can see in the below image there are 6 emails being shown in this report.
The black arrows show the DKIM and SPF show DKIM and SPF aligned and passing as the domains match the return path domain indicated by the blue arrows.
Forensic reports
Forensic reports are sometimes referred to as failure reports.
These reports are not actual reports. They are the full blown message that was sent and will contain the subject line, header information, message body, and in some cases the attachment.
The benefit of these reports is that they provide more insight as to which messages were marked as suspicious and why. However, because they are so deep with information, they can pose a privacy risk. This is why many organizations do not send forensic reports.
Below is an example of a forensic/failure report:
The domains and IP addresses of the sending systems should (hopefully) all be authorized systems, which should match the IT/email administration inventory list. If anything is not on their list, then it’s either an email service not known by the team (thus improving IT asset inventory), or those domains/IP addresses are spammers and/or phishers. Knowing the spammers/phishers is beneficial as well, because that data that can be used for cyber intel and spam blocklists.
The final blog in this three-part series will focus on the analysis of DMARC reports. Stay tuned!
