How to set up DMARC reports and what are the best practices?
Matthew Whittaker
Co-founder & CTO, Suped
Published 15 May 2025
Updated 17 Aug 2025
8 min read
Implementing DMARC is a crucial step in protecting your domain from email spoofing and phishing attacks. It provides a robust framework for email authentication, building upon SPF and DKIM to give domain owners more control over how unauthenticated emails are handled by receiving mail servers.
However, DMARC's true power lies not just in its ability to tell receivers what to do with suspicious emails, but in the comprehensive reports it generates. These reports offer invaluable insight into your email ecosystem, revealing legitimate sending sources, identifying unauthorized use of your domain, and helping to diagnose deliverability issues. Without these reports, DMARC is essentially a blind protocol, and you lose out on the intelligence needed to truly secure your email.
In this guide, I will walk you through the process of setting up DMARC reports and share the best practices for using the data to strengthen your email security and ensure optimal deliverability. We will cover everything from initial record creation to effective report analysis, ensuring you can leverage DMARC to its fullest potential.
The foundation of DMARC reporting lies in your DMARC DNS TXT record. This record, which you publish in your domain's DNS settings, includes specific tags that instruct receiving mail servers where to send the authentication reports. The two primary tags for reporting are rua for aggregate reports and ruf for forensic (failure) reports. Here is an example of a DMARC record, including these reporting tags:
Before you even think about publishing a DMARC record, ensure that you have properly configured SPF and DKIM for all your sending sources. DMARC relies on these two authentication methods to align with your domain. Without proper SPF and DKIM setup, DMARC will not function as intended, and you risk legitimate emails failing authentication. Allow at least 48 hours for SPF and DKIM records to propagate before setting up DMARC. This is a crucial step recommended by major email providers like Microsoft and Google.
The rua and ruf tags specify the email addresses where DMARC reports should be sent. While the email address can be on a different domain than the one being DMARC-ed, it requires a referral record on the receiving domain to grant permission. Using a DMARC reporting service simplifies this process, as they automatically handle the necessary configurations to receive and parse these complex XML reports. You can generate your DMARC record using a free DMARC record generator tool.
Understanding DMARC reports
DMARC generates two main types of reports: aggregate reports (RUA) and forensic reports (RUF). Each type serves a distinct purpose in providing visibility into your domain's email traffic.
Report Type
Content
Frequency
Use Case
Aggregate (RUA)
XML format, showing statistics about email volume, senders, DMARC authentication results (pass/fail), and policies applied. Data is aggregated by source IP and domain.
Typically daily, but can vary by receiving server (ISP).
High-level overview of email flows, identifying all sending sources and their compliance. Essential for initial DMARC setup and ongoing monitoring. ISPs often include a source identifier in reports.
Forensic (RUF)
Detailed reports about individual email failures, including headers, sending IP, and sometimes snippets of the email body. Often redacted for privacy reasons.
Immediately upon failure, but rarely sent by major ISPs due to privacy concerns and potential for abuse.
Useful for deep dives into specific spoofing attempts or authentication failures, though less common due to privacy limitations. It can help diagnose DMARC failures.
The raw DMARC reports, especially aggregate reports, are sent as large XML files. Manually reading and interpreting these files is incredibly time-consuming and challenging, if not impossible, for domains with significant email volume. The data is highly technical, making it difficult to extract actionable insights without specialized parsing tools or services.
Best practices for DMARC policy enforcement
When deploying DMARC, the universally recommended best practice is to start with a policy of p=none. This is a monitoring-only policy that instructs receiving servers not to take any action on emails that fail DMARC authentication, but still send you reports. This initial phase is critical for gathering comprehensive data on all email streams originating from your domain, both authorized and unauthorized, without impacting legitimate email delivery. It allows you to identify all your email sending sources, including marketing platforms, transactional email services, and internal systems, and ensure they are properly authenticated with SPF and DKIM. See simple DMARC examples for how to get started.
After a period of monitoring with p=none, and once you are confident that all your legitimate email traffic is passing DMARC authentication, you can gradually transition to stronger enforcement policies: p=quarantine or p=reject. p=quarantine suggests that receivers place non-compliant emails in the spam or junk folder, while p=reject instructs them to block these emails outright. A phased approach allows you to detect and rectify any unforeseen issues before fully enforcing your policy and potentially disrupting legitimate email flows. You can find best practices for setting DMARC policy in our other guides. The goal is to eventually reach p=reject to maximize protection against impersonation.
Gradual DMARC enforcement
Start with p=none: Monitor your email traffic without enforcing any policy. Use this period to identify all legitimate sending sources.
Move to p=quarantine: Once you are confident in your sending sources, move to quarantine policy to soft-block unauthorized emails.
Finally, p=reject: After successful quarantine monitoring, transition to reject for full protection against spoofing. Learn how to safely transition.
Continuous DMARC monitoring is not a one-time setup. Email sending infrastructure changes, new marketing platforms are adopted, and cyber threats evolve. Regularly reviewing your DMARC reports helps you quickly detect any new unauthorized sending activity or configuration issues that might impact your email deliverability. This proactive approach ensures your DMARC policy remains effective and your domain reputation stays strong.
Managing and analyzing DMARC reports effectively
As mentioned, raw DMARC reports are sent as XML files, often compressed. These files can be large and contain complex data that is difficult for humans to read and interpret manually. Imagine receiving hundreds or thousands of these reports daily from various Internet Service Providers (ISPs), each in a slightly different format. Trying to make sense of this data without proper tools is an overwhelming task that consumes excessive time and resources.
This is where DMARC report analyzers become indispensable. These services automatically collect, parse, and present your DMARC report data in an easy-to-understand, visual format. They provide dashboards that highlight key metrics, identify unauthorized senders, pinpoint authentication failures, and show the volume of emails passing or failing DMARC. This allows you to quickly identify issues, understand your email traffic patterns, and make informed decisions to improve your email security. Many free DMARC reporting services are available.
Manual analysis challenges
XML complexity: Raw DMARC reports are in XML format, which is not human-readable.
Time-consuming: Manually parsing and aggregating data from numerous reports is highly inefficient.
Difficult trend spotting: Hard to identify patterns, rogue senders, or long-term trends.
No real-time alerts: You won't be alerted to new threats or issues as they occur.
Automated analysis benefits
Human-readable dashboards: Data is presented clearly with charts and graphs.
Real-time insights: Quickly see email traffic and authentication results as they happen.
Automated alerts: Receive notifications for suspicious activity or policy failures.
Easy issue identification: Quickly identify rogue mail streams, spoofing attempts, or legitimate emails that are failing authentication.
While most ISPs send aggregate reports, the frequency and completeness of these reports can vary. Some major providers might send daily, others less frequently, and some might not send forensic reports at all due to privacy concerns. Relying solely on individual reports from various ISPs would make comprehensive monitoring impractical. Using a dedicated DMARC report analyzer provides a consolidated view, making the data manageable and actionable. It helps you keep track of your domain's sending reputation and detect any issues that could lead to your emails being marked as spam or even getting your domain added to a email blacklist or blocklist.
Views from the trenches
Best practices
Always start with a DMARC policy of p=none to monitor all email traffic and identify legitimate sending sources before enforcing any policy.
Ensure SPF and DKIM are properly configured and aligned for all email sending sources before publishing your DMARC record.
Utilize a DMARC reporting service to parse and visualize your aggregate reports, making the data actionable and easy to understand.
Gradually transition your DMARC policy from p=none to p=quarantine, and eventually to p=reject, monitoring reports at each stage.
Common pitfalls
Failing to implement DMARC reports, leading to blind implementation and missing valuable insights into email traffic and spoofing attempts.
Attempting to manually parse and analyze raw XML DMARC reports, which is inefficient and impractical for any significant email volume.
Jumping straight to p=quarantine or p=reject policies without prior monitoring, risking legitimate email blockage.
Neglecting to monitor DMARC reports regularly after initial setup, missing new unauthorized senders or infrastructure changes.
Expert tips
Consider a wildcard referral record if you're managing DMARC reports for multiple domains yourself, making setup easier for the destination domain.
Prioritize real-time report analysis to quickly spot anomalies like rogue mail streams or forgeries, as retrospective analysis is often too late.
Be aware that receiving DMARC reports to a different domain requires a referral record on the destination domain, a step often handled automatically by DMARC service providers.
Understand that DMARC reports are sent as compressed XML files, making a standard mailbox unsuitable for receiving and managing them.
Marketer view
Marketer from Email Geeks says the `rua=mailto` email address does not have to match the domain you are DMARC-ing, but if you are handling it yourself, you will need a referral record.
2024-01-18 - Email Geeks
Marketer view
Marketer from Email Geeks says it is not practical to manually read tons of XML files, even if you are intimately familiar with DMARC. Sending them to a free service that clearly tells you what is happening is much better.
2024-01-18 - Email Geeks
Protecting your email ecosystem with DMARC reports
Setting up DMARC reports is not just a technical requirement, it is a strategic imperative for any organization serious about email security and deliverability. These reports provide the transparency needed to understand your email landscape, identify potential threats, and ensure your legitimate emails reach their intended recipients. By diligently setting up and analyzing your DMARC reports, you gain crucial insights that empower you to protect your brand, maintain trust with your audience, and safeguard your email communications from sophisticated attacks.
Embracing DMARC and its reporting capabilities is a continuous journey. Start with a monitoring policy, use a reliable reporting service, and evolve your enforcement as you gain confidence. This proactive approach will significantly enhance your domain's email security posture and contribute to a healthier email ecosystem overall. It's a fundamental step in ensuring your messages land in the inbox, not the spam folder, and that your brand remains protected from email-based attacks.
