Which ISPs deliver DMARC reports and what configuration is needed?
Michael Ko
Co-founder & CEO, Suped
Published 10 Aug 2025
Updated 15 Aug 2025
9 min read
When you implement DMARC, a crucial aspect of email security, one of its most valuable features is the ability to receive reports on your email traffic. These reports provide insights into how your domain's emails are performing, including authentication passes and failures for SPF and DKIM. However, a common question arises for many domain owners: which Internet Service Providers (ISPs) actually send these reports, and what specific configurations are necessary to ensure you receive them reliably?
It can be confusing, especially if you set up your DMARC record and only see reports coming from a handful of providers. You might expect major players to consistently send these detailed aggregate reports, but the reality can sometimes differ. Understanding which ISPs are active reporters and the precise DNS configurations required is key to leveraging DMARC for better email deliverability and security.
Without these reports, you are effectively flying blind. You would not know if legitimate emails are failing authentication or if malicious actors are spoofing your domain. The primary purpose of DMARC reporting is to give you this visibility, enabling you to identify and resolve issues that could impact your email program's effectiveness and reputation. Let us explore the landscape of DMARC reporting ISPs and the technical requirements to ensure you get the data you need.
Many major ISPs and mailbox providers actively generate and send DMARC reports. These reports are sent by the receiving mail server to the domain owner, not by your own sending domain. The goal is to provide transparency on how emails purporting to be from your domain are being handled across the internet.
Among the most consistent reporters, Google (Gmail, Google Workspace) and Yahoo! are typically reliable sources for these aggregate reports. They have been at the forefront of DMARC adoption and actively contribute to its ecosystem. For instance, Microsoft (Outlook, Office 365) also sends DMARC aggregate reports, though some users report less consistent delivery compared to Google. Other significant ISPs that contribute to DMARC reporting include Mail.ru, AOL, Comcast, and Zoho.
The consistency of report delivery can vary, however. While many large providers are generally good about sending reports, smaller or regional ISPs may not support DMARC reporting or might do so with less frequency. Additionally, the type of report you receive can differ. DMARC defines two main types: aggregate reports (RUA) and forensic reports (RUF). Aggregate reports are XML files that provide high-level summaries of email traffic, authentication results, and policy actions. Forensic reports, on the other hand, are detailed individual email failure reports, though these are sent much less frequently due to privacy concerns and technical complexities.
Even with widespread adoption, there is no guarantee that every ISP will send you DMARC reports, or that they will do so with the same regularity. It is crucial to set up your DMARC record correctly and monitor the reports you receive to gain a comprehensive understanding of your email ecosystem.
Necessary DMARC configuration
To receive DMARC reports, you need to publish a DMARC record in your domain's DNS. This record is a TXT record that contains various tags, including the all-important rua and ruf tags. The rua tag specifies the email address where aggregate reports should be sent. This is crucial for understanding your overall email authentication performance. The ruf tag, on the other hand, designates the address for forensic reports, though as mentioned, these are less common due to privacy considerations.
A common configuration mistake that prevents reports from being delivered is neglecting external domain verification (EDV). If you are sending DMARC reports to an email address on a domain different from the one the DMARC record is for (e.g., your DMARC record is for yourdomain.com but you want reports sent to reports@anotherdomain.com), you must authorize the receiving domain. This is done by adding a specific TXT record on the receiving domain. This record typically looks like yourdomain.com._report._dmarc.anotherdomain.com with a value of v=DMARC1. Without this, many ISPs will simply not send reports to the external address for security reasons, as outlined in the DMARC specification RFC 7489 section 7.1.
Here's an example of a DMARC record and the corresponding external domain verification record:
Aggregate reports (RUA) provide a comprehensive overview of all emails sent using your domain, regardless of whether they passed or failed authentication. These reports typically arrive daily in XML format and include data such as sending IPs, the volume of messages, SPF and DKIM authentication results, and the DMARC policy applied (e.g., none, quarantine, or reject). This information is vital for diagnosing DMARC failures and improving your email deliverability, especially when you are trying to move towards a stricter DMARC policy like quarantine or reject.
Forensic reports (RUF), while theoretically more granular, are far less common in practice. These reports contain anonymized headers and sometimes even the body of individual emails that failed DMARC authentication. While useful for pinpointing specific issues, privacy concerns have led most major ISPs to significantly limit or outright disable their sending of RUF reports. Therefore, relying solely on forensic reports for DMARC monitoring is not advisable; aggregate reports are your primary source of actionable data.
Understanding the distinction between these report types and what information they provide is fundamental to effective DMARC implementation. Focusing on setting up aggregate report reception and using tools to parse the XML data will give you the clearest picture of your email sending health.
Troubleshooting missing DMARC reports
If you are not receiving DMARC reports, or only getting them from a few ISPs, several factors could be at play. The most frequent reason is an incorrect DMARC record. Even a small typo or misconfiguration in your DNS TXT record for DMARC can cause receiving mail servers to ignore your reporting requests. Double-check your DMARC record's syntax, ensuring all tags are correctly formatted and there are no hidden characters. You can use a DMARC record generator tool to help confirm it's valid.
As previously mentioned, a missing external domain verification (EDV) record is another very common cause. If your rua or ruf email address is on a different domain than your DMARC record, ISPs will often refuse to send reports until that separate domain explicitly authorizes it with a specific TXT record. Without this explicit authorization, the reports simply will not be sent, leaving you without crucial data.
Furthermore, remember that not all ISPs consistently send DMARC reports. While major players like Mail.ru, seznam.cz, and Zoho are known to send reports, smaller or regional providers may not have DMARC reporting enabled or might have inconsistent practices. The volume of email traffic your domain sends to a particular ISP can also influence report frequency. If you send very few emails to a specific provider, you might receive reports less often, or not at all, simply due to low volume. Consistent monitoring and analysis of the reports you do receive are vital for maintaining good email deliverability.
Final thoughts on DMARC reporting
Understanding which ISPs send DMARC reports and configuring your DNS records correctly are crucial steps in securing your email ecosystem. By setting up the rua and ruf tags accurately, and performing external domain verification when necessary, you empower yourself with the data needed to monitor your email authentication, identify spoofing attempts, and troubleshoot deliverability issues. Consistent monitoring and analysis of these reports will help you maintain a strong sending reputation and ensure your legitimate emails reach their intended inboxes.
Remember, DMARC reports are an invaluable tool for any domain owner committed to email security and deliverability. Take the time to implement them correctly, and you will gain critical insights into your email program's performance.
Views from the trenches
Best practices
Ensure your DMARC TXT record is meticulously correct, validating it with a DMARC record generator to prevent parsing errors by ISPs.
Always include the rua tag in your DMARC record to specify an email address for receiving aggregate reports, even if starting with a p=none policy.
Implement external domain verification (EDV) with a specific TXT record on the receiving domain if your reporting address is on a different domain.
Common pitfalls
Forgetting to add the necessary external domain verification (EDV) record, causing reports to be silently dropped by receiving mail servers.
Incorrectly formatting the DMARC TXT record, leading to ISPs ignoring your DMARC policy and reporting requests.
Expecting forensic (RUF) reports to be consistently delivered; many ISPs rarely send these due to privacy concerns.
Expert tips
I noticed that Google does not always seem to perform the external domain verification step, allowing reports even without the TXT record, though this might be an edge case.
Quite a few ISPs deliver reports; if you are only getting them from one or two, check for issues in your DMARC record that might be causing others to ignore it.
It is possible that something is slightly off in your DMARC record, which can cause some ISPs to ignore it while others process it correctly.
Expert view
Expert from Email Geeks says Microsoft is still not consistently delivering DMARC reports, but Yahoo should be.
2020-10-09 - Email Geeks
Expert view
Expert from Email Geeks says external domain verification is necessary if you are sending DMARC reports to a different domain.
Yahoo! are typically reliable sources for these aggregate reports. They have been at the forefront of DMARC adoption and actively contribute to its ecosystem. For instance, Microsoft (Outlook, Office 365) also sends DMARC aggregate reports, though some users report less consistent delivery compared to Google. Other significant ISPs that contribute to DMARC reporting include Mail.ru, AOL, Comcast, and Zoho.
Mail.ru, 
seznam.cz, and 
Zoho are known to send reports, smaller or regional providers may not have DMARC reporting enabled or might have inconsistent practices. The volume of email traffic your domain sends to a particular ISP can also influence report frequency. If you send very few emails to a specific provider, you might receive reports less often, or not at all, simply due to low volume. Consistent monitoring and analysis of the reports you do receive are vital for maintaining good email deliverability.
