• Log In
  • Sign Up
  • Contact Us
PowerDMARC
  • Features
    • PowerDMARC
    • Hosted DKIM
    • PowerSPF
    • PowerBIMI
    • PowerMTA-STS
    • PowerTLS-RPT
    • PowerAlerts
  • Services
    • Deployment Services
    • Managed Services
    • Support Services
    • Service Benefits
  • Pricing
  • Power Toolbox
  • Partners
    • Reseller Program
    • MSSP Program
    • Technology Partners
    • Industry Partners
    • Find a partner
    • Become a Partner
  • Resources
    • DMARC: What is it and How does it Work?
    • Datasheets
    • Case Studies
    • DMARC in Your Country
    • DMARC by Industry
    • Support
    • Blog
    • DMARC Training
  • About
    • Our company
    • Clients
    • Contact us
    • Book a demo
    • Events
  • Menu Menu

What is DMARC “External Destination Verification”? | Receiving DMARC reports outside your domain

Blogs
Receiving DMARC reports outside your domain

Did you know you can receive DMARC reports outside your own domain? Yes, it is possible to send your DMARC reports to an email address that does not fall within the scope of your own domain through DMARC External Destination Verification. If you own the domain company.com, you can send your reports to an address (example) [email protected], where company.com has no authority over mailreports.net and they are two completely separate domains. 

However, in order to achieve this, the report receiving domain (mailreports.net) needs to provide approval that it is agreeing to receive reports containing the DMARC data of your domain (company.com). 

The method that makes this possible is termed “External Domain Verification” and today we will be discussing what it is and how it helps you in your authentication journey. 

DMARC External Domain Verification – Explained

Let’s say you own the domain company.com and you have DMARC enabled for your domain. You now want to receive information about your email sending sources through DMARC aggregate reports, but to avoid spamming the inbox of your internal domains and subdomains, you want to redirect those reports to an external destination, say for example mailreports.net.

This is a common tactic exercised by businesses that have multiple registered domains, third parties, and a bulk flow of information to and from their domains. 

To do so, your subsequent DMARC record would look something like this: 

v=DMARC1; p=quarantine; rua=mailto:[email protected]

[To create your custom record for free, use our DMARC record generator tool]

The rua tag specifies the email address on which you will receive your DMARC reports. Now note that just because you have a record published on your DNS requesting your data to be sent to mailreports.net, doesn’t mean it will be so. It’s not that simple.

The report receiving domain must provide digital consent to receive the reports from company.com, else they can not be sent. This is known as External Domain Verification or External Destination Verification (as mentioned under RFC 7489 7.1). 

Why is External Destination Verification required? Potential threats and vulnerabilities

The following reasons can compel you to opt for External Domain Verification:

  • You own a domain that does not operate any mail servers
  • Without external domain verification, cyber attackers can easily create a DMARC record mentioning an external domain (of a victim) to receive reports. Reports for all bad emails sent by the attacker will now flood the victim’s inbox 

Through External Destination Verification, threat actors can be stopped from accomplishing their malicious deeds, and domain owners can route reports to an external domain that operates mail servers. 

How does External Domain Verification work?

Verifying External Reporting Destinations 

When a domain with a DMARC record published sends an email, the email receiving server checks whether the organizational domain at which the record has been published is an exact match to the organizational domain mentioned in the rua (or ruf) tag of the DMARC record. 

If it isn’t a match, and an external domain has been specified to receive reports, the verification process is initiated. 

To do so, the DNS of the report receiving host is queried to verify whether they have consented to receive the reports. If a DMARC record attesting the same is found in their DNS, the verification check passes, and reports are sent to the external domain. If it fails, reports are not delivered. 

Sometimes due to DNS timeout and other minor issues, a temporary error may occur preventing receiving servers from completing the external destination verification process temporarily. It is, however, reattempted later on. 

External Destination Verification configurations for specific domains (and subdomains) 

Let’s take our previous example to determine how to ensure your external destination verification process does not return an error result for your specific domains and subdomains.  

Example domain name: company.com 

Example external report receiving domain: mailreports.net 

A DMARC DNS record with the following information needs to be published on mailreports.net domain: 

Field  Description Value
Host This is where you publish the record on company.com._report._dmarc.mailreports.net
Value Your TXT record value v=DMARC1;

Note: Replace the domain names with your own domain and any external domain you want to receive your reports on. This record is NOT to be published on your domain, but on the external domain to which you want to send your reports.

And you’re done! During external destination verification, this will now inform email receiving servers that your preferred external domain mentioned in the rua or ruf tag does in fact consent to receiving DMARC reports on your domain’s behalf. 

Optional Configurations for External Destination Verification

Instead of publishing the above-mentioned record to give permission to specific domains for sending reports to their address, external domains often use a wildcard record (which starts with an asterisk “*”). 

