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

DMARC external Destination Verification | External Domain Verification

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.

Latest posts by Ahona Rudra (see all)
/by