DMARC reporting helps domain owners gain insights into email activities that consequently support result-driven strategical adjustments. There are two types of DMARC reports– aggregate and forensic. You can start receiving them right in your desired email account’s inbox by using rua and ruf tags in your DMARC record and adding email addresses where you wish to receive them.
However, not many domain owners are aware of the concept of External Domain Verification in DMARC reporting, which practically allows you to receive DMARC reports on an email address that is outside of your domain. Let’s learn more about this unique concept and why you should care to practice it for cybersecurity.
External Domain Verification- What Does it Mean?
This DMARC feature allows you to add an email address that is outside of your domain authority to your DMARC record for recipients’ mail servers to send DMARC aggregate reports and DMARC forensic reports to. So, if your domain is mydomain.com, you can receive reports on notmydomain.com, where you have no authority over the latter domain.
Businesses with multiple domains, subdomains, complicated email infrastructure, and involvement of third-party service providers practice this to avoid receiving too many reporting emails and spamming. In such cases, redirecting reports to an external landing place sorts out operations at multiple levels.
Since the domain receiving reports will be independent and outside of your domain control, verification would be required to confirm that there is no problem in sending the reports to it. Without the official consent, the reports won’t be delivered.
Why is the Consent Necessary?
Just because you mentioned notmydomain.com in the rua and ruf tags sections in your DMARC record, it doesn’t mean you would just simply start receiving reports on it. If that had been the case, then hackers would have gotten the shiniest golden opportunity to direct these reports to the external domain by creating a fake DMARC record for your domain and committing cybercrimes.
This way, domain owners can stop threat actors from accomplishing evil goals and direct both types of reports to an external domain that doesn’t operate any mail servers.
Image sourced from sendlayer.com
External Domain Verification- How Does it Work?
On receiving an email from your domain, the recipient’s mail server cross-checks whether the sender’s domain and the one mentioned in the rua or ruf tags are the same. The verification process is initiated if the match is negative and an external domain has been provided for receiving reports.
The verification is conducted by querying the DNS of the external domain about its consent to receiving DMARC monitoring reports on behalf of your company. So, if the DNS affirms the same, the verification check passes, and the reports are regularly sent to the external destination. If it fails, the reports aren’t sent to it at all. This ensures that only trusted and authorized external destinations have access to sensitive DMARC-related performance details.
However, users can encounter a temporary error due to DNS timeout and other technical issues. In this case, you don’t necessarily have to take action, as another attempt is made automatically.
Solving the External Verification Failure
At times, the verification process fails for a legitimate and authorized external domain as well. This can be easily fixed by publishing a TXT record in the external domain’s DNS to permit the receipt of monitoring reports.
As per our example, you can resolve the external verification failure error by publishing a TXT record in notmydomain.com’s DNS zone to confirm the consent to receiving DMARC reports of mydomain.com.
Optional Configurations for External Destination Verification
You can also use the ‘wildcard’ method as an alternative to the above-mentioned process. In this, you have to add a wildcard record value starting with an asterisk or *. This makes the process easier and less time-consuming; however, it’s not recommended as it bears potential risks since the external domain consents to the reception of DMARC reports from ‘any’ domain.
This alternate method encourages threat actors to spam email accounts as there isn’t a mechanism settled to filter reports.
The whole process is applicable if you’re sending reports to your own address. However, if you’re using the custom DMARCReport.com reporting address in your DNS record, this will already be configured for you.