Calculating manually the value of the Office 365 DKIM selector host name | Part 6#10

In the current article, we review the “formula” that we can use for calculating the value of the two Office 365 DKIM selector TXT record host names who contain the Public Key that the Office 365 DKIM selector use for signing outbound mail.

In the past, to the only way for getting the host name of the Office 365 DKIM selector, was by using the “manual method,” in which we need to “collocate” the DKIM TXT record host name, by using a formula that “construct” the Host name based on “different components” such as – the onMicrosoft domain name, the Office 365 tenant name whom we register and so on.

Later, Office 365 added a new a PowerShell cmdlet named Get-DkimSigningConfig, that was created to simplify this process by, provides us the ability to “display” the Office 365 DKIM selector TXT record host names who were generated for a specific Public domain name.

It’s up to you to choose the “method” (calculate the value vs. using PowerShell command) that you prefer.

The article Get the value of the DKIM record for a Domain, using PowerShell | Office 365 | Part 7#10 include a description of how to use PowerShell for generating the Office 365 DKIM selectors host names.

DKIM in Office 365 | using CNAME records that include two host names.

The foundation for the implementation of outbound DKIM signing for a specific domain name in Office 365 environment, is based on the mandatory need to publish two CNAME records that will include information about “our” DKIM infrastructure.

Each CNAME record consisting of two host names.

When a DNS client asks for information about the host name – A, the CNAME record, will redirect the request to Host name – B.

In our scenario, “Host A” is a logical name of a DKIM selector.
We use the term “logical” because, in reality, this DKIM selector host name does not exist.

This “logical” DKIM selector host name,” is added to the outgoing E-mail message, in the process of outgoing DKIM signature.

When the “receiving mail server,” asks the DNS server about “Host – A (the logical name of the DKIM selector),” the DNS CNAME record, will redirect the request to “Host B.”

In our scenario, “Host -B,” is the host name of the “real” Office 365 DKIM selector TXT record, that contains the Public key which was used for signing the outgoing E-mail.

The DKIM CNAME record stature

The structure of the Office 365 DKIM CNAME record is implemented in the following way:

1. The logical DKIM host name (the first part).

The “first part” of the DKIM CNAME record, meaning, the “logical DKIM Selector” host name, is a “fixed value.”

In Office 365, the name of the “logical” DKIM host name is implemented by using the following naming convention:

Selector1._domain key<Public domain name>
Selector2._domain key<Public domain name>

For example, in our example, we want to implement the option of outbound DKIM signing for the domain name – o365pilot.com

2. The “real” host name of the Office 365 DKIM selector (the second part).

When we enable the option of DKIM outbound signing, Office 365 generates a dedicated TXT record that contains the public-key value of the Office 365 DKIM selector.

The “host name” of this DKIM TXT record, will be created based on a “formula,” that generate the host name based on the Office 365 tenant and domain names.

In the next section, we will learn how to use this formula for calculating the host name of the Office 365 TXT record that “represent” a specific domain name.

Calculating the Office 365 DKIM TXT record host name

In this section, we review the “formula” that we use for the Office 365 DKIM selector TXT record.

The structure of the “Office 365 DKIM selector TXT record” that is generating for a specific public domain name, is based on the following two “parts”: Domain GUID and onMicrosoft domain name.

In case that the thought – “what WT.. Are these terms?”
Do not worry; we will explain them in the next section

In the following diagram, we can see the structure of the “Office 365 DKIM selector TXT record”.

We can see that the DNS record consisting of four parts:

In the following diagram, we can see an example of “Office 365 DKIM hostname.”

Part 1 – this is the “reserved host name.”
In Office 365, we will need to define two DKIM records using the following host names: – selector1 and selector2

Part 2 – the second part defines as DomainGUID.
The DomainGUID name is the left part of the Office 365 MX record that represents our registered public domain name.

In the following diagram, we can see an example for MX record that is used in Office 365 for the public domain o365pilot.com

The “left part” of the host name is the Domain GUID

Part 3 – the DKIM sub domain name

The part of the DKIM subdomain is a “predefined value” that is written using the following naming convention – ._domainkey

The special “dash character that we use for defining the Office 365 hostnames

Notice that the DKIM subdomain vale includes a special dash character that is a mandatory part of the DKIM subdomain value.

Part 4 – the Office 365 tenant name

This is the part that is “taken” from the Office 365 tenant name.

For example – o365info2.onmicrosoft.com

In the following diagram, we can see an example of the Office 365 DKIM selector TXT record host name structure.

Part 1#2 | How to get the information about our domain GUID in Office 365?

As mentioned, the Domain GUID is the “left part” of the Exchange Online MX record.

To be able to get information about the Office 365 MX records that represent a particular public domain name, we a use a couple of options:

Option 1 – using the Office 365 portal

When we log in to the Office 365 portal, on the left-side menu bar, we can choose the domain menu and then select a specific domain name such as o365pilot.com in our scenario.
To be able to view information about the DNS records that “belong” to the specific domain, we will choose the menu domain settings

In the following screenshot, we can see information about the Office 365 MX records of the
domain name – o365pilot.com

The DomainGUID name appears as the left part of the Office 365 MX record.

Option 2 – using the nslookup tool

Another way that we can use for display information about the MX record of specific Office 365 domains is by using the nslookup command line tool.

We can use the following parameters to query the DNS server regarding the domain name.

Nslookup

Set q=mx

<Domain name>

Part 3 – the third part is the DKIM sub-domain (reserved names). As mentioned, this name is the “reserved sub-domain name” (._domainkey).

Part 4 – the fourth part is the “onMicrosoft domain” name.
This is the domain name that automatically generated for our Office 365 tenant in the first time that we create our Office 365 tenant.

Part 2#2 | How to get the name of the OnMicrosoft domain name?

To be able to get the name of our “onMicrosoft domain” name we can be login to the Office 365 portal.
In the following screenshot, we can see an example to Office 365 tenant that include three registered domain names.

Two of the domain names considers as a “public domain” (other terms, a vanity domain or a custom domain) name and one domain is the onMicrosoft Domain name (number 2).

The next article in the current article series

Get the value of the DKIM record for a Domain, using PowerShell | Office 365 | Part 7#10