How to diagnose DMARC failures using DMARC reports?
Michael Ko
Co-founder & CEO, Suped
Published 27 Apr 2025
Updated 18 Aug 2025
10 min read
Understanding why DMARC authentication fails can feel like a maze, especially when your initial checks suggest everything is configured correctly. You might see messages indicating a DMARC reject policy on a sender domain, yet your own monitoring shows 100% pass rates for SPF, DKIM, and DMARC. This apparent contradiction is common, and it highlights the need for a deeper dive into your DMARC reports. These reports are designed to give you the visibility needed to diagnose and resolve such complex issues, revealing the true authentication journey of your emails.
I’ve learned that the key to unlocking these mysteries lies within the data provided by DMARC reporting. While a basic overview might suggest compliance, the granular details in these reports often point to subtle misconfigurations or unauthorized sending that would otherwise go unnoticed. They are your primary diagnostic tool, offering insights into how various mailbox providers interpret your email authentication records.
Without properly analyzing these reports, you are essentially flying blind, unable to pinpoint the exact reasons for delivery issues, brand impersonation, or unexpected DMARC failures. My aim here is to break down how to effectively use DMARC reports to diagnose and ultimately resolve these challenges, ensuring your legitimate emails reach their intended inboxes.
DMARC leverages two primary types of reports: aggregate reports (RUA) and forensic reports (RUF). Each serves a distinct purpose in helping you understand your email ecosystem and diagnose authentication failures. Aggregate reports offer a high-level overview, while forensic reports provide granular detail on individual messages that failed.
Aggregate reports (RUA) are XML files sent daily by participating mailbox providers to the email address specified in your DMARC record. They summarize email authentication results for your domain, indicating how many messages passed or failed SPF and DKIM checks, the sending sources (IP addresses), and the DMARC policy applied by the receiving server. These reports are invaluable for long-term monitoring and identifying patterns in your email traffic.
Forensic reports (RUF), also known as failure reports, are sent almost immediately when an email claiming to be from your domain fails DMARC authentication. Unlike aggregate reports, RUF reports contain detailed information about each individual failed message, including headers and sometimes even snippets of the message body. This level of detail makes them powerful for pinpointing specific issues or identifying phishing attempts. However, due to privacy concerns, fewer mailbox providers send RUF reports, and they can be challenging to parse manually. You can learn more about DMARC failure reports by reviewing the IETF draft document on the topic.
Report type
Purpose
Frequency
Detail level
Aggregate (RUA)
Summary of authentication results
Daily
High-level overview by source
Forensic (RUF)
Detailed reports on individual failures
Immediate upon failure
Per-message detail (including headers)
To effectively use DMARC for diagnosing failures, you need to enable reporting in your DMARC record. This typically involves adding rua and potentially ruf tags to your DNS TXT record, specifying the email addresses where you want to receive these reports. For a deeper dive into setting up your DMARC record and understanding the various tags, you can explore our comprehensive guide on DMARC tags and their meanings.
Analyzing aggregate (RUA) reports
Aggregate reports are the backbone of DMARC monitoring. While they can seem overwhelming due to their XML format, parsing them allows you to see the big picture of your email authentication. I focus on key metrics to diagnose failures. One crucial element to watch for is the source IP address. Identify all IP addresses listed as sending mail on behalf of your domain. Cross-reference these with your authorized sending services.
Next, pay close attention to the authentication results for SPF and DKIM for each source. A pass result for SPF or DKIM is good, but DMARC also requires alignment. This means the domain in the SPF or DKIM checks must match (or be a subdomain of) the domain in your email's From: header. If alignment fails, DMARC will fail, even if SPF or DKIM technically passed. This is a common pitfall that often leads to confusion. For more information, check out our article on why some emails fail DMARC checks despite proper SPF/DKIM alignment.
Finally, review the policy applied by the receiving server. This shows what action the receiver took on emails failing DMARC (none, quarantine, or reject). Consistent policy applications for failing emails from specific sources indicate ongoing issues. For a comprehensive guide on reading DMARC reports, including aggregate ones, refer to this Mimecast blog on how to read DMARC reports.
Common aggregate report findings
Unexpected sources: Identify sending IPs that are not authorized by you.
Low pass rates: A low percentage of emails passing DMARC from a known source indicates authentication configuration issues.
Alignment failures: Even if SPF or DKIM pass, DMARC will fail if alignment isn't met.
High rejection rates: If your policy is set to reject, monitor for a high volume of rejected mail to prevent legitimate emails from being blocked.
Interpreting forensic (RUF) reports
Forensic (RUF) reports provide the deep dive you need for specific DMARC failures. When an email fails authentication and alignment, a RUF report is generated, containing granular details about that single message. This can include the original email headers, sender and recipient addresses, and the specific authentication results (SPF, DKIM, and DMARC) that led to the failure. This information is critical for understanding the exact point of failure.
By examining the headers within a RUF report, you can identify which authentication mechanism (SPF or DKIM) failed and, more importantly, why. Was it a misalignment issue? Was the sending IP not included in your SPF record? Was the DKIM signature invalid or missing? RUF reports can reveal these precise problems, especially when you are trying to understand why a specific email might have been rejected despite your general DMARC monitoring showing good health.
It’s important to note that RUF reports are not universally supported by all mailbox providers due to privacy concerns, as they can contain sensitive email content. However, for those providers that do send them, they offer an unparalleled view into individual DMARC failures, making them incredibly useful for debugging specific incidents or identifying phishing campaigns in real-time. For more details on the types of information included in these reports, you can read our article on what information DMARC RUA and RUF reports contain.
Privacy considerations for forensic reports
Sensitive data: RUF reports can include email subject lines, sender and recipient addresses, and even parts of the email body, which may contain personally identifiable information (PII).
Limited adoption: Due to these privacy concerns, many major mailbox providers (like Google and Yahoo) have ceased or significantly limited sending RUF reports.
Use with caution: While powerful, relying solely on RUF reports for diagnosis is not always feasible due to their limited availability and the data they expose.
Troubleshooting common DMARC failure scenarios
After gathering and understanding your DMARC reports, the next step is to pinpoint the common causes of failure. The most frequent culprits are issues with SPF, DKIM, or, critically, DMARC alignment. Even if SPF and DKIM records are technically correct, DMARC can still fail if the domains used in these authentication checks do not align with the From: header domain.
Misconfigured SPF records, such as missing authorized sending IPs or exceeding the 10-lookup limit, are common. Similarly, expired or invalid DKIM keys, incorrect selector names, or improper signing by your sending service can lead to DKIM failures. Your DMARC reports will clearly indicate which of these authentication mechanisms failed for each email source. If you are experiencing issues with Microsoft's DMARC validation, analyzing your reports is essential for diagnosis.
Beyond misconfigurations, DMARC failures often signal unauthorized sending or phishing attempts. If your reports show a high volume of failed emails from unknown IP addresses, it’s likely that malicious actors are spoofing your domain. DMARC’s policy enforcement (quarantine or reject) is designed to mitigate these threats, but only if you are monitoring your reports and adjusting your policy accordingly. For a more in-depth look at troubleshooting, check out our guide on how to troubleshoot DMARC failures.
Correct DMARC alignment
SPF alignment: The domain in the Mail From (Return-Path) matches the From: header domain.
DKIM alignment: The domain in the DKIM signature (d=) matches the From: header domain.
DMARC pass: At least one of SPF or DKIM passes and aligns.
Common causes of failure
Subdomain sending: Sending from a subdomain (e.g., mail.example.com) with SPF/DKIM configured for the root domain (example.com) if alignment is strict.
Forwarding issues: Emails forwarded by a receiving server may break SPF alignment.
Unauthorized senders: Emails sent from sources not included in your SPF record or not properly signing with DKIM.
Human error: Typos in DNS records, or forgotten SPF includes.
Views from the trenches
A marketer from Email Geeks says: I was seeing high delivery errors in Google Postmaster Tools, with DMARC's reject policy on my sender domain, even though SPF, DKIM, and DMARC were showing 100% passed. It turned out the Google Postmaster Tools checks the DMARC success or failure for a domain that isn't the one in the visible From: header, which was confusing.
An expert from Email Geeks says: The data for which emails Google rejected due to DMARC failures are always available in your DMARC reports. That is precisely what those reports are for. Analyzing them allows you to see the SPF string, the DKIM string, and the originating IP of the failures.
An expert from Email Geeks says: I do not think headers alone will be very useful for diagnosing DMARC failures. You need to find headers from the small percentage of messages that are failing, and those might not even be your messages if it is a spoofing issue.
An expert from Email Geeks says: You need to review your identifier alignment if you are seeing unexpected DMARC failures.
Best practices
Always start with a DMARC policy of p=none (monitoring mode) to identify all sending sources and prevent legitimate emails from being impacted.
Regularly review your DMARC aggregate reports to detect new or unauthorized sending sources.
Ensure that SPF and DKIM records are correctly configured for all authorized email senders.
Verify that your SPF and DKIM records achieve DMARC alignment with your From: header domain, as non-aligned mail will fail DMARC.
Consider using a DMARC reporting service to simplify the parsing and analysis of complex XML reports.
Common pitfalls
Failing to review DMARC reports regularly, leading to delayed detection of spoofing or authentication issues.
Moving directly to a p=quarantine or p=reject policy without thorough monitoring, which can block legitimate email.
Misunderstanding DMARC alignment, causing emails to fail even when SPF and DKIM pass independently.
Not accounting for all third-party senders (marketing platforms, transactional email services) in SPF and DKIM records.
Ignoring low-volume DMARC failures, which can be early indicators of a larger problem or targeted attacks.
Expert tips
Pay close attention to the 'Disposition' column in aggregate reports to understand how receivers apply your DMARC policy.
Use forensic reports (if available) to drill down into specific email headers for a deeper understanding of why authentication failed.
Implement automated alerts for significant changes in DMARC pass/fail rates or the appearance of new sending IPs.
Leverage DMARC's 'rua' and 'ruf' tags to direct reports to a dedicated inbox or DMARC analysis tool.
Regularly audit your DNS records to ensure SPF and DKIM configurations remain accurate and up-to-date.
Marketer view
A marketer from Email Geeks says: I was seeing high delivery errors in Google Postmaster Tools, with DMARC's reject policy on my sender domain, even though SPF, DKIM, and DMARC were showing 100% passed. It turned out the Google Postmaster Tools checks the DMARC success or failure for a domain that isn't the one in the visible From: header, which was confusing.
2021-05-07 - Email Geeks
Expert view
An expert from Email Geeks says: The data for which emails Google rejected due to DMARC failures are always available in your DMARC reports. That is precisely what those reports are for. Analyzing them allows you to see the SPF string, the DKIM string, and the originating IP of the failures.
2021-05-07 - Email Geeks
The path to DMARC success
DMARC reports are indispensable for diagnosing email authentication failures and maintaining strong email deliverability. By understanding the differences between aggregate and forensic reports, and knowing what specific data points to look for, you can effectively pinpoint the root causes of DMARC failures, whether they stem from misconfigurations or malicious spoofing attempts.
The insights gained from these reports allow you to refine your SPF and DKIM configurations, onboard new sending services correctly, and enforce stronger DMARC policies confidently. Regular monitoring and proactive analysis of your DMARC reports are not just best practices, they are essential for protecting your brand’s reputation and ensuring your legitimate emails consistently reach the inbox.
