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

In my first blog on Mimecast’s internal DMARC project, I laid the groundwork for why we chose to embark on the project. In short, Mimecast’s own online brands and email domains periodically draw the unwanted attention of malicious actors who attempt to use them as part of phishing campaigns. Clearly, we want to put a stop to that!

Who Should Be Involved in Getting to P=Reject?

Since a DMARC project will touch on several areas other than just DNS administration - which is the easy part - it is very important that the right internal functions are represented and active on the DMARC implementation team for the duration of the project.

For Mimecast, the team assembled includes a senior security architect and project manager from our internal security team; our internal SOC manager who handles threat monitoring, detection and response; a representative from the Mimecast engineering team (we are, after all, an email security provider with deep expertise and are always looking to improve our products); a member of the internal IT team who looks after third-party IT application service providers; and a DMARC specialist from the DMARC Analyzer professional services team, who adds deep expertise from successful DMARC implementation projects for customers. The DMARC Analyzer product is serving as the application backbone of the project.

A similar project team makeup is recommended for other organizations who want to get to p=Reject, perhaps with exception to Mimecast engineering, to ensure that no part of the project is overlooked, misunderstood, or causes email delivery problems down the line.

Internal Organization for P=Reject

And, as with any multi-faceted and potentially business-impacting project, a key to success is appropriate phasing and risk management. For example, there are a number of legitimate services sending email on behalf of Mimecast, including Salesforce.com, Netsuite, and Marketo, making it critical not to disrupt the delivery of legitimate emails to our various audiences during the process of DMARC posture hardening.

While a key goal of the project is to block the illegitimate use of our primary owned domain, mimecast.com, it is very important not to overlook all the other domains our organization owns, but may not use for email; indeed, just because your organization doesn’t use them for email, doesn’t mean that cybercriminals who are trying to spoof you will not!

Domains and Categorizations

With this in mind, an early step in our DMARC project was collecting a listing of all the domains that Mimecast owns, leading us to discover more than 350 owned domains. These domains were organized into the following three categories:

• Cybersquatted domains - These are domains that we have registered over the years to block malicious actors from registering them and using them for websites or sending email. We have no intention of using them for our business. Examples of these include: store, mimecastt.com, mimecast.ai, mimecsat.co.uk. Note that with an increase in TLDs and the infinite combination of similar domains by just switching a letter here or there, proactively registering your way into domain protection is an approach that only registrars could love!
• Parked or redirect domains - These are domains that we might use in the future or are using in a light way, such as to redirect web traffic to specific areas of the mimecast.com website. We don’t use them as email sending domains. Domains that came along with acquisitions were also generally slotted here. Examples of these include com, mimecast.com.au, and mimecastercentral.com.
• Active Email Sending Domains – These are the email “crown jewels” for Mimecast that this project is largely focused on protecting. This category includes domains that we - including those from acquired companies - are actively sending email from or have in the recent past. Examples of these include mimecast.com, ataata.com, and solebitlabs.com.

While there is nothing truly magical about the above categorizations, I expect that you, the savvy reader, have picked up on the rationale. Given how impactful the move to p=reject can be if not done correctly, one doesn’t want to turn it on and just hope for the best. Given this, the Mimecast DMARC project team is progressing through our 350+ owned domains in exactly the order listed above, pausing between each stage to assess the business impact, if any. And of course, monitoring the DMARC reports that were sent back to DMARC Analyzer from DMARC reporting email receivers.

The Bottom Line

Phase 1 included configuring all the cybersquatted domains’ DNS’ to p=reject. Given these domains never have and never will be used to legitimately send email, we immediately set those to p=reject, and we anticipate no downside to blocking email purportedly sent from those domains. Phase 2 included setting our parked and redirect domains to p=reject as well, and the DMARC reports from these are being closely monitored to make sure no issues arise.  

Phase 3, covering our active email sending domains including mimecast.com, will be a more complex step of the project. As expected, through this process we have discovered email senders using this domain that looked to be legitimate (not phishers or spammers) but weren’t configured properly with SPF or DKIM and thus were failing DMARC. This is where the internal sleuthing begins. Who owns those service providers internally? Should they still be actively sending email on our behalf? How best to get them aligned with DMARC? This is the security clean-up function that is part of any DMARC project.

In my next and final blog on this topic I will provide a project wrap-up and retrospective on what our key learnings and takeaways were. Until then, keep DMARCing!