Implementing DMARC is one thing. Making the commitment to implement DMARC in its most aggressive configuration is another.
Conceptually, Domain-based Message Authentication, Reporting, and Conformance (DMARC) is simple. DMARC provides a mechanism for email receivers to validate the source and integrity of inbound email. DMARC also specifies what receivers should do with messages that are not valid based on criteria pre-configured by senders. DMARC is designed to protect against direct domain spoofing, so it isn’t a complete solution to phishing. That said, DMARC has the potential, when deployed in an aggressive configuration, to take a page out of a hacker’s or spammer’s playbook.
DMARC is the result of a collaborative effort between leading organizations who originally came together in 2011 to provide senders and receivers with a tool to fight against fraudulent email activity. The remainder of this post provides an overview the mechanisms that enable DMARC, explores DMARC’s deployable configurations, and provides an overview of obstacles preventing wider adoption and/or more effective use of DMARC.
DMARC is built upon two existing standards, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). SPF enables an email sender to specify the servers from which email will come and provides instructions for how an email receiver should handle a message that does not originate from a specified server. DKIM, on the other hand, enables senders to include a digital signature on their messages, enabling receivers to verify that the message has not be altered in transit by a third-party.
DMARC brings these two mechanisms together in a powerful manner by allowing senders to specify a policy that tells receivers what to do with email messages that fail to pass SPF and/or DKIM validation. DMARC also enables senders to receive data back from receivers, providing insight into fraudulent email patterns. Before DMARC, there was not an effective feedback channel for failed email, so senders were largely in the dark on email once messages left their servers. There are only three DMARC policies that a sender can specify, and thus, three deployable configurations for DMARC:
- p=none: Tells the receiver to do nothing to the message except report back to the sender that it failed DMARC validation. Basically, the sender tells the receiver to deliver the message but lets the sender know why it failed DMARC validation.
- p=quarantine: Tells the receiver to treat the message as spam, results in delivery of the message to the recipients’ junk/spam folder, and then tells the receiver to report back on why the message failed validation.
- p=reject: Tells the receiver to block the message and report back on why the message failed validation.
The verdict is still out on DMARC’s impact and viability as a global tool to fight spam and phishing. As noted above, DMARC only protects against direct-domain spoofing, so it isn’t a comprehensive solution to these problems. In addition, adoption of the mechanism is far from comprehensive. While many large organizations, including some of the largest senders and email providers in the world (as well as the Federal Government), are pushing DMARC forward, there are key challenges standing in the way of more widespread adoption. Some of these challenges include:
- DMARC can be difficult to implement. Smaller and mid-sized organizations may lack the capacity or expertise to properly implement, configure, and monitor DMARC. Implementing DMARC sounds easy but can be difficult and involves many intricacies. Even something as simple as entering the right text, in the right format into a DNS TXT record can be a challenge for small and mid-sized companies where one or two IT professionals retain responsibility for all IT and security functions. For larger organizations, implementing DMARC involves inventorying every single entity that sends email on their behalf, which can include scores of internal and external groups. Excluding any of these groups can result in business interruptions or rejected emails.
- The reporting and data received after implementing DMARC can be difficult to interpret. After implementing DMARC, organizations will begin to receive raw data with many potential insights into their email traffic. Having the capacity and expertise to transform this data into meaningful information can be an issue. Fortunately, if senders are willing to invest, this can be solved with managed services, who can take the data and turn it into actionable insights for senders.
- Making the commitment to set a p=reject policy. This is really where the rubber meets the road. Until senders are willing to commit to blocking illegitimate emails and become confident in their DMARC configuration, they really aren’t stopping any emails from getting through. Now, this isn’t to suggest that senders should throw caution to the wind and go to a p=reject policy right away, but there should be a commitment to get there eventually. There’s nothing wrong with starting at p=none, monitoring, tweaking, and then moving to p=quarantine and p=reject in a reasonable timeframe. A good example of this type of implementation can be found in the Federal Government, with the Department of Homeland Security mandating that agencies achieve DMARC deployment with a p=reject policy by October 2018.
Despite these challenges, DMARC continues to show a lot of promise. It isn’t a complete fix to spamming and phishing, but it is another tool in the larger fight to protect information. Of note, DMARC does not rely on end user actions to distinguish between authentic and fraudulent emails, eliminating a notable weak point in many cases. Bottom line, until a comprehensive solution to phishing and spoofing materializes, DMARC is an important control to protect against email spoofing – if it gains widespread adoption across industries and geographies. In addition, senders need to commit to implementing DMARC fully, in its most secure configuration, if the mechanism is going to be effective long-term. The Federal Government appears to be leading the charge on DMARC in 2018, following in the footsteps of technology and finance firms in recent years.
There is certainly still an open question as to whether DMARC will gain widespread adoption. As of August 2017, 337 of Fortune 500 companies had not implemented a DMARC policy at all and 124 were still in the p=none phase. Looking at the Alexa Top 100 domains as of July 2017, 43% have deployed DMARC with a p=reject policy. The picture is less promising when looking at the Alexa Top 1,000 and Top 10,000, where there is 16% and 4.6% adoption of a p=reject policy, respectively. Perhaps with the 2018 push at the federal level, we will be better able to determine if widespread adoption is likely next year, or if we should look to another mechanism to protect against email spoofing.