Outbound DKIM Signing in Office 365 (Part 1)

by [Published on 3 May 2016 / Last Updated on 3 May 2016]

In this two-part article, we will explore how to enable outbound DKIM signing in Exchange Online.

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


About a year ago, I wrote an article entitled DKIM and DMARC in Office 365 where I explored what DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC) are, and how exactly they work with Exchange Online in Office 365.

At the time of writing that article, Office 365 only supported inbound validation of DKIM over IPv4 and IPv6. Outbound DKIM signing was not yet available but was in the roadmap. Well, it is here now!

Quick Recap on DKIM

DKIM is a public key encryption methodology that works in conjunction with Sender Policy Framework (SPF), by cryptographically linking each message with the sending domain, thus reducing the likelihood of our business email being detected as spam.

An SPF record indicates which servers are authorized to send mail for a domain. Recipient servers perform the check “is this email coming from an authorized mail server”? If not, then the email in question is more likely to be spam. Our SPF DNS record lets the recipient server perform this verification. The SPF check verifies that an email comes from authorized servers.

A DKIM record adds a digital signature to emails our organization sends. Recipient servers perform the check “does the signature match”? If yes, then the email has not been modified and is from a legitimate sender. Our DKIM DNS record lets the recipient server perform this verification. The DKIM check verifies that the message is signed and associated with the correct domain.

DKIM uses DNS to publish a Public Key so that any party that wants to validate a signature can easily find it and use it to validate the DKIM signature. When a sender wishes to send an email to a recipient, the sending server calculates a crypto signature that covers the relevant parts of the message using the Private Key. The signature is then placed in an email header and the message is sent. At any point in trave,l the signature is validated using the public key.

Spoofed emails will not carry a valid signature so these are now easy to detect. Using DMARC it is possible to help the recipient decide what to do with these messages that do not pass validation, typically asking for their rejection and reporting to the legitimate organization for further investigation.

DKIM in Office 365

For inbound validation, we do not need to do anything as Exchange Online Protection (EOP) automatically validates DKIM through the DKIM-Signature header in the message headers. In the screenshot below we can see this header and the DKIM signature itself of an email sent from Gmail to Exchange Online. We can also extract certain information from it such as the fact that the signing domain is gmail.com (d=gmail.com).

The result of a DKIM-Signature validation is stamped in the Authentication-Results header and, for now, in a temporary X-DkimResult-Test header as well. In the following screenshot we can see both the DKIM signature and its validation:

Figure 1

If a message fails DKIM verification, the header will say dkim=fail with the reason for the failure in parentheses such as invalid body hash, key query timeout, no key for signature, and so on.

If I send an email from Office 365 tenant, it seems that emails are already being sent with a DKIM signature:

Figure 2

As we can see from the first Authentication-Results, it says dkim=pass! This is because Microsoft is adding DKIM signatures to outgoing email, even when customers have not explicitly enabled DKIM-signing for their domain(s). This has been gradually rolling out to everyone and my guess is that, by the time of publishing this article, it will probably have already been enabled for all tenants.

In my case I have not yet enabled DKIM signing, so EOP created a default signing policy for my domain and is using that in the selector and d= fields in the DKIM signature (notice that in the DKIM signature, d= is set to nunomota.onmicrosoft.com and not nunomota.pt):

Figure 3

This is because Microsoft does not have access to the nunomota.pt domain to publish the required DNS records for DKIM. However, it can put this information in the headers to uniquely identify my domain. This way, receivers can use the above information to determine if the email is a spoofed email or not.

As we will see next, when we enable DKIM manually, the selector and d= domain will change so that it aligns with the From: address. In my case, it should change to s=selector1; d=nunomota.pt.

Enabling Outbound DKIM in Office 365

With other email services/systems, the customer has to do all the work, including publishing their public key in DNS and configure the email servers to sign messages with their private key. An important difference with the way Office 365 implements DKIM is that customers only need to publish two CNAME records which delegate the customer’s namespace to Office 365.

So, in order to enable EOP to sign our outbound messages, first we need to publish these two CNAME DNS records (not TXT records!) for each domain we want to sign. These records are as follows:


Points to









This is what we use in our MX record(s) for our domain, more specifically, what appears before mail.protection.outlook.com. For example, the MX record for my nunomota.pt domain is:

nunomota.pt. 3600 IN MX 0 nunomota-pt.mail.protection.outlook.com.

As such, my <domainGUID> is nunomota-pt.


This is the domain that we signed up with for Office 365. For example, in my case, this is nunomota.onmicrosoft.com.

Now that we have these two values, the records I need to create for my nunomota.pt domain are:


Points to








Figure 4

This DKIM selector hosts names are based on the formal DKIM naming convention that we have to follow to publish information about DKIM that represents a specific domain name. These two selectors will be used alternatively to sign each e-mail that gets sent from our organization’s users. The two CNAMEs are so that EOP can perform automatic DKIM key rotation for us, which we will discuss in the next part of this article series.

Once more, in a standard DKIM implementation, the DKIM selector host record is implemented as a TXT record that holds the public key that recipients will use to validate our email’s signature. As Office 365 is a “hosted environment” and Microsoft does not have access to our DNS, we publish instead CNAME records that redirect DNS queries requests to the special Office 365 DKIM selector record on the <domain>.onmicrosoft.com domain, which in turn contain our public key.

Every domain gets their own DKIM keys, they are not shared among customers (for obvious reasons). These keys are not even shared among domains within the same customer.

We can verify we created these records correctly using a variety of methods, such as using the useful MXToolbox:

Figure 5

We can also query the selector1-nunomota-pt._domainkey.nunomota.onmicrosoft.com record to see exactly what it resolves to. As expected, they are TXT records that contain our public key(s):

Figure 6

The same queries this time performed using MXToolbox:

Figure 7

Once more, we need to create these 2 CNAME records for each domain we have in Exchange Online that we want to enable DKIM signing for.


In the first part of this article series, we had a brief look at what DKIM is, how it works in Office 365 and started the process of enabling outbound DKIM-signing for our domain. In the second and final part, we will finish configuring DKIM, see it action and look at DKIM Key Rotation.

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

See Also

The Author — Nuno Mota

Nuno Mota avatar

Nuno is an Exchange MVP working as a Senior Microsoft Messaging Consultant for a UK IT Services Provider in London. He specializes in Exchange, Lync, Active Directory and PowerShell.


Featured Links