This is simply a shortcut to avoid extra effort since a wildcard record essentially denotes that the external domain is consenting to receive DMARC reports from ANY domain (and not just your specific domain). 

Given below is the syntax (example) for a wildcard record used for external domain verification: 

Field  Description Wildcard Record Value
Host This is where you publish the record on *._report._dmarc.domain.com
Value Your TXT record value v=DMARC1;

Potential risks associated with using wildcard entries

Using wildcard entries for external domain verification is not a recommended practice and comes with potential risks. This is because when a domain consents to receive reports from any domain, bad actors can use this to spam email accounts with bulk reports from malicious domains without any mechanism in place to regulate or filter the reports. This can be potentially harmful to the report receiving domain, and also cause problems for you who are using that domain to receive your own reports. 

How do we handle External Domain Verification at PowerDMARC?

For clients who have created a PowerDMARC account and receive reports on the DMARC report analyzer dashboard don’t need to worry about external domain verification as we handle it for you. All reports sent by receivers are automatically routed and sent to our platform, neatly parsed and organized for you to view without you having to publish records in order to streamline the external destination verification process. All you need to do is specify our custom rua (or ruf) address in your DMARC record. 

Sign up now to make your external destination validation and DMARC implementation process effortless with a free DMARC trial.

external destination verification

  • About
  • Latest Posts
Ahona Rudra
Digital Marketing & Content Writer Manager at PowerDMARC
Ahona works as a Digital Marketing and Content Writer Manager at PowerDMARC. She is a passionate writer, blogger, and marketing specialist in cybersecurity and information technology.
Latest posts by Ahona Rudra (see all)
  • Methods To Protect Yourself From Identity Theft - September 29, 2023
  • The Role of DNS in Email Security - September 29, 2023
  • New Age Phishing Threats and How to Plan Ahead - September 29, 2023
May 30, 2022/by Ahona Rudra
Tags: dmarc external destination verification, external destination verification, external domain verification, receiving dmarc reports outside your domain
Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
  • Share by Mail

Secure Your Email

Stop Email Spoofing and Improve Email Deliverability

15-day Free trial!


Categories

  • Blogs
  • News
  • Press Releases

Latest Blogs

  • Methods To Protect Yourself From Identity Theft
    Methods To Protect Yourself From Identity TheftSeptember 29, 2023 - 12:11 pm
  • The Role of DNS in Email Security
    The Role of DNS in Email SecuritySeptember 29, 2023 - 12:08 pm
  • New Age Phishing Threats and How To Plan Ahead
    New Age Phishing Threats and How to Plan AheadSeptember 29, 2023 - 12:06 pm
  • How to View and Analyze Message Headers Online
    How to View and Analyze Message Headers Online?September 26, 2023 - 12:59 pm
logo footer powerdmarc
SOC2 GDPR PowerDMARC GDPR comliant crown commercial service
global cyber alliance certified powerdmarc csa

Knowledge

What is Email Authentication?
What is DMARC?
What is DMARC Policy?
What is SPF?
What is DKIM?
What is BIMI?
What is MTA-STS?
What is TLS-RPT?
What is RUA?
What is RUF?
AntiSpam vs DMARC
DMARC Alignment
DMARC Compliance
DMARC Enforcement
BIMI Implementation Guide
Permerror
MTA-STS & TLS-RPT Implementation Guide

Tools

Free DMARC Record Generator
Free DMARC Record Checker
Free SPF Record Generator
Free SPF Record Lookup
Free DKIM Record Generator
Free DKIM Record Lookup
Free BIMI Record Generator
Free BIMI Record Lookup
Free FCrDNS Record Lookup
Free TLS-RPT Record Checker
Free MTA-STS Record Checker
Free TLS-RPT Record Generator

Product

Product Tour
Features
PowerSPF
PowerBIMI
PowerMTA-STS
PowerTLS-RPT
PowerAlerts
API Documentation
Managed Services
Email Spoofing Protection
Brand Protection
Anti Phishing
DMARC for Office365
DMARC for Google Mail GSuite
DMARC for Zimbra
Free DMARC Training

Try Us

Contact Us
Free Trial
Book Demo
Partnership
Pricing
FAQ
Support
Blog
Events
Feature Request
Change Log
System Status

  • Français
  • Dansk
  • Nederlands
  • Deutsch
  • Русский
  • Polski
  • Español
  • Italiano
  • 日本語
  • 中文 (简体)
  • Português
  • Norsk
  • Svenska
  • 한국어
© PowerDMARC is a registered trademark.
  • Twitter
  • Youtube
  • LinkedIn
  • Facebook
  • Instagram
  • Contact us
  • Terms & Conditions
  • Privacy Policy
  • Cookie Policy
  • Security Policy
  • Compliance
  • GDPR Notice
  • Sitemap
What is Ping Spoofing?Ping SpoofingSPF Record SyntaxSPF Record Syntax
Scroll to top