What DMARC tag specifies the reporting format for failure reports?
Michael Ko
Co-founder & CEO, Suped
Published 19 Nov 2024
Updated 2 Nov 2025
6 min read
When you implement DMARC, you gain valuable insights into how your domain's emails are performing and whether they are being spoofed. A critical component of DMARC's reporting capabilities involves failure reports, also known as forensic reports. These reports provide detailed information about individual emails that fail DMARC authentication, which is crucial for identifying and mitigating malicious activity. To control the format in which these detailed failure reports are sent, DMARC includes a specific tag.
The DMARC tag that specifies the reporting format for failure reports is the rf tag. This tag allows you to dictate the structure and content of the forensic reports you receive, helping you to integrate them more effectively with your security systems. Understanding and correctly configuring the rf tag is a key step in leveraging DMARC for comprehensive email security.
While aggregate reports (rua) provide a high-level overview of email traffic, forensic reports (ruf) offer granular detail about individual authentication failures. This distinction is vital for incident response and threat analysis. If you're looking for more details on the forensic reports themselves, you can check out what information is contained in DMARC reports.
The 'rf' tag explained
The rf tag, when included in your DMARC record, tells reporting organizations which format to use when sending forensic reports. These reports contain sensitive information, often including email headers and snippets of the message body, which is why they are typically sent with caution and often suppressed by Mailbox Providers by default due to privacy concerns. The primary purpose of these reports is to provide you with granular data to analyze why specific emails failed DMARC, helping you pinpoint misconfigurations or malicious attempts to spoof your domain.
By default, if you don't specify the rf tag, the reporting format defaults to afrf. This is the most common and widely supported format. It stands for Authentication Failure Reporting Format, and it's designed to be easily parseable by automated systems, which makes it ideal for DMARC monitoring tools. You can learn more about the purpose of the 'rf' DMARC tag to get a deeper understanding of its utility.
While useful, it's important to remember that not all Mailbox Providers (ISPs) send forensic reports, even if requested. Privacy concerns and the potential for these reports to contain sensitive data often lead to their suppression. However, when they are sent, the rf tag ensures that the data you do receive is in a format you can readily use for analysis, often within a DMARC monitoring platform like Suped.
Available reporting formats: AFRF and IODEF
There are two primary reporting formats specified by the rf tag, though afrf is far more common. These formats dictate how the forensic data is structured within the report, impacting how easily it can be processed and understood. Let's delve into each one.
AFRF (Authentication failure reporting format)
This is the default and most widely adopted format for DMARC forensic reports. AFRF reports are sent as multi-part MIME messages, typically compressed with GZIP. They include the full email headers of the failed message, which can be invaluable for debugging authentication issues and understanding the context of a spoofing attempt. The format is defined in RFC 6591.
Email headers: Contains the full set of original headers from the failed email, including From, To, Subject, and authentication results.
Limited body content: Some Mailbox Providers may include a truncated portion of the email body, which helps in identifying the specific content being spoofed.
IODEF is a more general-purpose format for exchanging incident information, defined in RFC 5070. It is XML-based and offers a highly structured way to describe security incidents. While DMARC supports IODEF as a reporting format for failure reports, it is rarely implemented by Mailbox Providers for this purpose. The complexity of IODEF compared to AFRF makes it less practical for the specific needs of email authentication failure reporting.
Structured data: Designed for machine processing, IODEF provides a detailed, structured representation of an incident.
Less common for DMARC: Due to its generic nature and complexity, IODEF is not commonly used or supported for DMARC forensic reports.
In practice, you will almost exclusively encounter AFRF formatted reports if forensic reports are sent at all. This means focusing your DMARC setup and monitoring tools on processing AFRF data effectively.
Implementing the 'rf' tag
Implementing the rf tag is straightforward. You include it as part of your DMARC DNS TXT record, alongside other essential tags like v (version), p (policy), and rua (aggregate report URI). Remember that you will also need the ruf tag to specify the email address where these reports should be sent. If you're setting up DMARC for the first time or need a refresher, check out our guide to a simple DMARC setup.
In this example, rf=afrf explicitly requests forensic reports in the AFRF format. If you were to omit the rf tag, afrf would still be the default. However, explicitly stating it can sometimes help ensure consistent reporting across different Mailbox Providers, although their individual policies on sending forensic reports will ultimately govern whether you receive them.
Why the reporting format matters
The choice of reporting format for failure reports, while often defaulting to AFRF, holds significance for your email security posture. These reports provide the raw data needed to understand the specifics of DMARC authentication failures. Without this granular detail, it can be challenging to diagnose complex issues, especially when dealing with advanced phishing or spoofing attacks. Having a clear format ensures that if you do receive these reports, they can be processed by your systems or DMARC monitoring solution.
For instance, if your DMARC record is set to a more restrictive policy like p=reject, forensic reports can alert you to legitimate email streams that might be unexpectedly failing DMARC. This allows you to quickly adjust your SPF or DKIM configurations. Suped's AI-Powered Recommendations can analyze these reports and suggest actionable steps to fix issues, even if you are not directly parsing these reports yourself. We can also provide real-time alerts so you know exactly what is happening with your email ecosystem and when.
Important DMARC reporting considerations
Data sensitivity: Forensic reports can contain sensitive information. Ensure your designated ruf URI is secure.
ISP support: Many Mailbox Providers do not send forensic reports due to privacy concerns, regardless of your rf tag setting. Aggregate reports are far more common and reliable. We recommend monitoring DMARC reports from Google and Yahoo specifically.
Tooling: A good DMARC monitoring platform like Suped is essential to effectively interpret DMARC reports for both aggregate and forensic data, providing actionable insights.
Final thoughts on DMARC reporting
The rf tag plays a specific, though sometimes underutilized, role in your DMARC implementation. While aggregate reports offer the broadest view of your email traffic, forensic reports, when available and correctly formatted via the rf tag, can provide crucial debugging information.
For complete visibility into your email ecosystem and to maintain strong email deliverability, it's essential to implement DMARC correctly and monitor its reports diligently. Suped offers a unified platform for DMARC, SPF, and DKIM monitoring, alongside blocklist and deliverability insights. Our generous free plan makes DMARC accessible to everyone, helping you protect your domain from spoofing and ensure your emails reach the inbox.
In practice, you will almost exclusively encounter AFRF formatted reports if forensic reports are sent at all. This means focusing your DMARC setup and monitoring tools on processing AFRF data effectively.
explicitly requests forensic reports in the AFRF format. If you were to omit the rf tag, afrf would still be the default. However, explicitly stating it can sometimes help ensure consistent reporting across different Mailbox Providers, although their individual policies on sending forensic reports will ultimately govern whether you receive them.
