Getting to p=Reject, Mimecast’s Internal DMARC Project: Part 3. Job Done?

In my first blog on Mimecast’s internal DMARC project, I laid the groundwork on what DMARC is and why we chose to embark on this project. Mimecast, like any company with an online presence, is targeted by phishers who try to exploit it specifically to leverage the awareness and trust in our brand and to attack our customers, partners and others. DMARC is an excellent way to address this sort of email-based brand exploitation by more effectively locking down the use of domains for email. The purpose of this blog series is to provide insights that will help guide your own organization’s DMARC project.

In my second blog, I delved into the “who” and the “how” of our DMARC project. Yes, it is a project that typically requires, in addition to a great DMARC product, a cross-functional team comprising IT, security, a DMARC specialist and even marketing to get the best and most expedient outcome. For Mimecast, like most other organizations, we discovered that we own many more domains than we initially thought — more than 300. Many of these domains are just parked to block others from registering them, while others came across in past M&A transactions, and others were registered for special projects without the active participation of the IT or security teams.

Registering domains is so easy after all. Fortunately, very few of the 300 owned domains are being used to send legitimate email from Mimecast. For Mimecast, mimecast.com is our #1 domain that we want to protect. We use it both as our main website domain as well as the domain from which we send most of our email.

Setting Mimecast.com to p=reject

Once we collected our list of owned domains, we found that some domains took sleuthing to figure out internal ownership. For those mostly unused domains, we very quickly set them to p=reject for DMARC — since we don’t use them to send email anyway, there is no chance that legitimate email delivery would be disrupted. Keep in mind that just because you don’t send email from most of your domains, doesn’t mean attackers won’t! Therefore, DMARC is relevant for all of your domains and p=reject should be part of your default DNS entry, even for parked domains. Doing this in the first phase of the project allowed us to focus our energy on our primary email presence, which is built around the mimecast.com domain. This is the domain from which we and our legitimate service providers (Marketo and others) send email. Here we needed to be more careful in our move to p=reject.

After about a month of DMARC report reviews, ongoing monitoring, and making DKIM and SPF configuration changes in the few remaining legitimate sending applications, we made the move to p=reject for mimecast.com. And I am happy to say that mimecast.com has been moved from p=quarantine to p=reject with no significant negative impact. In fact, it is has helped to drive another stake into the hearts of the phishers who are attempting to misuse our brand!

Has this move to p=reject stopped spammers and phishers from attempting to leverage the mimecast.com domain to spoof the Mimecast brand? Not yet, but it has definitely impacted their email delivery rate! And with a dramatically reduced email delivery rate, we expect them to move on to attack less well-defended domains. Let me provide an email example — Figure 2 below — to give you a sample of what we have been collecting in our ruf and rua DMARC reports.

And what were these emails attempting to lead their intended victims to? Big surprise — a credential collection page that was hosted on a variety of different, now blocked or taken down, web pages. Note that they didn’t even bother to spell “Mimecast” correctly in the URLs.

What Next?

Well, that’s it. DMARC project done. On to the next security project? Not quite. The reality is that nothing is static in the world of IT and security. It is important to keep monitoring your DMARC reports to see if new, legitimate but improperly configured services have been rolled out (hello, marketing). Without ongoing monitoring, the delivery rate of these new legitimate email sending services will be quite poor. In addition, the information contained in your DMARC reports about the phishers that are attempting to abuse your domains should be provided to your SOC team or anyone else that manages your threat detection and response program, as they can provide important insights into who and how your organization is being spoofed via email. The attacks described above are not unique to Mimecast.

Next up, BIMI

Now that mimecast.com is at p=reject for DMARC, it also opens another option to improve trust in the Mimecast brand via email. A new standard, Brand Indicators for Message Identification (BIMI), is emerging that enables the cryptographic locking of a trademarked logo, in our case the Mimecast “M” (seen above) to the mimecast.com domain. This way only verified BIMI senders using the mimecast.com domain can enable the delivery of the Mimecast “M” and have it displayed in BIMI supporting email clients, such as Gmail and Yahoo mail. Stay tuned, as the DMARC team at Mimecast is in the process of pivoting to implement BIMI for mimecast.com. In an upcoming blog I will report back on the BIMI extension to our DMARC project.