Configuring DomainKeys Identified Mail (DKIM) helps you protect against spoofing by adding a digital signature to the Email header. In other terms you authorize your domain to associate, or sign, its name to an email message by using cryptographic authentication. As a result, the Email systems that receive Email from your domain, can determine the legitimacy of the incoming email, by using the public key published to your domain’s DNS records to decode the signature. DKIM, along with SPF, DMARC, and other technologies supported by Office 365 help prevent spoofing and phishing. Considering that DKIM relies on public key cryptography to authenticate and not just IP addresses, DKIM is considered a much stronger form of authentication than SPF.

A Sender Policy Framework record (SPF) is a system of domain names (DNS), that identifies which mail servers are allowed to send mail on your behalf. If a domain has SPF configured the receiving mail server can check if the claimed sender of the mail is allowed to send mail from that IP address. While SPF adds information to a message envelope, DKIM actually encrypts a signature within the message header. In this case, when a message is forwarded, portions of that message’s envelope can be stripped away by the forwarding server. Since the digital signature stays with the email message as part of the email header, DKIM works even when a message has been forwarded.

NOTE (DNS record): For DKIM – CNAME record (some domain hosters do not offer the possibility to create a CNAME record – in this case – the DKIM will not work for Office 365).


As a prerequisite, to add a DKIM signature for a the subdomain, two CNAME record must be published:

Host Name Point to Address TTL (s)
selector1._domainkey.<subdomain>.<domain>.<domainsuffix> selector1-<subdomain>-<domain>-<domainsuffix>._domainkey.<tenant> 3600
selector2._domainkey.<subdomain>.<domain>.<domainsuffix> selector2-<subdomain>-<domain>-<domainsuffix>._domainkey.<tenant> 3600

You needs to replace:

<subdomain> – Ex.: external
<domain> – Ex.: contoso
<domainsuffix> – Ex.: com
<tenant> – Ex.: O365contoso

The example record would look like this:

Host Name Point to Address TTL (s) 3600 selector2- 3600

Once published the CNAME records in DNS, the DKIM signing through Office 365 can be enabled. This will be done from the UI-browser or using the following PowerShell commands:



New-DkimSigningConfig -DomainName -Enabled $false

Set-DkimSigningConfig -Identity -Enabled $true


Confirm DKIM signing is configured properly

Wait a few minutes for the newly enabled DKIM domains to replicate throughout the network, then follow these steps to confirm that the DKIM is properly configured:

  • Send a message from an account within your Office 365 DKIM-enabled domain to another email account such as or (not AOL – it may not work because AOL may skip the DKIM-check if the SPF-check passes and aligns with the domain in the From: address)
  • The DKIM-signed message will contain the host name and domain you defined when you published the CNAME entries and should look as follows:

From: Example User <>

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;

s=selector2;; t=1429912795;


bh=<body hash>;

b=<signed field>;

  • In the Authentication-Results header, while the format used by the receiving service to stamp the incoming mail may vary, the result should include something like: DKIM=pass or DKIM=OK.


NOTE: If an SPF is already set for the tenant, there is no need to add one for the subdomain hosted in O365. As well, if DMARC is set for the principal domain, it will also apply for the subdomain, as long as the settings for the subdomain are no different.