DMARC emerged from an experiment piloted by Yahoo! and PayPal in 2007 that was designed to prevent phishing. Before DMARC, there were two email authentication protocols, “Sender Policy Framework” (SPF) and “Domain Keys Identified Mail” (DKIM). SPF utilizes DNS to specify which mail servers are authorized to send email for the domain listed in the envelope or “bounce” address. SPF is therefore able to authenticate the envelope sender, but does nothing to authenticate the sender contained in the “From: header” of the message. Since end users don’t see the envelope sender, it’s far more important to authenticate the “From: header,” which they do see.
DKIM uses cryptographic authentication. A hash of the message is digitally signed using a private key known only to the sending email server. This signature rides around in a special message header, and can be verified using the signer’s public key, which is stored in the signer’s DNS. DKIM is actually quite easy to deploy so long as your mail server or Email Service Provider supports it. Unfortunately, there’s a misconception that DKIM is difficult to deploy, or that deploying DKIM will cause receivers to block your email if the signature fails validation. Neither of these are true.
The “Domain-based Message Authentication, Reporting & Conformance” (DMARC) protocol seeks to advance these previous standards by comparing the envelope sender authenticated by the SPF check and the signing entity authenticated by the DKIM signature back to the sender listed in the “From:” header. Known as “identifier alignment”, this identifier comparison is what enables DMARC to authenticate the “From: header” of an email message.
PayPal and Yahoo! were successful in their DMARC pilot program. Criminals could no longer send fraudulent PayPal messages to Yahoo! mail users. Next came a working group of email industry experts including Google, Yahoo!, Bank of America, PayPal, Agari, and a number
of other companies interested in scaling up the Yahoo!/PayPal experiment. The goal was to allow anybody on the Internet to control the use of their domain in the “From:” header of email messages. This group was known as MOOCOW, or Messaging Operational Overlay Coalition Of the Willing.
After many months of discussion, debate, and compromise, Microsoft, AOL, Google, and Yahoo! deployed the first working receiver implementations of what came to be known as DMARC in January 2012. Since then, many senders and receivers have implemented this crucial email control, often with the help of a vendor such as Agari. In March 2015, DMARC was detailed in an informational Request for Comments as RFC-7489. Since then, a number of additional consumer mailbox providers have implemented the standard, and most major Secure Email Gateway vendors have incorporated parts of the standard into their services and appliances.
DMARC is designed to be deployed in stages. Companies generally start in “monitor mode” using what’s known as a “p=none” policy. This will provide feedback about servers using the domain name in the “From:” header of the email messages they send. The domain owner uses this information to make adjustments to their SPF and DKIM configurations until all of their legitimate mail sources are properly authenticated. At this point, the policy can be tightened to “p=quarantine”, which sends authenticated messages to the recipient’s spam folder or even “preject”, which causes the message to be blocked outright.
According to DMARC.org, DMARC is designed to:
Finally, it is important to realize that DMARC must also be deployed on the receiver side, by email service providers. Currently, the major email service providers, Microsoft, AOL, Google and Yahoo! have deployed DMARC, but smaller email service providers or a self-hosted email server may not provide the same level of protection.
Agari is uniquely positioned to share its insight into the practical applications of DMARC deployments because so many of its users are early adopters of DMARC. The following charts provide an anonymized view of Agari dashboards to highlight the positive impact of DMARC. Together, Agari and DMARC are preventing identity deception.
As shown in Figure 5, the Agari client was receiving a tremendous volume of unauthenticated emails – at times more than 100 million per day. These are emails that were spoofing the domain in the “From:” header. Shortly after March 11, 2013, the client implemented a DMARC Reject policy, resulting in millions of spoofed messages that could no longer be delivered. As a result, by the end of that March, these messages all but ceased – the perpetrators realized there was no benefit to continuing their campaign when every message was rejected.
Following this same customer’s journey, let’s fast forward a few years.
Figure 6 demonstrates that these spoofed messages have been all but eliminated. In most cases, there are simply no messages that are attempting to be sent. However, every so often, a new campaign may emerge, as seen in March of 2017. Even in this instance, the volume of messages sent is only 10,000, which seems insignificant compared to the initial 100 million. Again, these messages are rejected and the campaign drops off, as attackers turn their attention to more vulnerable targets elsewhere. DMARC is so effective at preventing these campaigns that the bad guys literally give up trying.
Finally, let’s switch gears to observe the gradual deployment of DMARC from None to Quarantine, to Reject.
Figure 7 demonstrates another client’s gradual adoption of tighter DMARC policies, precisely as DMARC was designed to be deployed. The initial volume of unauthenticated mail surpassed 100,000 to 150,000 messages per day, which was cut dramatically to 50,000 or less once a Quarantine policy was implemented. After another six months, this is tightened further to a Reject policy, which practically eliminates the volume of unauthenticated email.
Based on the Agari research, many organization find themselves in the first stage of DMARC implementation and unable to progress to quarantine and reject policies. The reason for this is that larger organization have to first identify who is sending email on their behalf and get them to authenticate the email they are sending before changing the policy. Agari is the leading solution to help large organization with the analytics, workflow and services to move to more effective policies, maintain email governance and prevent ongoing brand abuse.
Corporations and governments around the world are woefully unprotected against phishing. From the Fortune 500 to the FTSE 100 and the ASX 100, the majority of organizations have not deployed DMARC, and for those that do, the majority maintain a monitor-only “p=none” policy that doesn’t protect anyone. These organizations and their customers remain vulnerable to domain spoofing and phishing attacks.
The logical early adopters of DMARC were the original high-value targets of phishing: payment processors, credit cards, banks, shipping and airlines. However, all organizations should be concerned with domain name spoofing to protect their brand reputation and trust.
Deploying a DMARC policy where p=none is simple, but it is only the first step. Organizations must Quarantine, Reject and maintain strong email governance to reap the benefits of DMARC.