What are the requirements for RUA and RUF in DMARC policies?
Michael Ko
Co-founder & CEO, Suped
Published 4 May 2025
Updated 17 Aug 2025
8 min read
When setting up DMARC (Domain-based Message Authentication, Reporting, and Conformance), many people wonder about the necessity of the RUA and RUF tags. These tags are crucial for gaining visibility into your email ecosystem, but their requirements and practical utility differ significantly. Let's explore what RUA and RUF entail and why one is generally considered more vital than the other for successful email deliverability and security.
DMARC helps protect your domain from impersonation and phishing by instructing receiving mail servers how to handle emails that fail authentication checks (SPF or DKIM). A key part of its functionality is the reporting mechanism, which provides feedback on your domain's email traffic. This feedback is delivered through RUA and RUF reports.
While not strictly mandatory for a valid DMARC record to exist, these reporting tags, particularly RUA, are essential for monitoring and enforcing your email policy effectively. Without them, you would essentially be operating your DMARC policy in the dark, unable to identify legitimate email sources or detect unauthorized sending from your domain.
RUA stands for "Reporting URI for Aggregate Reports." These reports are XML documents that summarize your domain's email activity. They provide high-level data about emails purporting to be from your domain, including: the sending IP address, the number of messages sent, the results of SPF and DKIM authentication, and whether DMARC alignment passed or failed. You can see examples of what this data looks like if you know where to find example DMARC RUA reports.
RUF, on the other hand, stands for "Reporting URI for Forensic Reports," also known as failure reports. These reports are designed to provide more detailed information about individual emails that failed DMARC authentication. Ideally, they would include sanitized copies of the failed messages, including headers and potentially even partial body content. This data could theoretically help identify the source of fraudulent emails.
While both provide valuable insights, the practical implementation and utility differ significantly. RUA reports are widely adopted and sent by most major email providers. They are the cornerstone of DMARC monitoring. RUF reports, however, are rarely sent by email receivers due to privacy concerns, as they can inadvertently expose sensitive recipient information. The DMARC RFC 7489 itself notes that forensic reports might be constrained or omitted.
Why RUA reports are crucial
Aggregate reports give you the broad overview needed to understand your email landscape. They help you:
Identify legitimate senders: See which services are sending email on behalf of your domain and ensure they are properly authenticated.
Detect unauthorized activity: Spot spoofing attempts or misconfigured senders that are failing DMARC.
Monitor policy impact: Understand how your DMARC policy (p=none, p=quarantine, or p=reject) is being applied by receivers.
The role of RUA and RUF in your DMARC policy
To directly address the question, neither RUA nor RUF are strictly "required" for a DMARC record to be syntactically valid. You could publish a DMARC record without either tag, and it would technically work. However, doing so means you would receive no feedback on your email traffic, making DMARC significantly less effective as a security and monitoring tool. For context, you might be interested to know whether DMARC is required for mail sending domains at all, or required by Mailgun and Yahoo.
When it comes to recent sender requirements, such as those from Google and Yahoo, the emphasis is placed on the implementation of DMARC itself, with an explicit strong recommendation for including the RUA tag. They want senders to have visibility into their email streams. While they don't explicitly require RUA, it's considered a fundamental part of proper DMARC deployment.
For the new DMARC requirements for 2024 and beyond, the focus remains squarely on DMARC adoption and the ability for senders to monitor their email. This strongly implies that RUA is the critical component. RUF reports, given their inherent privacy challenges and inconsistent support from receivers, are not typically part of these baseline requirements.
RUA: Aggregate reports
These reports provide a daily or hourly summary of all email traffic observed from your domain, whether authenticated or not. They are crucial for initial DMARC setup and ongoing monitoring.
Data content: Includes sending IPs, message volumes, SPF/DKIM authentication results, and DMARC policy application. Crucially, they do not contain sensitive personally identifiable information (PII).
Purpose: Gives you a holistic view of your domain's email ecosystem, helping you to identify all legitimate sending sources and monitor for unauthorized usage.
Support: Widely supported by almost all mailbox providers.
RUF: Forensic reports
These reports aim to provide detailed forensic data for individual messages that fail DMARC authentication. They are designed to help you analyze specific email failures.
Data content: Could include message headers, subjects, and partial body content from emails that failed DMARC authentication. However, this often includes PII.
Purpose: Intended for deep dives into specific spoofing incidents or misconfigurations, providing granular details that aggregate reports lack.
Support: Limited support from mailbox providers due to privacy concerns and the difficulty of sanitizing sensitive data. Many simply don't send them.
Implementing RUA and RUF in your DMARC record
To receive DMARC reports, you need to include the RUA and RUF tags in your DMARC DNS record. These tags specify the email addresses where you want the reports to be sent. The format typically uses mailto: followed by the email address.
For example, a basic DMARC record including RUA and RUF might look like this:
You can specify multiple email addresses for RUA and RUF reports by separating them with commas. It is also possible for using the plus sign in the RUA email address. If the reporting address is on a different domain than the DMARC record itself, the receiving domain might need to publish a DMARC record with an adkim or aspf tag to authorize report reception. This is outlined in the DMARC.org FAQ.
It's generally recommended to start with a DMARC policy of p=none to simply monitor your email traffic without affecting deliverability. During this monitoring phase, RUA reports are invaluable for identifying all legitimate sending sources and ensuring proper SPF and DKIM alignment. Once you have a clear picture, you can gradually move to a more restrictive policy like p=quarantine or p=reject. Learn more about when to use these DMARC policies.
Why RUA is generally preferred over RUF
While RUF reports theoretically offer a deeper look into specific failures, their practical utility is severely limited by privacy concerns. Mailbox providers are hesitant to send full forensic reports because they often contain Personally Identifiable Information (PII) of the original recipient, which could violate privacy regulations like GDPR. Even when sent, these reports are often heavily sanitized, rendering them less useful for detailed analysis.
In most cases, the comprehensive overview provided by RUA (aggregate) reports is sufficient for 99.9% of DMARC monitoring needs. They allow you to identify trends, misconfigurations, and sources of unauthorized email. Focusing on maximizing the effectiveness of RUA reporting, often through a DMARC monitoring platform, will provide the most actionable insights for improving your email security posture and ensuring proper email deliverability.
If you are using a dedicated subdomain for email sending with a strict p=reject policy, the immediate need for RUA reports for that specific subdomain might seem less critical. This is because any mail failing authentication from that subdomain would be rejected. However, for your primary domain and other subdomains, RUA reports remain vital for maintaining visibility and control. Understanding what information is contained in DMARC RUA and RUF reports is key to leveraging DMARC effectively.
There are some scenarios where a missing RUA record in your DMARC can cause email blocking by Microsoft domains in particular, highlighting the importance of including them even if not strictly mandatory by specification. This underscores the practical requirement set by major mailbox providers.
Conclusion
While RUA and RUF reports are not technically mandatory for a DMARC record to exist, RUA (aggregate) reports are strongly recommended and practically essential for any domain owner committed to email security and deliverability. They provide the necessary visibility to monitor email traffic, identify legitimate senders, and detect potential threats. RUF (forensic) reports, though seemingly offering deeper insights, are rarely supported by major mailbox providers due to privacy implications, making them less reliable and often unnecessary for most organizations. Prioritize RUA implementation to gain the actionable insights needed to protect your domain.
Views from the trenches
Best practices
Always include an RUA tag in your DMARC record for comprehensive visibility into your email ecosystem.
Use a DMARC monitoring service to parse and visualize RUA reports, making the data actionable and easy to understand.
Gradually increase your DMARC policy from `p=none` to `p=quarantine` or `p=reject` only after analyzing RUA reports to confirm legitimate email sources are authenticated.
Common pitfalls
Omitting both RUA and RUF tags, leading to a 'flying blind' scenario with no visibility into DMARC compliance.
Over-relying on RUF reports for forensic analysis, given their inconsistent and often censored nature from mailbox providers.
Not understanding how to interpret DMARC reports, making them useless even when configured correctly.
Expert tips
If your DMARC policy is set to `p=reject` for a dedicated subdomain, the immediate need for RUA reports for that specific subdomain might be reduced.
While RUF reports are generally rare, some DMARC vendors have special partnerships to receive more detailed forensic feeds.
Ensure that any external domain used for receiving DMARC reports has an appropriate DMARC record to allow report delivery.
Expert view
Expert from Email Geeks says neither RUA nor RUF are strictly required, but RUA is strongly recommended because flying blind isn't a good strategy for DMARC implementation.
2024-01-23 - Email Geeks
Marketer view
Marketer from Email Geeks says almost no one receives RUF reports, emphasizing their limited practical use for most senders.
Google and 
Yahoo, the emphasis is placed on the implementation of DMARC itself, with an explicit strong recommendation for including the RUA tag. They want senders to have visibility into their email streams. While they don't explicitly require RUA, it's considered a fundamental part of proper DMARC deployment.
