In Office 365 based environment, the process of signing outgoing E-mail using DKIM signature happens automatically for each of the Office 365 tenant domain names.
Article table of content | Click to expand
Implementing DKIM (Domain Keys Identified Mail) in Office 365 | Article Series
- DKIM – Domain Keys Identified Mail | Basic introduction | Part 1#5
- DKIM as standard that based upon the Public key infrastructure | Part 2#5
- DKIM flow in Office 365 | Part 3#5
- Outbound DKIM signing and DNS infrastructure | Building the required DNS records for Office 365 | Part 4#5
- How to enable outbound DKIM signing for your domain in Office 365 |Part 5#5
I emphasize the term “our public domain name” because, this “automatically DKIM signature”, is implemented by using the default Office 365 DKIM selector hostname who “embeds” his hostname as part of the E-mail message.
The Office 365 DKIM Selector name is based on a domain suffix that is different from the public domain name of the Office 365 recipients.
The scenario in which the DKIM Selector, hostname uses a different domain name from the domain name that he represents could cause some issues when the receiving mail server uses an additional standard named DMARC.
The general concept regarding the subject of using outbound DKIM signing in Office 365 based environment is that every E-mail message that is sent by the Exchange Online server to external recipients will include a DKIM signature.
[Source of information – Manually hooking up DKIM signing in Office 365]
Finally, even if you don’t enable DKIM, Office 365 will still (eventually) enable DKIM signing for your domain using the default signing configuration. Suppose that fabrikam.com was enabled by Office 365, not by the admin of the domain (so the required CNAMEs do not exist in DNS). DKIM signatures will look like the following:
From: Second Example <firstname.lastname@example.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
s=selector1-fabrikam-com; d=contoso.onmicrosoft.com; t=1429912795;
In the example above, the selector and d= domain contain the values where the CNAME would point to had DKIM-signing for fabrikam.com been enabled by the customer.Eventually, every single message out of Office 365 will be DKIM-signed. If you enable DKIM yourself, the d= domain will align with the domain in the From: address; if not, it will not align and instead will have your organization’s initial domain.
The above quotation could cause us to wonder about the purpose of – enabling the option of outbound DKIM signing for our public domain that is hosted in Office 365.
In other words, why should bother ourselves with complicated DKIM configuration settings, if the option of outbound DKIM signing in Office 365 based environment, will eventually be implemented without any need for intervention?
The simple answer is that technically; we don’t have to enable the DKIM signing for mail that is sent from our Office 365 tenants, but when using the “default Office 365 DKIM settings” for outbound DKIM signing, there is a drawback that I could be realized to a major drawback.
In case that we use the default Office 365 DKIM signing configuration, without creating a “custom DKIM settings” for our specific public domain name who was registered with Office 365, E-mail message that will be sent from our domain name, will include DKIM signature that will contain information about the default Office 365 DKIM signing selector host name.
This scenario, in which the E-mail message includes the host name of the DKIM signing selector that uses a different domain name, then the domain name that appears in the E-mail message, can be identified as a “problematic scenario” when an additional mail security standard named – DMARC is used by the “destination mail infrastructure”.
We will not get into a detailed description of the DMARC standard, but briefly mention that, when there is an implementation of DMARC standard, the DMARC verification process will look at the E-mail message header and check if the DKIM Selector host is “aligned” with the sender E-mail address domain name.
For example, if the sender E-mail address is: Suzan@o365pilot.com, the DMARC standard will verify if the host name of the DKIM Selector includes the domain name – o365pilot.com
In case that the DKIM selector, the host name is different (doesn’t include the domain name of the sender E-mail address) the DMARC standard “mark the E-mail message” as an E-mail message with a “problem”.
Attached a quotation that describes the DKIM process in this scenario:
[Source of information – DMARC – Frequently Asked Questions]
DMARC introduces the concept of aligned identifiers. Briefly, it means the domain in the RFC5322.From header must match the domain in the “d=” tag in the DKIM signature for DKIM alignment, and/or match the domain in the RFC5321.MailFrom field for SPF alignment. (Please see sections 3, 15.5, and Appendix B.1 of DMARC for more details.)DMARC doesn’t directly address whether or not an email is spam or otherwise fraudulent. Instead, DMARC requires that a message not only pass DKIM or SPF validation, but that it also pass alignment.For SPF, the message must PASS the SPF check, and the domain in the From: header must match the domain used to validate SPF (must exactly match for strict alignment, or must be a sub-domain for relaxed alignment).
For DKIM, the message must be validly signed and the d= domain of the valid signature must align with the domain in the From: header (must exactly match for strict alignment, or must be a sub-domain for relaxed alignment). Under DMARC a message can fail even if it passes SPF or DKIM, but fails alignment.
The best practice is to make the necessary efforts for creating the required the DKIM configuration settings for customizing Office 365 outbound DKIM signing for our specific domain name.
What is going on behind the scenes, when we enable Outbound DKIM signing for our public domain in Office 365?
When we use the Office 365 portal admin for enabling outbound DKIM signing for our domain name, the following steps will be implemented:
- Office 365 will automatically create a DNS query, looking for a specific CNAME record that he expects to find “under” our public domain name.
- In case that Office 365 finds the specific CNAME records, Office 365 will automatically generate two “new TXT records” that will be used a predefined host name and will contain the value of the DKIM Public Key of Exchange Online. This two TXT record will be created on the Office 365 DNS infrastructure (the DNS server who host the OnMicrosoft domain name).
- In case that Office 365 doesn’t find the specific CNAME records he expects to find, an error message will appear and inform us, that we (as the public domain owners) need to create the required two CNAME records
The two DKIM Selectors “entities” in an Office 365 based environment
The subject of the DKIM Selectors “entities” in Office 365 could be a little confusing.
In short, because Office 365 considered as “hosted environment”, will need to implement a process, in which we redirect DNS requests for the “formal DKIM selector record hostname” to the – dedicated\ special Office 365 DKIM selector.
When I use the term “dedicated\ special Office 365 DKIM selector record”, I mean – the Office 365 records that contain the DKIM Public Key, which needs to be used by the receiver mail server, for verifying the Exchange Online DKIM signature.
How to enable DKIM signing for your domain if it is hosted in Office 365
In the following section, we will review the required steps for activating the outbound DKIM signing in Office 365 (Exchange Online) for a public domain.
The correct flow of the task that we need to implement is:
- Verify the required information about the following DKIM Selector hosts names:
- The “standard” DKIM Selector record Hostname, that will represent our public domain name.
- The “special” Office 365 DKIM Selector record, that will serve as a logical container for the value of the DKIM Public Key.
- Create the required two CNAME record in the DNS server who hosts our public domain name.
- Enable (“activate”) the outbound DKIM signing option in Office 365 (Exchange Online) for the specific public domain.
- Test the outbound DKIM signing – this step could be considered as optional because there is not a mandatory need for checking the process of outbound DKIM signing. Even though, it’s highly recommended to test a scenario of “outgoing E-mail message” so we will be able to be sure that the outbound DKIM signing configurations was configured properly.
Our specific scenario characters
Our task is to enable the option of outbound DKIM signing to an E-mail message that will be sent by our organization recipients.
In other words, we want that each E-mail message that uses an E-mail address that includes our organization domain name – o365pilot.com, will be included DKIM signature (the DKIM signature that will be implemented by the Exchange Online server who represents our domain name).
Despite the need for implementing the task in a particular order that mentioned above, I would like to start with a common mistake, in which we start the process by trying to activate the outbound DKIM signing for a specific domain is the Office 365 admin portal.
In our scenario, we will try to activate the outbound DKIM signing for the domain name – o365pilot.com
- Login to Exchange Online admin portal
- On the left menu bar, choose the menu – protection
- On the left menu bar, choose the menu – dkim
In the following screenshot, we can see the list of the public domain name that was registered with Office 365 and in addition, the OnMicrosoft domain name.
In our specific scenario, we want to enable the outbound DKIM signing for the domain name – o365pilot.com.
We can see that by default, the status of the DKIM signatures is: Disabled
When we try to activate the outbound DKIM signing, the following error appears:
CNAME record does not exist for this config. Please publish a CNAME record first
The meaning of this error is that the required CNAME record not configured.
We will need to create the required CNAME records in our DNS (the DNS that hosts our public domain name) and only after we complete this phase, we can try to activate
the outbound DKIM signing for the specific domain.
Step 1#4 |Planning and creating the required set of DKIM selector DNS record
To be able to complete this task, we will need to configure sum of four host names who will be added to the DNS server that hosts our domain name.
The “four hosts name” will be added to our domain by creating two CNAME records.
Each CNAME record includes information about two hosts names.
In this phase, we “write down” this hostname that we will add in the next step to our DNS server.
Q1: Why do I need to write down four host names?
A1: In the Office 365 environment, we need to “declare” about two DKIM Selectors host names.
This DKIM selector hosts names are based on the formal DKIM naming convention that needs to be used for publishing information about a DKIM selected that represent specific domain names.
This two DKIM Selector hosts name will be “attached” Intermittently to each of the E-mail messages that will be sent by our organization recipients.
In a standard DKIM implementation, the DKIM Selector, host record is implemented as a TXT record that will hold the information about the value of the DKIM Selector Public Key.
Because Office 365 considered as a “hosted environment”, the use of the DKIM Selector record is a little different.
Office 365 infrastructure will use a set of two “dedicated TXT records” that will be used for “contain” the value of the DKIM Selector Public Key.
The “standard DKIM Selector, host record” that we will be published, will redirect DNS queries requests to the “special Office 365 DKIM Selector record”.
For each of the registered public domain in Office 365, we will need to create two CNAME records.
Each CNAME record will include two host names:
- The standard \ formal DKIM Selector, host names record, that will represent our domain name and will appear in the outgoing E-mail messages.
- The “special” Office 365 DKIM Selector record. This record is the actual TXT record that contains the value of the DKIM Selector Public Key.
When the receiving mail server looks for the DKIM Selector, hostname who appears in an
E-mail (E-mail that was sent by our organization recipient), the DNS query for the DKIM Selector, host name, will be redirected (by the CNAME record) to the “special Office 365 DKIM hostname” record.
The sum of the records that we need to “write down” and later configure this record in our pubic DNS is “4.”
Write down the information about the outbound DKIM signing records for the domain o365pilot.com
1#2 – Write down the host names of the “formal DKIM hostname” records.
The two DKIM Selector records that will represent our domain name are:
Given that we complete the required configuration setting in which we add and published the required DNS record, each E-mail message that will be sent from our organization recipients that use an E-mail address with the domain name o365pilot.com, will include the DKIM signature.
The DKIM signature will include the following DKIM Selector host names:
In a nutshell, the formula that we use for generating the “formal” DKIM Selector, host name in Office 365 environment is based on the following naming convention:
2#2 – Write down the host names of the “special Office 365 DKIM hostname” record.
The second set of DKIM Selector records that we need to “write down” is the special Office 365 records that will be implemented as the TXT record.
This TXT record will contain the value of the Exchange Online DKIM Public Key, which will be used by the receiver mail server for decrypting the HASH value of the DKIM signature.
In a DKIM scenario in which the receiver mail server needs to verify the DKIM signature, the receiver mail server will need to find the DKIM Host name that is “attached” to the E-mail message and create a DNS query for this hostname to be able to “fetch” the value of the DKIM Public Key from this TXT record.
In an Office 365 based environment, this request will be, “answered” by the DNS server by redirecting the receiving mail server to “other DKIM Selector record”.
The DNS uses the CNAME record, for redirecting the receiving mail server to the required Office 365 TXT DKIM Selector host record.
In our specific scenario, this FQDN of the special Office 365 TXT DKIM Selector hosts records is:
In the following diagram, we can see the structure of the two “special Office 365 TXT DKIM Selector hosts record” that we need to “write down” for later use when we have created the CNAME record.
In a nutshell, the formula that we use for generating the “special Office 365 TXT DKIM Selector hosts record” is based on the following naming convention:
Pay attention to the subject of the “dash” character that needs to be used for creating the Office 365 DKIM Selector host name.
A common mistake is to use the common “dot” character, instead of the “dash” character.
The following diagram, describe the “DNS flaw” that will implement by the receiving mail server that will try to verify the DKIM signature that will be “attached” to E-mail message that will be sent by
In our specific scenario, the host name of the DKIM Selector that represents the domain name
o365pilot.com is – selector1._domainkey.o365pilot.com
When the receiving mail server queries the DNS server regarding this hostname, the DNS “answer” will be a redirection to the “special Office 365 TXT DKIM Selector hosts record”.
When the receiving mail server query again the DNS server, but now, regarding the “special Office 365 TXT DKIM Selector hosts record”, the DNS “answer” will include the content of the Office 365 TXT record that contains the value of the DKIM Selector Public Key.
Step 2#4 |Creating the required two CNAME required for Outbound DKIM signing using GoDaddy DNS
In the following section, we will demonstrate how to create the required two CNAME records for a domain name that is managed via the GoDaddy DNS management interface.
In our specific scenario, we will add the required CNAME DKIM record for the domain name – o365pilot.com
In the DNS management, we will choose the option of – Add Record
We will click on the small black arrow
We will choose the option of CNAME (Alias) record
In our specific scenario, the CNAME record will include the following hosts names:
In the “upper section” named – HOST:, we will add the host name:
It’s important to understand that because this hostname is hosted “under” the domain name – o365pilot.com, the FQDN (Fully qualified Hostname) will be
In other words, don’t add the “full hostname” to the upper part, but only the “partial hostname” with Outlook the domain part.
The host name in the “upper part”, will be used for redirected requests to the dedicated Office 365 DKIM Selector record that includes the Office 365 DKIM Public Key.
In the “bottom section” named – POINTS TO:, we will add the following host name:
We will need to repeat this process for cratering an additional CNAME record that will use for redirecting DKIM request to additional Office 365 host named – selector2
To add an additional record, we will click on the button – ADD ANOTHER
In the “upper section” named – HOST:, we will add the host name:
In the “bottom section” named – POINTS TO:, we will add the host name:
We will save the new CNAME records that added.
In the following screenshot, we can see the result; two new CNAME record created.
Verifying the information about the DKIM CNAME record
After we complete the step of creating the required “DKIM records”, it’s important that we will verify that the required CNAME record was successfully created + published.
We can use a couple of methods for getting information about the CNAME record.
In the next example, we will use a useful website named- mxtoolbox, that includes a collection of web-based tools.
We will use the mxtoolbox for getting information about the DKIM CNAME record that we have created in the former step.
In our specific scenario, the DKIM Selector host name whom we use for publishing our DKIM infrastructure is – selector1._domainkey.o365pilot.com
We will add this hostname (selector1._domainkey.o365pilot.com) in the Box named: Domain name and click on the CNAME lookup
In the following screenshot, we can see the result.
The mxtoolbox CNAME lookup tool accesses public DNS server and retrieves the required information.
In our specific example, we can see that the host name – selector1._domainkey.o365pilot.com is “mapped” (redirected) to the host name:
Step 3#4 | Activating (enabling) the Outbound DKIM signing for our domain name
In this phase, we assume that the required DNS records were already created.
To activate (enabling) the option of outbound DKIM signing for our domain name, all we need to do is – to select the required domain name and choose the Enable menu
In the following screenshot, we can see that the outbound DKIM signing is Enabled
How to verify that the “special Office 365 TXT DKIM selector hosts record” was created?
In this phase, we have already activated the option of outbound DKIM signing and Theoretically, Office 365 should have created two special TXT records that will contain the value of
the DKIM Selector Public Key.
My personal preference is to verify that this TXT record was successfully created and published.
To be able to verify the information about the special TXT records that will contain the value of the DKIM Selector Public Key, we can use the nslookup command line tool.
In the following screenshot, we can see an example of the nslookup syntax the we use for getting information about the content of a specific TXT record.
In our scenario, I query the DNS about the TXT record that has the hostname:
Step 4#4 | verging the process of Outbound DKIM signing
In this section, we want to verify that the Office 365 DKIM infrastructure is “working properly and that E-mail messages that sent by our organization users will be digitally signed by
using a DKIM signature.
Testing and analyzing DKIM scenario in Office 365 | Outbound DKIM signing
In the following section, we will test the “outbound DKIM signing” that was configured for our domain – o365pilot.com
To be able to verify the DKIM flow, we will use a scenario with the following characters:
Our organization mail infrastructure (Exchange Online), was configured to implement outbound DKIM signing for the public domain name – o365pilot.com
We have a business partnership with an organization named – thankyouforsharing.org
The mail infrastructure of thankyouforsharing.org support only “inbound DKIM” meaning, the mail server that represents thankyouforsharing.org knows how to verify E-mail message that includes DKIM signature, but is not configured to support outbound DKIM signing.
We would like to verify if an email message that is sent from our domain includes the required DKIM signature and if the DKIM signature is successfully verified by the mail server that represents the thankyouforsharing.org recipients.
In addition, we would also like to check the “opposite flow direction”, in which our mail server (Exchange Online) gets an E-mail message that includes DKIM signature from an external sender.
In this case, we would like to test the ability of our mail server to implement the incoming DKIM verification test.
To be able to analyze the “DKIM flow”, we will simulate a scenario in which our organization recipient sends an E-mail message to thankyouforsharing.org recipient and vice versa.
We will “fetch” the E-mail message header content and analyze this content using the ExRCA message analyzer.
To be able to verify that the outbound DKIM signing was configured correctly and implemented correctly, we will use the following two scenarios:
Scenario A – testing the outbound DKIM signing for an o365pilot.com recipient
In this scenario, the sender is Suzan, an organization’s user who uses the E-mail address – Suzan@o365pilot.com.
Suzan wants to send E-mail message to the external recipient named Justin, that uses the E-mail address – Justin@thankyouforsharing.org
When looking at the E-mail message header content, of the mail that Justin got, we can see the following information:
In the section named – Authentication-result section (A), we can see that the DKIM test result is – dkim=pass (signature was verified).
The meaning is that the mail server (receiving mail server) that represents the destination recipient (Justin), implemented the DKIM verification process for “our mail” (“Our mail” is the E-mail message that was sent by Suzan).
The receiving mail server mail server verifies the DKIM signature and approves that the DKIM signature is valid.
In other words – that he can “trust” Suzan as a valid sender.
When looking at the section named – DKIM-Signature (B), we can see information about the host name of the DKIM Selector that “signed” the E-mail message.
In our specific scenario, the HOST name of the “our DKIM Selector” is:
If we want to be more precise, the receiving mail server will “translate” this hostname to
the “full hostname” – selector1._domainkey.o365pilot.com
Scenario B – testing incoming DKIM signing
Testing the specific scenario, consider as optional because our main goal was to verify the process of outbound DKIM signing that needs to be implemented by our Exchange Online mail server.
Just to be on the safe side, we would like also to test what happened when the external sender sends an E-mail message that includes DKIM signature to one of our organization recipients.
In other words, we would like to verify that our Exchange Online server “know” how to implement an “inbound DKIM check.”
In this scenario, Justin an external sender sends an E-mail message to one of our organization recipient named – Suzan.
The mail infrastructure of Justin (the mail server that hosts the domain thankyouforsharing.org) is configured to support DKIM only for inbound E-mail.
When looking at the E-mail message header content of the mail that Suzan got, we can see the following information:
In the section named – Authentication-result section (A), we can see that the DKIM test result is – dkim=none (message not signed).
The meaning is that the mail server that represents the sender, the recipient (Justin), doesn’t support outbound DKIM signing.
It is important for us to know your opinion on this article