Mimecast’s now completed DMARC project highlights examples of attacks that were stopped using a combination of DMARC, for the email portion of the attack, and Mimecast’s Brand Exploit Protect for the malicious website detection and takedown.

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!

DMARC 1.png

Figure 1 – DMARC DNS results for mimecast.com – p=reject

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.

DMARC 2.png

Figure 2 – Example of an email that attempted to spoof “mimecast.com” and link to a fraudulent Mimecast login page

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.

DMARC 3.1.png

DMARC 3.2.png

DMARC 3.3.png

DMARC 3.4.png

Figure 3 – Four examples of URLs that were linking to fraudulent Mimecast login pages

DMARC 4.png

Figure 4 – The fake Mimecast login page that was hosted on those malicious websites

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.

DMARC 5.png

Figure 5 – The Mimecast “M” logo

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.

Want more great articles like this?Subscribe to our blog.

Get all the latest news, tips and articles delivered right to your inbox

You may also like:

Getting to p=Reject, Mimecast’s Internal DMARC Project: Part 1

Creating a DMARC record and setting it t…

Creating a DMARC record and setting it to p=Reject would see… Read More >

Matthew Gardiner

by Matthew Gardiner

Principal Security Strategist

Posted Jul 16, 2020

BIMI May Boost Brand Safety—and Email Open Rates

Emerging standard specification ties bra…

Emerging standard specification ties brand logos to legitima… Read More >

Debra Donston-Miller

by Debra Donston-Miller

Contributing Writer

Posted Sep 11, 2020

Getting to p=Reject, Mimecast’s Internal DMARC Project: Part 2

A DMARC project goes well beyond just DN…

A DMARC project goes well beyond just DNS administration; te… Read More >

Matthew Gardiner

by Matthew Gardiner

Principal Security Strategist

Posted Aug 20, 2020