What is DMARC “External Destination Verification”?

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

To make this work, the report-receiving domain (mailreports.net) must signal its approval to receive reports containing the DMARC data of your domain (company.com).

The method that makes this possible is called External Destination Verification (also referred to as External Domain Verification),and this chapter covers what it is and how it helps in your authentication journey.

DMARC External Destination Verification, Explained

Say you own company.com and have DMARC enabled. You want to receive aggregate reports about your sending sources, but to avoid filling internal mailboxes, you want to route those reports to an external destination such as mailreports.net.

This is common among businesses that manage multiple domains, work with third parties, or handle a high volume of mail.

Your DMARC record would look like this:

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

The rua tag specifies where your aggregate reports should be sent. But publishing this record does not by itself guarantee delivery to mailreports.net. The receiving domain must give DNS-based consent to receive reports from company.com. That consent step is External Destination Verification.

Why is External Destination Verification required?

The mechanism exists to prevent abuse:

You may own a domain that operates no mail servers and still want reports.
Without verification, an attacker could publish a DMARC record naming a victim's domain as the report destination, then deliberately send large volumes of failing mail, flooding the victim with unwanted reports.

External Destination Verification stops this by requiring the receiving domain to opt in, so reports only flow where the destination has agreed to receive them.

How does External Destination Verification work?

When a mail receiver discovers a DMARC record, and the organizational domain where the record was found is not the same as the organizational domain of the host in the rua (or ruf) destination, the verification process is triggered.

The receiver constructs a special DNS name (described below) at the destination domain and queries it for a confirming TXT record. If a record containing v=DMARC1 is found, verification passes and reports are sent. If not, the destination is ignored and no reports are sent.

To guard against loops and indirection, RFC 9990 also specifies that if the confirming record tries to redirect reports to yet another different host, the receiver must not generate the report. This keeps report routing from being chained off to unintended destinations.

If a temporary DNS error (such as a timeout) occurs, the receiver may defer and retry the verification later rather than failing permanently.

Configuring External Destination Verification for your domain (and subdomains)

Using our example:

Your domain: company.com
External report-receiving domain: mailreports.net

A TXT record with the following must be published on the mailreports.net domain:

Host: company.com._report._dmarc.mailreports.net
Value: v=DMARC1;

Note: Replace the domain names with your own. This record is published on the external domain (the one receiving your reports),NOT on your own domain. Once in place, it tells mail receivers that mailreports.net consents to receive DMARC reports on company.com's behalf.

Optional: wildcard authorization

Instead of authorizing each domain individually, an external domain can publish a wildcard record (using an asterisk) to consent to receiving reports from any domain:

Host: *._report._dmarc.mailreports.net
Value: v=DMARC1;

Risks of wildcard entries

Using wildcards is not recommended. When a domain consents to receive reports from any source, bad actors can exploit this to flood the receiving address with bulk reports from malicious domains, with no mechanism to filter or regulate them. This can harm the report-receiving domain and disrupt your own legitimate reporting.