If you publish a DMARC record, you receive two types of reports—aggregate and forensic—that contain valuable authentication data. But making sense of that data can be tough.
Last month, we reviewed how to read your first DMARC aggregate reports. Today, we’ll dive into how to read your first DMARC forensic reports.
What are DMARC forensic reports?
In addition to providing information about which emails are authenticating against SPF, DKIM, and DMARC (as aggregate reports do) forensic reports include additional information such as the subject line and header information as well as, most importantly any URLs (URIs) included in the message.
Forensic reports are delivered on a smaller scale than aggregate reports—they’re generated by email providers almost immediately after detecting a DMARC authentication failure. Intended to give you sample detail and evidence of an issue, forensic reports may contain message-level data, “To” and “From” email addresses, and the IP addresses of the sender.
How to request DMARC forensic reports
To start collecting forensic data on your email, publish a simple DMARC record in monitor mode (tag: p=none) with a request for forensic reports (tag: ruf=mailto:[email protected]).
Need help creating DMARC record? This blog post along with our DMARC Creation Wizard will help you build one.
Once your DMARC record is in place, participating mailbox providers will send forensic reports in real time to the destination you defined in the RUF tag.
What is included in forensic DMARC reports
Below is an overview of what is and what is included in these DMARC forensic reports:
Here’s an example of what they look like:
What is not included in DMARC forensic reports
Here is what is not included in the DMARC forensic report:
Trends across ISPs: As with aggregate reports, your organization must have the capacity to analyze the data received across ISPs to identify trends such as subject line similarities and URLs across all the reporting ISPs.
Sender Score (reputation data): Again as with aggregate reports, while the sending IP is reported, the reputation of that IP is something you will have to investigate further as it is not outlined in the forensic report. Return Path’s Sender Score tool can help you do it.
Automatic URL Transfer: Chances are, if you have having phishing issues within your organization you are working with a takedown provider who can work to shut down malicious sites purporting to be from your brand. While the forensic reports will include those URLs, they will not ship directly to your takedown provider.
Alerting capabilities: Because forensic reports are sent in real time they can help to identify a phishing attack faster than aggregate reports. If you receive a forensic report for a domain that is not being used to send legitimate traffic, you’ll want to know about it right away so that you can protect that domain ASAP. Similarly, if you are having authentication issues that are causing legitimate mail from your domain to not be delivered, you’ll want to be made aware of that before it affects your mail on a wider scale.
As we discussed in part one of this series, the reports themselves do not give you everything you need to protect your customers and employees from phishing.
But working with a partner like Return Path can equip you with actionable insights into your sending domain policies and performance, allowing you to make informed authentication decisions.
Contact us now if you want help making sense of your DMARC reports.