Share via

Office 365: Enabling DKIM for Custom Domains

  • Article

Before we start with this topic I would like to explain the existing methodologies used to prevent spoofing and phishing, these two together cause a great threat to almost all organizations around the world. Most of us knows SPF records are considered critical and highly recommended to prevent any spoofing and phishing attack in the name of your organization, however there are many organizations which have not enabled SPF lookup for inbound mails to validate if the mail came from a legitimate source. With time passing DMAC and DKIM are the new two features introduced to validate the authenticity of the sender. Let us try to understand how each of these work and later move on to implementing DKIM same in Office 365. 

How an SPF record works? 

SPF uses a DNS TXT record to provide a list of authorized sending IP addresses for a given domain. Those companies with mail servers which are enabled to do a SPF lookup for all received mails will validate the authenticity of the sender by doing a reverselookup for spf record of sender domain. Here, the receiving server will look at the email header for "Mail From" portion extract the domain from name here and validate the SPF record published for this domain. In the below example, fabrikam.com domain is extracted and spf reverselookup is done for fabrikam.com. If the sending server IP and IP of servers mentioned in the SPF record matches the mail is allowed in to the organization else the mail is rejected. When we enable strict SPF lookup in the receiving side, mails from organization who doesnt have a spf record published will be straight away rejected.

Example Header:

Mail from: Josh@fabrikam.com

Rcpt to: astobes@contoso.com

How a DKIM works and what are the extensive security over SPF?

"Domain Keys Identified Mail" is an advanced security feature which is used along with SPF to prevent spoofing and phishing attack on the domains. When DKIM is enabled for your domain, all emails sent out from the server will be digitally signed using cryptographic authentication. Receiving server can use this digital signature to determine if the email is legitimate. DKIM uses a private key to encrypt the header of all outgoing mail. Receiving server will look for the DKIM public key (published in the DNS) of the sending domain to decode the signature. If the mail is coming from an unauthorized server, the signature can’t be decoded there by preventing any spoofing attempt. 

We can say SPF and DKIM together provides a greater protection from Spoofing attack. Consider two domains spoofing.com  and genuine.com hosted in same cloud multitenant infrastructure. Now, spoofing.com user is sending out spoofing message as user@genuine.com to user@recepient.com.  SPF records for both the domains spoofing.com and genuine.com will be same in this case so there is a chance that recipient.com will accept the mail after validating the SPF record. Considering DKIM implemented along with SPF, recipient.com will try to decrypt the signature of genuine.com using the public key published using DNS. If decrypted mail is allowed in to the organization else rejected. 

How DMARC works? Advantages of DMARC over SPF.

To understand DMARC, we should understand below two headers. 

  1. a) "Mail From" address Identifies the sender and specifies where to send return notices if any problems occur with the delivery of the message, such as non-delivery notices. This is sometimes called the 5321.MailFrom address or the reverse-path address. SPF records are checked against the domain in this header. 
  2. b) "From" address is the address displayed in outlook, "From" Address is not authenticated with SPF. In short, user can still get a spoofed mail which had passed SPF against "Mail From" address. DMARC records are verified against domain of this header. 

DMARC works the same way as SPF, here the DMARC TXT records will have the details of the authorized sending servers. As soon as a mail is received by the receiver server “FROM” header is stripped and the sending domain servers are validated against DMARC records. If the sending servers are not the authorized servers, mail is dropped.

Advantage of DMARC over SPF, 

In the below example, "Mail from" and "From" headers are different. Here SPF is validated against "Mail from" header, so even if the sender had spoofed the "From" header the mail will be rejected post validating against DMARC records. 

S: Helo woodgrovebank.com
S: Mail from: phish@phishing.contoso.com
S: Rcpt to: astobes@tailspintoys.com
S: data
S: To: "Andrew Stobes"  <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security"  <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings User,
S: 
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S: 
S: http://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

Steps for enabling DKIM in office 365 domains.

If we have not enabled DKIM, Office 365 automatically creates a 1024-bit DKIM public key for all the custom domains and the associated private key which are stored internally in Microsoft datacenters. By default, Office 365 uses a default signing configuration for all domains that do not have a policy in place. This means that if DKIM is not manually setup, Office 365 will use its default policy and keys to enable DKIM. Also, if we disable DKIM signing after enabling it, Office 365 will automatically apply the Office 365 default policy for this domain.

**a. Publish two CNAME records O365 custom domain in DNS. **

Office 365 performs automatic key rotation using these two records. For custom domains in addition to the initial domain in Office 365, we must publish two CNAME records for each additional domain. So, if there are two custom domains in office 365, we must publish four additional CNAME records.

 

**In our example: **

Domain guid: cloudexchangers-com  (copied from the MX record of the domain cloudexchangers.com) 

Domain: cloudexchaners.com

InitialDomain: cloudexchangers.onmicrosoft.com

**b. Enable DKIM for each domain in Office 365 portal. **

To enable DKIM signing for your custom domain through the Office 365 admin center. 

  • Sign in to Office 365 with our work or school account.
  • Select the app launcher icon in the upper-left and choose Admin.
  • In the lower-left navigation, expand Admin and choose Exchange.
  • Go to Protection > dkim.
  • Select the domain for which we want to enable DKIM and then, for Sign messages for this domain with DKIM signatures, choose Enable. Repeat this step for each custom domain.

To enable DKIM signing for your custom domain by using PowerShell

  • Connect to Exchange Online using remote PowerShell.
  • Run the following cmdlet:

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

Where domain is the name of the custom domain for which you want to enable DKIM signing.

For example, for the domain cloudexchangers..com:

 New-DkimSigningConfig -DomainName cloudexchangers.com -Enabled $true

To disable the DKIM signing policy by using Windows PowerShell.

Disabling the signing policy does not completely disable DKIM. After a period of time, Office 365 will automatically apply the default Office 365 policy for our domain. 

Steps: 

Connect to Exchange Online using remote PowerShell and execute 

$p=Get-DkimSigningConfig -identity <domain>
$p[0] | set-DkimSigningConfig -enabled $false

For example:

$p=Get-DkimSigningConfig -identity cloudexchangers.com
$p[0] | set-DkimSigningConfig -enabled $false

Validate DKIM signing is configured properly for Office 365.

The DKIM-signed message will contain the host name and domain we defined when we published the CNAME entries. Validate the header of the mail sent out, it should be as below. 

From: anoop@cloudexchangers.com
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; 
s=selector1; d=cloudexchangers.com; t=1429912795; 
h=From:To:Message-ID:Subject:MIME-Version:Content-Type; 
bh=<body hash>; 
b=<signed field>;