Outbound DKIM Signing in Office 365 (Part 2)

If you would like to read the first part in this article series please go to Outbound DKIM Signing in Office 365 (Part 1).

Enabling Outbound DKIM in Office 365 – Continuation

Now that we have created all the necessary DNS records, we need to enable DKIM-signing for the domain within Office 365. We do this by logging into the Office 365 portal with an admin account, and navigating to our Exchange Admin Center (EAC):

Figure 1

Once in the EAC, navigate to protection and then dkim:

Figure 2

In here we select the domain we want to enable outbound DKIM-signing for and click on Enable:

Figure 3

If the CNAME records we created previously were not created correctly, or if DNS has not yet fully propagated, we will receive the following error message, which also tells us the exact values the records should have:

Figure 4

Once everything is ready, DKIM will be enabled:

Figure 5

Alternatively, we can also use PowerShell to do this. We start by connecting to Exchange Online:

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session

Figure 6

Once connected to our Exchange Online, we use the New-DkimSigningConfig cmdlet to enable DKIM:

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

In this case I am using –WhatIf as DKIM has already been enabled:

Figure 7

We can also easily confirm if DKIM is currently enabled or not by using the Get-DkimSigningConfig cmdlet:

Figure 8

And that is all we need to do to enable DKIM! Now it is time to test it.

Testing DKIM

In order to check if our emails are being signed with a DKIM signature, we need to wait a few minutes for all the changes to take effect, send a new email and check its Authentication-Results header as before. Now that I have enabled DKIM, this is how an email header looks like:

Figure 9

Notice the different d= and s= when compared to our example before enabling DKIM:

Figure 10

Now the selector and d= domain have changed and are aligned with the From: address.

Remember that if you have another mail server positioned after Office 365 that relays out to the Internet, it may modify the message content and cause the DKIM signature not to verify. If this occurs, you should ensure that Office 365 is the last service to relay out to the Internet, otherwise you may get some email bounces due to a broken DKIM signature.

Disabling DKIM in Office 365

If, for some reason, you decide to disable DKIM, this can be done through the Exchange Admin Center in the same way we used to enable DKIM:

Figure 11

Or using the following PowerShell cmdlets:

$dkim = Get-DkimSigningConfig <domain>

$dkim[0] | Set-DkimSigningConfig –Enabled $False

However, you need to understand that this does not completely disable DKIM. Remember that Office 365 is already signing emails using a default DKIM signing configuration as we saw at the beginning of this article series. If, for example, I now disable DKIM for my domain, emails will start to be sent out using the following DKIM config again:

Figure 12

In this case, the selector and d= domain contain the values where the CNAME would point to if DKIM-signing was still enabled for nunomota.pt.

Basically, if we enable DKIM ourselves, the d= domain will align with the domain in the From: address, If not, it will not align and instead will have our organization’s initial domain.

DKIM Selectors and Key Rotation

In order to enable DKIM, we had to configure two DKIM Selectors “entities” and I mentioned that this was for key rotation.

Before going into further details, let us go back to the very basics of DKIM. Yes, once more 🙂

  1. As email authentication method, DKIM Keys verify that an email has not been modified while in transit;
  2. Typically, but not in the case of Office 365, domain owners generate a pair of keys: a public and private one which are used to sign emails;
  3. The public key exists as a TXT file in the domain’s DNS record;
  4. The private key is kept on the domain’s mail server;
  5. When an email is sent, the outgoing server appends a digital signature using the private key;
  6. This digital signature is added to the DKIM signature header in the email;
  7. When receiving the email, the recipient verifies the signature of DKIM Keys using the sender’s public key (which is published in the public DNS);
  8. A matching signature means a successful validation.

As with all passwords, the longer they go unchanged, the higher the risk of them being compromised. The same applies to DKIM keys. It is a best practice to rotate DKIM Keys every few months. This is typically done by creating a new selector/private key/public key set. Once the keys have been created, the public key is published in the public DNS record, and the outgoing mail server re-configured to use the new private key (the old key should be kept for a at least a week, after which it can be safely removed).

However, many organizations neglect to do this, mainly because it is not an easy task and a few things can go wrong:

  • DNS negative caching can cause some issues. If a DNS resolver queries for our public key before we have published it, then it will cache that the key does not exist (although hopefully only cache this for a short time);
  • When reusing a selector that we have used in the past (but this time with a new key), then we should wait 24 hours after publishing the new public key before we start signing emails with the new private key. This will avoid having the non-existent key cached at remote ISPs who happen to look it up based on an old message which used the same selector;
  • Suppose we rotate our DKIM keys at 10:00. A couple of minutes before, a user sent an email which was still signed with the old key. When that email arrives at the recipient’s email system at 10:05, it can no longer be validated.

Well, these problems do not exist with Office 365 🙂 The main reason why we created two CNAME records is, as already mentioned, for seamless key rotation. Because we are using CNAME records, EOP can rotate the keys whenever it needs to. As EOP controls the public and private keys, when it needs to rotate the keys it simply updates the private key on the backend and the public key in Microsoft’s DNS servers. The CNAME in our (customer’s) DNS record still points to Microsoft, but what it points to is a new key. We, as a customer, do not have to do anything!

Let us look at the previous example above where we want to rotate our DKIM keys. The way it works in Office 365 is as follows:

  1. On April 3rd 10:00, Microsoft publishes public key #2 at CNAME #2 (in fact, it is already there as we have seen);
  2. On April 10th 10:00, EOP starts signing outbound emails with key #2;
  3. On April 17th 10:00, it is assumed that all emails signed with key #1 are out of the system and everyone else’s system too (as we have been signing all emails with key #2 for a week now);
  4. EOP then updates key #1. Emails sent more than a week ago cannot be verified anymore, but they should not need to be re-verified anyway;
  5. The next time EOP updates the keys a few months later, it repeats the same process: it flips back to key #1 (which contains a rotated key) and then updates key #2 a week later.

Using this approach, Microsoft enables its customers to automatically rotate their DKIM keys without them having to do anything.

These changes happen automatically behind the scenes as EOP alternates between changing the DKIM signing selector (selector1 vs selector2) which correspond to CNAME 1 and CNAME 2. Because our domain has these two CNAME records pre-populated, we do not need to be aware of which selector or key is active because EOP is in control.

Although this entire process is automatic, customers can still force EOP to rotate DKIM keys. This is done through the Exchange Admin Center and by navigating to protection and then dkim. Select the domain you want to rotate the keys for and click on Rotate:

Figure 13

EOP will then report that the DKIM keys for this domain are being rotated:

Figure 14

Before rotating our keys, we were using Selector1:

Figure 15

After EOP has rotated our keys, which will take approximately a week to complete the entire process as described above, we will start using Selector2:

Figure 16


In this article series we had a brief look at what DKIM is, how it works in Office 365, how we can enable outbound DKIM-signing for our domain and ended discussing DKIM Key Rotation.

If you would like to read the first part in this article series please go to Outbound DKIM Signing in Office 365 (Part 1).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top