DMARC is a powerful tool that domain owners can use to protect their domains — and thus their brands — from abuse. At enforcement (a policy of “quarantine” or “reject”) it stops impersonation attacks, which are the most difficult type of phishing attacks to detect and block.
DMARC’s benefits go further than phishing prevention, though. With the right tools, DMARC allows domain owners to gain global visibility into all senders spoofing their domains, and to exert centralized control over allowed SaaS services, which is a boon for IT teams everywhere. And when implemented properly, it improves deliverability, because spammers can no longer damage a domain’s reputation by sending email purporting to be from that domain.
That said, not all elements of DMARC are equally valuable. One component of DMARC, failure reports (sometimes called forensic reports), have been a part of the standard from the very beginning. But unlike aggregate reports — which provide aggregated summaries of email authentication activity and are actually useful — failure reports are riddled with problems, not the least of which is that they open organizations to potential liability around privacy issues.
When an email system receives a message that fails DMARC, it may send a failure report to the domain owner. Since receivers send failure reports in real time, they can provide an immediate alert whenever a non-authenticating message is detected. Sounds good, right? And even more appealing, failure reports include details about the failing message that many domain owners would like to have: The From address, the subject line, and, in some cases, part or all of the message content.
On the face of it, DMARC failure reports seem like a valuable part of the standard. But in practice they haven’t worked out that way. Failure reports have failed to deliver real value to domain owners and, in today’s increasingly privacy-focused world, opened them up to non-obvious risks.
So what’s wrong with failure reports?
There are five major problems:
- They distract from enforcement
- They have a high false positive rate
- They are not generally actionable
- They potentially expose PII
- Most ISPs have dropped support for failure reports
They Distract from Enforcement
When working with DMARC, the focus of any domain owner should be getting to enforcement. The primary purpose of DMARC is to protect the domain from abuse through policy enforcement.
But the ‘real-time alert’ nature of DMARC failure reports confuses this notion. Some people interpret the existence of failure reports as evidence that DMARC is intended primarily as an abuse-reporting mechanism. As a result, many IT professionals believe that they are “done” when they have configured a non-enforcement DMARC record (one with a policy of p=none) to send them reports. Yes, they get reports (both failure reports and aggregate reports), but at p=none these domains never get the real benefit of DMARC: protection through authentication.
They Have a High False Positive Rate
When sending large numbers of marketing messages per day, it’s inevitable that some small percentage will fail DMARC. Some of these messages fail because they are routed through forwarders that break their DKIM signatures, and thus fail DMARC at their final destination.
But even if the failure percentage is low (0.1% or below), if you’re sending millions or tens of millions of messages per day, that amounts to thousands of failures. Wading through that noise is extremely challenging and time-consuming.
They Are Not Generally Actionable
Assuming that IT staff are reacting to DMARC failure reports as they come in, and they are able to filter through the large number of false positives to find the actual phishing messages, what do they do when they find one?
Most companies don’t have the time or resources to prosecute bad actors on the Internet. At best, members of the IT staff may be able to file reports with a hosting provider. Perhaps they’ll even be able to get the hosting provider to shut down the offending server. But in that case, how long do you think it will take the phisher to find a new home? Is this game of Whac-a-Mole even worth it?
For that matter, why bother when email authentication at enforcement protects you from this abuse completely, without requiring any involvement from you?
They Potentially Expose PII
As a domain owner it’s important to understand that you don’t control what’s included in the DMARC failure report — that’s up to the receiver. And if the report is a false positive (an email that failed DMARC but shouldn’t have) that can mean ‘real’ information may be included in the failure report. That makes the failure report an easy way to leak confidential corporate or customer information.
For example, imagine an email containing details about the new iPhone, a new CIO hire, or about the sale of the company accidentally failing DMARC, then winding up as a failure report on some IT admin’s desktop.
With the online world’s increasing focus on privacy, so-called PII (personally identifiable information) needs to be handled with extreme care. The penalties for leaking this kind of information have grown substantially. Inadvertently leaking news of an impending product launch or layoff is no longer merely a business risk — these kinds of leaks can now lead to substantial fines. With the European Union’s GDPR rules coming into effect in May 2018, each leak of customer PII can result in a fine of 20 million euros or higher. DMARC failure reports do not bring enough value to be worth that sort of risk.
They Are Poorly Supported
We’re not the only ones who feel that DMARC failure reports bring little value and present a lot of risk. Most ISPs have stopped providing DMARC failure reports because of concerns about PII leakage and general doubts as to their actual value.
As of this writing NetEase (a Chinese ISP) and Hotmail.com are the only two large ISPs that still send DMARC failure reports, and Hotmail is in the process of phasing them out. Google, Oath (Yahoo/AOL), and virtually all other major ISPs do not send failure reports. Even those ISPs that once supported “private channel” arrangements — only sending failure reports to trusted vendors — have abandoned them because of PII concerns.
So even if you configure your DMARC record to accept failure reports, you’ll find that almost none of your failing messages generate them.
Given the above, we believe that DMARC failure reports were a well-intentioned, but ultimately unsuccessful, part of the DMARC standard.
DMARC aggregate reports provide all the information that domain owners need to get their domains to enforcement, without the risks presented by DMARC failure reports.
Moving past DMARC failure reports would be a positive step for the ecosystem, and we encourage all participants to stop supporting and using them and instead focus on getting to enforcement.