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

Like any organization with a significant online presence, 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. In fact, I recently showed real attempts to impersonate the Mimecast brand in both phishing emails as well as via clones of our login page on mimecast.com. We certainly aren’t alone. If Mimecast can be a target, is there any reason to believe your organization can’t be?

Implementing DMARC

A key part of any program to rein in the illegitimate email spoofing of an organization’s domains is the use of the DNS Authentication standard, DMARC. But DMARC is not a standard or technology that can be quickly deployed, configured, turned on, and forgotten. To implement DMARC well, organizations must first carefully monitor and assess their owned domains and sort out those email senders that are sending email on their behalf both legitimately and illegitimately. And then once p=Reject is reached for all owned domains, they must create a program of ongoing monitoring. This last step is critical, as the online world is not static.

The dirty secret of email is that by design anyone can send email claiming to be from any domain they want. Of course, the true domain owner can stop them. DMARC, along with its close cousins, SPF and DKIM, are the technologies that the domain owner can use to keep proper control of their email domains.

Any domain owner can easily create a DMARC record in their DNS entry and set it to p=Reject, but first they must make sure that doing so won’t cut off critically important or legitimate emails that might be coming from “good spoofers.”

For instance, most organization use Salesforce.com, Marketo, Netsuite, or other applications that uses email to communicate on its behalf, meaning these are good spoofers with whom DMARC should not interfere. In fact, there is an excellent chance that IT and security teams don’t know who all the legitimate spoofers are that are currently sending email on behalf of their organization.

Keep in mind that p=Reject is a public declaration and request; email receivers should reject any emails that are purportedly sent from the associated domain but that aren’t properly configured in the domain’s SPF record or aren’t signed by the organization’s private DKIM key.

The Mimecast Journey to P=Reject

To better protect our owned domains, Mimecast has initiated a project to complete its own move to p=Reject for all our owned domains. To check our progress or the state of another organization’s DMARC records, use our DMARC record checker to get the latest DMARC information for that domain. To save you the trouble I snapped our current configuration for mimecast.com below.

As a member of Mimecast’s internal DMARC project team, I will report back on progress via a series of articles to provide an inside look at what it takes to get to DMARC p=Reject. As a bonus, since Mimecast is a provider of a DMARC platform and service, the team also has representation from product management so that any learnings from this project can be fed directly back into the product and the associated service offerings.

The Bottom Line

The reality is that a DMARC project will surface some tricky IT and security questions and processes. Can anyone register new domains for your organization? What should the process be? What legitimate applications are sending emails on behalf of your domain currently? Who is the business owner of your email-sending applications? What do you do with the hundreds of typo-squatted domains that you own, but don’t use? How do you make sure that all new applications and domains go immediately to p=Reject going forward?

In the second part of this article series, I will provide details on the decisions and steps that we are taking to safely and efficiently get all our owned domains to p=Reject. At the completion of this article series, I hope what Mimecast did and what we prioritized can help inform your DMARC program.