DMARC is the most efficient tool you can get to protect your domain. All your communications are more secure once you implement DMARC records using a DMARC record generator for your domain. The enforcement of DMARC policies prevents spoofing attacks. You also get the full scope of your communications and see how your emails perform. To better understand this procedure, you rely on DMARC reports, including DMARC forensic reports.
A properly configured DMARC policy sends two specific report types: aggregate reports, which offer aggregate summaries of all email activity, and DMARC forensic reports, which provide a quick notification when an authentication failure occurs. They include details about the type of failure: it can be due to infrastructure problems, lack of verification from the ESP, and other assorted reasons.
What a DMARC Forensic Report Contains
A DMARC forensic report is also commonly known as a DMARC failure report. Both terms refer to the same message-level report that provides details about an individual email that failed DMARC authentication. Unlike aggregate reports, DMARC forensic reports are generated soon after a failure when the receiving server supports them, and sent to the URI specified in the “ruf” tag of your domain’s DMARC record.
The average forensic report contains the following fields:
- Email address of the recipient (the email to which the original message was for)
- SPF and DKIM authentication results
- Time of reception
- DKIM signature
- Host
- Subject of email
- Message ID of the email
- Other headers
Here’s an example:
When Do You Receive a Failure Report?
DMARC forensic reports can include message-specific details about an email that failed verification. They may contain sensitive information, but they have every scrap of data to help you understand why the authentication failed. You can request DMARC forensic reports by configuring the “ruf” and “fo” tags in your DMARC record and specifying the email address where reports should be sent.
DMARC Forensic Report Tags: How to Request Forensic Reporting?
As you explore DMARC forensic reporting options, you’ll find that the “ruf” and “fo” tags are used to request forensic reports in the DMARC record. Here’s what each one of them does with your rejected messages:
- ruf: this optional tag is a designation that indicates the email address where message-specific failure reports are sent. Most of this data is presented as a plain text URI. The usual ruf tag looks like this: “ruf=mailito:[email protected].”
- fo: the option tag that indicates the value of each DMARC failure for a domain. The tag also defines the type of report you get based on specific verification requirements.
- fo=0 is used when both SPF and DKIM fail authentication or alignment, so the message doesn’t produce an aligned DMARC pass.
- fo=1 can be used when SPF or DKIM fails authentication or alignment, regardless of whether that failure was decisive for the overall DMARC result.
- Regardless of the alignment, fo=d can be used when the DKIM signature fails.
- fo=s can be used when the SPF record fails to align with the domain.
Failure Reports: Pros and Cons
DMARC forensic reports have faced their fair share of criticism. Critics often mention that these reports offer too much raw data that is difficult to understand if you’re a newcomer to DMARC. Some people think only some elements of DMARC are as valuable as they may seem.
Aggregate reports provide a condensed portion of data to help you understand your sources and configure DMARC for your domain. Forensic reports, on the other hand, offer data in real-time so you can fix any issues on the go.
Pros
- More detailed than aggregate reports: A DMARC forensic report includes message-level data that helps explain why a specific email failed authentication.
- Faster issue visibility: Forensic reports may arrive soon after authentication failures when supported, helping teams investigate specific messages sooner.
- Useful for targeted troubleshooting: Forensic reports can help teams review individual failures instead of relying only on aggregate patterns.
Cons
- Limited mailbox provider support: Many providers do not support DMARC forensic reports, and report formats can vary across email service providers.
- High report volume: Forensic reports can arrive individually after failures, which may overwhelm teams managing many domains or sending sources.
- Sensitive data exposure: These reports may include personally identifiable information or message-level details that need careful handling and access control.
- Limited ecosystem view: Forensic reports focus on individual failures, so aggregate reports are still needed for broader domain visibility.
Best Practices for DMARC Forensic Reporting
If you choose multiple URIs for DMARC forensic reports, reports may be sent to those destinations when supported. Depending on how many emails fail DMARC in your ecosystem, the result could be an onslaught of reports in minutes. Going through all of them is almost impossible by human standards, but you can put some control in place to limit the reporting process. These are some of the best strategies for handling forensic reports:
Limit Sending the Report Only to the First Recipient
Limiting one report to the first recipient means you won’t get duplicate reports in all your URIs. This can help you focus better on the issues affecting your DMARC protocol.
Group Reports and Bulk-Deliver
You can store DMARC forensic reports for specific periods before sending them. This makes detecting delivery issues easier by allowing the collection and reporting of similar incidents easier.
Limit the Number of Failure Reports Sent Per Minute
This is one of the main reasons why ISPs are phasing out DMARC failure reports. Anyone with enough knowledge about handling the data contained in these reports can get a ton of Personally Identifiable Information from them.
It’s Hard to See the Full Picture of Your Domain Ecosystem
Aggregate reports offer a cohesive view of your domain’s email ecosystem. You can understand what’s working and what’s failing with them. However, if you limit yourself only to DMARC failure reports, you won’t know where to look. You are more likely to oversee something vital because you’re paying attention to one failed email at a time.
Best Practices for DMARC Failure Reporting
If you choose multiple URIs to get your DMARC failure reports, your DMARC record will happily comply. Depending on how many emails fail DMARC in your ecosystem, the result could ba an onslaught of reports in minutes. Going through all of them is almost impossible by human standards, but you can put some control in place to limit the reporting process. These are some of the best strategies for handling failure reports:
Limit Sending the Report Only to the First Recipient
Limiting one report to the first recipient means you won’t get duplicate reports in all your URIs. This can help you focus better on the issues affecting your DMARC protocol.
Group Reports and Bulk-Deliver
You can store failure reports for specific periods before sending them. This makes detecting delivery issues easier by allowing the collection and reporting of similar incidents easier.
Limit the number of Failure Reports Sent Per Minute
You can apply a limiting rate to the number of reports sent by the minute. That way, you won’t get overwhelmed and can take time to see relevant data on each report, as the system will discard anything else.
DMARC Aggregate Reports Vs. DMARC Forensic Reports
This blog post mentioned aggregate reports as the broader summary counterpart to DMARC forensic reports. Both have features that make them worthy of paying attention to. They also have specific purposes, but the closer you look at them, the more you realize how different they are from each other. Here’s a comparison:
| Aggregate reports | Failure reports |
| To receive reports, the rua tag must be set up | To receive reports, ruf tag must be set up |
| Provides aggregate data on a group of emails | Provides details of a single email |
| Not real-time, by default, they are sent every day | Sent immediately after failures |
| XML format | Plain text |
| Don’t contain PII (personally identifiable information) | Contain PII |
| Supported in all DMARC-compliant mailbox providers | Supported only in some of the mailbox providers |
The Role of Forensic Reports in a DMARC Strategy
DMARC forensic reports were an early way to investigate message-specific DMARC authentication failures. They had their day in the sun, but they’re going out of fashion these days. Today, support for forensic reports is limited across mailbox providers. Some mailbox providers previously supported forensic reports more broadly, but many now prioritize aggregate reports as the default reporting method.
EasyDMARC can help teams review and understand the data provided by DMARC forensic reports. We can help you improve your DMARC strategy and increase your deliverability rates. Contact us through our website to update your DMARC strategy.
Frequently Asked Questions
A DMARC forensic report, also known as a DMARC failure report, is a message-level report generated when an individual email fails DMARC authentication. It includes details such as the recipient address, authentication results, and message headers for that specific email. Unlike aggregate reports, forensic reports focus on a single failure rather than a summary of your domain’s overall email activity.
To receive forensic reports, add the “ruf” tag to your DMARC record with the destination email address, and configure the “fo” tag to define which failure conditions trigger a report. EasyDMARC’s DMARC Record Generator helps you build this syntax correctly, reducing the risk of misconfigured tags that prevent reports from reaching your inbox.
Aggregate reports summarize authentication results across all emails sent from your domain and arrive on a set schedule, typically once every 24 hours. Forensic reports cover a single email and are generated soon after a failure, when the receiving server supports them. Aggregate reports use XML format and contain no sensitive data; forensic reports are plain text and may include personally identifiable information.
No. Support for forensic reports is limited across mailbox providers, and coverage has narrowed over time. Some providers that once generated them now prioritize aggregate reporting instead. Because of this inconsistent support, forensic reports should be treated as a supplementary data source rather than the primary method for monitoring domain-wide authentication activity.
No. Aggregate reports provide the visibility needed to move your policy toward enforcement, and many organizations reach p=reject without ever configuring the “ruf” tag. Forensic reports add message-level detail for investigating specific failures, but enforcement decisions typically rely on patterns visible in aggregate data rather than individual forensic notifications.
A typical forensic report includes the recipient’s email address, SPF and DKIM authentication results, the time of reception, the DKIM signature, the sending host, the message subject, the message ID, and other headers. Because these fields can include personally identifiable information, teams should limit access and apply appropriate handling controls when reviewing forensic report data through the EasyDMARC platform.
Domains with high send volume or frequent authentication failures can generate a large number of forensic reports, since each one covers a single email. To manage this, you can send reports to only the first configured recipient, group and bulk-deliver reports over set intervals, or apply a limit on reports sent per minute. These controls keep review manageable without discarding investigative context.
We’re glad you joined EasyDMARC newsletter! Get ready for valuable email security knowledge every week.
You’re already subscribed to EasyDMARC newsletter. Continue learning more about email security with us
