There are good reasons why one domain might want to have the DMARC reports about its traffic sent to a mailbox in a different domain. However DMARC.org has recently received several aggregate reports for a few seemingly random domains with no connection to DMARC.org – which is potentially a form of abuse itself, and one that’s addressed in the DMARC specification. So why are these reports being sent here? We’ll take a quick look at why and how this is done, and how that might change in the near future.
Specifying Reporting Destinations
Aggregate reports are sent via email to an address specified in the rua tag of a domain’s DMARC record. (Failure reports are similarly directed with the ruf tag.) The domain owner can set any address they would like as the value of the rua tag – a mailbox in the same domain, an address elsewhere within the organizational domain, or an address in a different domain altogether.
There are many reasons why you may wish to have these reports sent to a mailbox in a different domain from the one you’re publishing the record under. For example, you might manage several domains and want to have all the reports come to a single mailbox. Or you may wish to have these reports sent directly to a commercial report processor.
Potential Abuses
But there are at least two potential problems with publishing reporting addresses this way. First, spammers and others will pull these addresses and start sending a lot of random email messages to them. However this is a well-understood problem with putting any email address on the Internet. Second, bad actors could put somebody else’s address in their DMARC records, thereby turning DMARC’s reporting mechanism into a DDoS attack whenever they run a spam campaign.
In order to prevent this kind of abuse, the DMARC specification (RFC7489) describes an authorization mechanism that report generators must implement in Section 7.1, unless they have an alternate mechanism for restricting reporting abuses.
External Reporting Authorization Records
Under these rules, if the operators of example.com wanted to receive their aggregate reports at reports@otherdomain.com, hey would include this rua tag in their DMARC record:
rua=reports@otherdomain.com
When a report generator has an aggregate report to send to example.com, it will consult example.com‘s DMARC record and extract the address above. Since the domain in that address is not example.com or its organizational domain, it would have to make an authorization check first. It would take that domain the report is for (example.com), and the domain that the rua field references (otherdomain.com), and construct a new name like this:
example.com._report._dmarc.otherdomain.com
The report generator would then look that name up in DNS. If the domain operator for otherdomain.com has published a DNS record at that name with the contents “v=DMARC1”, then the report generator may send reports for example.com to an email address at otherdomain.com.
Why Did Those Reports Arrive at DMARC.org?
Back to what started all this, DMARC.org received aggregate reports for a couple random domains. For some reason, the people operating those domains decided to put a DMARC.org email address in the rua field of their DMARC records. But this shouldn’t have mattered, because DMARC.org doesn’t publish external reporting authorization records for those domains – right? Right – provided the report generators were checking for those authorization records…
New standards often encounter race conditions, or chicken or the egg problems in the course of adoption. In the case of external reporting authorization records, a few email receiving sites that deployed DMARC early on observed that most sending domains had not yet deployed external reporting authorization records. They chose to temporarily disable this check in order not to stifle the initial wave of adopters, and unfortunately didn’t revisit the situation later.
Changes Are Coming
However readers should be aware that these report generators are planning to correct this situation. DMARC.org will attempt to spread the word when such changes are scheduled, and hopefully the resources on our site will help anybody impacted resolve the issue quickly.