In my role at Microsoft I am talking daily to Microsoft Partners and customers throughout the United States. One of the more popular conversation topics is email spam and spoofing of their domain. There are several email related DNS records available that the majority of organizations are either unaware of or worried about making changes for fear of “bouncing” email. Some of these DNS records are SPF, MX, DMARC, and DKIM. These types of records have existed for many years and are not new. This blog provides information about DKIM DNS records, what they are, and how to properly implement them in Microsoft Office 365.
First, a little explanation on what DNS DKIM records really are. DKIM is short for DomainKeys Identified Mail. DKIM records are designed to help prevent spammers from spoofing your domain in emails sent to other organizations (as you) as well as to prevent inbound emails coming into your environment that appear to be coming from others. Spoofing is a very common technique used by spammers in phishing campaigns designed to trick users into providing their user credentials. DKIM records are not a requirement for email services, but certainly help in the constant battles against malicious senders. And, best of all, DKIM records are extremely easy to setup for use in Microsoft Office 365.
If you are using Microsoft Office 365, you’ll find in your settings (reviewed later in this blog) that DKIM was enabled for your tenant domain which is yourdomain.onmicrosoft.com at the time in which your email environment was setup. However, DKIM records were not enabled for your custom domain that you also likely have defined and is what is being used for email delivery (yourdomain.com instead of yourdomain.onmicrosoft.com). It is highly recommended by Microsoft and any email expert (I’ve been doing this for over 20 years) that you setup your DKIM, SPF, and DMARC records properly. Unfortunately, a study in August 2017 showed that fewer than 10% of all Fortune 500 companies have proper records defined. Over 90% of these large companies do not have basic email security defined.
I have documented the steps below that describe how to setup DKIM records for your environment. I have also created a short YouTube video that walks through these steps as well. In this demonstration, I am using my lab environment as an example for Office 365. I am also using GoDaddy as the DNS hosting provider where I will create the CNAME records required for DKIM. As you read through the instructions, as with any good implementation plan you need to always consider a backout plan in case there are any problems. What is really nice about the implementation of DKIM records is that there is a basic enable/disable toggle within the Office 365 Admin Portal that can be used. This setting will disable the use of DKIM within minutes (based on my experience, but ultimately dependent on DNS replication).
YouTube Video Using the Steps Below:
Create DKIM Records for Office 365
Find Your CNAME Record Format for DKIM:
In this example I have provided steps using the GoDaddy.com administration portal for DKIM records. Similar steps to create the same CNAME records for DKIM may be used with other DNS providers.
Figure out the format of your CNAME DKIM records
- Logon to protection.office.com
- Select Threat Management and then Policy
- Select the DKIM panel
- From within the DKIM panel, if you click to highlight the yourdomain.onmicrosoft.com site, you will notice that DKIM is enabled for this particular domain. However, when you click to highlight your custom domain (yourdomain.com) notice how it is not enabled.
- With your custom domain highlighted, click on the Enable option (this will not enable DKIM at this point since the records have not been created).
-
The error message shown provides the correct format of the DKIM selector record to create. In the case of this lab environment where kmartins.com is the custom domain, the correct format of the CNAME records are below. Be sure to highlight the records in the error message and paste them to a NotePad file for easy reference later.
-
DKIM Records:
-
CNAME Record 1:
- Host: selector1_domainkey
- Points to: selector-1-kmartins-com._domainkey.M365x378908.onmicrosoft.com
-
CNAME Record 2:
- Host: selector2_domainkey
- Points to: selector-2-kmartins-com._domainkey.M365x378908.onmicrosoft.com
-
-
- Now that you have the correct format of the CNAME records, let’s move on to the next section to create the records.
Create CNAME Records in GoDaddy
In this section, you will logon to GoDaddy to create your CNAME records
- Logon to GoDaddy.com using your DNS Administration Account
- Go to the DNS Management area to display the DNS records defined for your environment.
-
At the bottom of the DNS records screen, choose the Add option.
- Under Type, choose CNAME record.
- In the Host area for our first record, enter selector1._domainkey
- In the Points to Area for our first record, enter the record you copied into the NotePad file in the previous section. In my lab example, it is selector-1-kmartins-com._domainkey.M365x378908.onmicrosoft.com
-
Repeat the same set of instructions above to enter the second record
- Under Type, choose CNAME record.
- In the Host area for our second record, enter selector2._domainkey
- In the Points to Area for our first record, enter the record you copied into the NotePad file in the previous section. In my lab example, it is selector-2-kmartins-com._domainkey.M365x378908.onmicrosoft.com
Verify CNAME Records are Replicated
Before we take the final step to enable DKIM on your custom domain, we need to first make sure the new DNS records have been replicated. A quick and easy way to determine this is use mxtoolbox.com.
- Go to MXToolbox.com
- Choose the More drop-down option
- In the more area, locate the field for DKIM record lookup. In there, paste the Points To record you used above. In our example case, this record is Selector-1-kmartins-com._domainkey.M365x378908.onmicrosoft.com
- Select the greed play button to begin the search.
- The search result will indicate if the new record was found or not. Generally, all green check marks is a good sign.
Enable DKIM in the Office 365 Portal
In this section, you will enable the use of DKIM records for your custom domain.
ProTip: Always have a backout plan. In this case, if there are any issues with email delivery you can just as easily disable the use of DKIM records in the portal as it was to enable them. You do not have to remove the DNS Records created earlier to disable the use of DKIM records, simply Disable the option using steps similar to those below.
- Logon to protection.office.com
- Select Threat Management and then Policy
- Select the DKIM panel
-
From within the DKIM panel, click to highlight your custom domain: yourdomain.com site. Notice that DKIM is still not enabled for your domain. Simply click on the option to Enable DKIM signatures and within a few seconds that status says Enabled. To disable it, click on the Disable option. It only takes a few seconds to enable or disable DKIM for your organization in this portal.
Note: If you receive an error stating that the CNAME records still do not exist, I recommend you try this activity an hour later as there may still be DNS replication issues. If it still does not work, verify you have properly configured your DKIM records in DNS. Both records must be published for this to work correctly.
Verify DKIM is Now Used
Now that DKIM is enabled for your environment, you want to test that it is working properly. We will do this by sending an inbound email to your account in the organization and reviewing the email headers of the email.
- From an email account external to your organization (use an external Outlook.com or Hotmail.com account), send yourself an email
-
In the email received to your Inbox at your organization, open it. In the email, click File. In the options that then appear, choose Properties at the bottom of the screen.
- In the bottom of the Properties screen for this email, locate the Internet Headers section. Copy all of the information contained here to a NotePad for easier review (there is a lot of information in here). Click within the headers area, use CTRL-A to select the text and then a CTRL-C to copy it. Then paste into a NotePad file.
- In the NotePad file, choose Edit and then Find to search for the DKIM record being used (or not). Search for the term DKIM.
- The search results will display dkim=pass (signature was verified) if the incoming email successfully used the DKIM record. See below for possible DKIM= variables for troubleshooting.
DKIM Results (Troubleshooting):
If you have taken the steps above to implement DKIM records, but you are not receiving a Pass in the results, other results could help with troubleshooting. Below are a list of possible DKIM records that may be seen in the headers of a test email as per RFC6376.
Pass: The message was signed, the signature or signatures were acceptable, and the signature passed verification tests.
Temperror: The message could not be verified due to some error that is likely transient in nature, such as a temporary inability to retrieve a public key.
Fail: The message was signed and the signature or signatures were acceptable, but they failed the verification test.
Policy: The message was signed but the signature or signatures were not acceptable.
None: The message was not signed
Neutral: The message was signed but the signature or signatures contained syntax errors or were not otherwise able to be processed.
Additional Information:
Microsoft Documentation for email related DNS record setup:
Microsoft Inspire 2018 Session
Brian Reid delivered a fantastic session at Microsoft Ignite 2018 in Orlando, FL called “So Long and Thanks for all the Phish.” This session is available on YouTube and is worth the 45 minute watch for better understanding of all email DNS records.
