What DNS record is required for DMARC reports to an external domain?
Matthew Whittaker
Co-founder & CTO, Suped
Published 17 May 2025
Updated 17 Aug 2025
6 min read
When implementing DMARC for your domain, DMARC reports are essential for gaining visibility into your email ecosystem. These reports provide crucial data on email authentication, helping you identify legitimate email traffic and detect fraudulent activity. They show how many emails are passing or failing SPF and DKIM authentication, and what actions receiving mail servers are taking based on your DMARC policy.
Often, organizations prefer to send these reports to a dedicated email address, which might be hosted on a different domain, especially when using a third-party DMARC reporting or monitoring service. While convenient, this setup introduces an additional DNS requirement to ensure that these external domains are authorized to receive reports on your behalf.
Receiving DMARC reports from external domains is a common practice, particularly when you leverage specialized DMARC report analysis services. These services aggregate and parse the raw XML reports into an understandable format, saving you significant effort. You specify where these reports should be sent using the rua (aggregate report URI) and ruf (forensic report URI) tags within your primary DMARC record. You can learn more about the list of DMARC tags and their meanings in our guide.
The reason for this additional DNS record is purely for security and to prevent abuse. Without a verification mechanism, anyone could configure their DMARC record to send reports to any email address, potentially leading to a denial-of-service attack through unsolicited DMARC report volumes. This is precisely why the DMARC specification includes explicit rules for receiving DMARC reports outside your domain.
When a mail receiver, such as Google or Microsoft, processes your DMARC record and finds an external domain listed in the rua or ruf tag, it performs an additional DNS lookup. This lookup verifies that the external domain explicitly agrees to receive reports about your sending domain. Without this handshake, most legitimate mail servers will simply not send the reports, leading to gaps in your DMARC data. Even if you're asking, can DMARC reports be sent without RUA or RUF addresses? The answer is generally no, for comprehensive reporting, they are crucial.
The external domain verification DNS record
The specific DNS record required for DMARC reports to an external domain is a TXT record. This record must be published in the DNS of the *receiving* domain, not your primary sending domain. Its purpose is to explicitly authorize the receiving domain to accept DMARC reports for your sending domain. This ensures that the receiving party has indeed consented to receive potentially large volumes of data.
The format of this authorization record is crucial. It follows a specific naming convention that includes both the sending and receiving domains. You can find detailed information about this requirement in the DMARC specification, RFC 7489, specifically in Section 7.1 regarding external reporting.
Example DMARC External Verification TXT Record
sendingdomain._report._dmarc.receivingdomain IN TXT "v=DMARC1;"
Let's break down this record format. sendingdomain refers to the domain that has the DMARC record (your primary email sending domain). _report._dmarc is a fixed prefix used to identify this specific type of DMARC-related record. Finally, receivingdomain is the domain hosting the email address where you want to receive the DMARC reports. The value "v=DMARC1;" indicates that this is a valid DMARC external report verification record.
Configuring the verification record
Configuring this verification record involves adding it to the DNS zone of the domain that will *receive* the DMARC reports. For example, if your sending domain is yourcompany.com and you're sending reports to reports@dmarcservice.com, then the TXT record needs to be added to the DNS of dmarcservice.com.
The exact steps depend on your DNS provider, but generally, you will log into your DNS management interface, navigate to the zone file for the receiving domain, and add a new TXT record. The name or host field should be yourcompany.com._report._dmarc (replacing yourcompany.com with your actual sending domain), and the value should be "v=DMARC1;". Remember that proper DMARC setup is critical for email authentication.
Correct DMARC record setup
Sending Domain's DNS: A DMARC TXT record at _dmarc.yourdomain.com with rua=mailto:reports@externaldomain.com.
Receiving Domain's DNS: A TXT record at yourdomain.com._report._dmarc.externaldomain.com with value "v=DMARC1;".
This setup provides explicit consent, allowing mail receivers to send aggregate and forensic reports to your designated external domain without issues. It ensures compliance with the DMARC specification and helps you gather all necessary data for analysis.
Common incorrect setup
Sending Domain's DNS: A DMARC TXT record at _dmarc.yourdomain.com with rua=mailto:reports@externaldomain.com.
Receiving Domain's DNS: No specific TXT record for yourdomain.com._report._dmarc.externaldomain.com.
In this scenario, many mail receivers will refuse to send DMARC reports, as the external domain has not explicitly authorized their reception. This leads to incomplete data and hinders your ability to effectively monitor your email traffic and detect spoofing attempts.
Common pitfalls and troubleshooting
A common pitfall is overlooking this required DNS record, especially if you're not using a dedicated DMARC service that automatically handles this for you. If this record is missing, most mail servers adhering strictly to the DMARC specification (RFC 7489) will not send reports to your specified external address. This will result in missing data and an incomplete view of your email authentication status, making it harder to diagnose DMARC failures.
While some mail providers might still send DMARC reports even if the external verification record is absent, this is an exception rather than the rule. Relying on such behavior leaves your DMARC reporting vulnerable to inconsistencies and makes it impossible to receive comprehensive feedback on your domain's email activity. For example, some anecdotal reports suggest Mail.ru occasionally sends reports without this strict check.
Best practices for DMARC external reporting
Always verify: Ensure the required TXT record is correctly published in the DNS of the external receiving domain.
Monitor reports: Regularly check your DMARC reports for consistency. Missing reports from specific mail providers could indicate a misconfiguration.
Use a DMARC solution: Consider using a DMARC analysis platform that can help manage and verify these records, providing a comprehensive view of your email security.
Review DMARC policy: Make sure your DMARC policy is set appropriately, especially if you're transitioning from p=none to quarantine or reject.
Ensuring comprehensive DMARC reporting
Setting up the proper DNS record for DMARC reports to an external domain is a critical, yet often overlooked, step in achieving full DMARC compliance and visibility. It ensures that mail receivers have explicit authorization to send you the valuable data needed to protect your domain from email spoofing and phishing attacks. Ignoring this requirement can lead to incomplete reporting, leaving blind spots in your email security posture.
By correctly publishing this verification record, you strengthen your DMARC implementation and ensure that you receive all the necessary insights into your email authentication efforts. This comprehensive data is vital for making informed decisions about your DMARC policy, moving towards a stricter DMARC policy like quarantine or reject, and ultimately improving your email deliverability and reputation.
Views from the trenches
Best practices
Always publish the external report verification record on the *receiving* domain's DNS.
Use a DMARC monitoring service to automatically handle report collection and analysis.
Regularly review your DMARC reports for any missing data or unexpected gaps.
Common pitfalls
Forgetting to publish the TXT record on the external receiving domain.
Assuming DMARC reports will be sent automatically to external addresses.
Incorrectly formatting the external verification DNS record.
Expert tips
Setting up the external verification record prevents potential mailbombing of report recipient email addresses.
While most mail servers respect the external verification requirement, some might occasionally send reports even without it.
The authorization record for external DMARC reports does not affect DMARC validation itself; it only impacts report delivery.
Expert view
Expert from Email Geeks says the domain receiving DMARC reports must announce its readiness to accept reports for your domain to prevent mailbombing incidents.
2023-12-20 - Email Geeks
Marketer view
Marketer from Email Geeks says that to authorize DMARC reports, you need to set up a specific TXT record in your DNS, as detailed in the RFC documentation.
Google or 
Microsoft, processes your DMARC record and finds an external domain listed in the rua or ruf tag, it performs an additional DNS lookup. This lookup verifies that the external domain explicitly agrees to receive reports about your sending domain. Without this handshake, most legitimate mail servers will simply not send the reports, leading to gaps in your DMARC data. Even if you're asking, can DMARC reports be sent without RUA or RUF addresses? The answer is generally no, for comprehensive reporting, they are crucial.
Mail.ru occasionally sends reports without this strict check.
