What is DMARC “External Destination 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]

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.

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: 

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: 

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.