Enabling DKIM in Exchange Online

Spam is the bane of all messaging administrators, as well as a major pain for all email users. Using email means a consistent battle against spam, malware, and unwanted nonsense flooding your inbox. There are a number of different tools and tactics we, as administrators, can use to reduce the impact of these attacks and recently Microsoft has added another one to the toolboxes of Office 365 customers. In this blog post I'm going to explain what DKIM is, and how you can use it to help make the world a safer place for legitimate email messages.

What is DKIM?

Domain Keys Identified Mail (DKIM) is a technology that cryptographically validates that an email message came from the domain it appears to have come from. In short, it’s a more advanced version of Sender Protection Framework (SPF). That’s not to say you should disregard SPF once you have DKIM up and working. DKIM works as a complement to SPF. Both technologies working together can offer a much better validation of messages.

How does DKIM help fight spam?

DKIM does not directly prevent any spam. DKIM itself does not filter or identify spam, but implementation of DKIM makes it much harder for spammers to spoof your domain. Widespread implementation of DKIM would make it much easier to identify the domains that spammers use, and thus reduce spam for us all.

Conversely, implementing DKIM can make it easier for spam filtering systems to validate messages based on your domain’s reputation.

Does DKIM help prevent phishing attacks against my users?

Yes, or at least it helps prevent phishing attacks where the attacker spoofs the email address of someone within your organization. While that is not perfect protection, it certainly is helpful in the event of targeted phishing attacks that are designed to impersonate your organizations executives or helpdesk personal.

Is there any downside to enabling DKIM?

In the process of researching DKIM for this blog post, I also looked for any reason enabling DKIM on your Office 365 tenant might cause problems.

The short answer is no. There is no downside to enabling DKIM in Office 365. There are potentially some problems you could cause yourself with a poor DKIM implementation on your own Exchange servers, but that is not a concern here. Microsoft has done 99% of the work of deploying DKIM for you, and there really is not much you can screw up. As long as you deploy the required DNS record properly (instructions below) you’ll be golden.

I have seen some Office 365 customers questioning why Microsoft is turning on DKIM now since DKIM is over 10 years old. The short answer to that concern is Microsoft originally backed a competing anti-spoofing standard. Much like the HD-DVD player I bought for my Xbox 360, that standard has died. Moving to DKIM now is just Microsoft correcting course to the standard that the rest of the internet is already using.

What is DMARC, and how does it relate to DKIM?

Domain-based Message Authentication, Reporting and Conformance (DMARC) is a complementary system to both DKIM and SPF. From Wikipedia:

DMARC is built on top of two existing mechanisms, Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). It allows the sender of an email to publish a policy on which mechanism (DKIM, SPF or both) is employed when sending email and how the receiver should deal with failures. Additionally, it provides a reporting mechanism of actions performed under those policies. It thus coordinates the results of DKIM and SPF and specifies under which circumstances the From: header field, which is often visible to end users, should be considered legitimate.

There is nothing you need to do at this point to enable DMARC in your Office 365 tenant. You can verify DMARC is evaluating messages within your tenant by looking for the following headers added to your email messages:

                Authentication-results: protection.outlook.com; spf=pass
                (sender IP is xx.xx.xx.xx) smtp.mailfrom=user@contoso.com
                dkim=none (message not signed) header.d=none; dmarc=none
                action=none header.from=contoso.com;

Enabling DKIM in Exchange Online

DKIM is not turned on by default for your Office 365 tenant. It’s not very hard to turn it on, but there are a few simple steps we need to complete.

The first step to turning on DKIM is to publish the required DNS records for your domain. You’ll need to setup two CNMAE records for each vanity domain.

As of this writing (March 2016), the domain setup wizard in the Office 365 portal has not caught up with DKIM yet. The records you’ll need to create are not listed there. To figure out what your DKIM records needs to look like, run the following command in your Exchange Online tenant.

               Get-DkimSigningConfig <domain> | FL *CNAME

 The output from the command is the data part of your CNAME record. The HOST part of your CNAME record is going to be selector1._domainkey.<domain> and selector2._domainkey.<domain>. For my domain, the records look like this:

Once those DNS records are in place, and you’ve verified they are publicly accessible, you can turn on DKIM for your domain with the following command.

              New-DkimSigningConfig –DomainName <domain> –Enabled $true

You can confirm DKIM is enabled with

              Get-DkimSigningConfig <domain>

That’s all there is to it. Microsoft does all the really hard work of implementing DKIM for you, you just need to add a couple of DNS records and run a simple PowerShell command.

There you have it, everything you need to know to get DKIM up and running in your Office 365 tenant.