Outbound DKIM signing and DNS infrastructure | Building the required DNS records for Office 365 | Part 4#10
In a scenario in which we want to use outbound DKIM signing for our public…
|01||DKIM – Domain Keys Identified Mail | Basic introduction | Part 1#10|
|02||DKIM as standard that based upon the Public key infrastructure | Part 2#10|
|03||DKIM flow in Office 365 | Part 3#10|
|04||Outbound DKIM signing and DNS infrastructure | Building the required DNS records for Office 365 | Part 4#10|
|05||How to enable outbound DKIM signing for your domain in Office 365 – Introduction | Part 5#10|
|06||Calculating manually the value of the Office 365 DKIM selector host name | Part 6#10|
|07||Get the value of the DKIM record for a Domain, using PowerShell | Office 365 | Part 7#10|
|08||How to create the CNAME records for Outbound DKIM signing using GoDaddy DNS | Office 365 | Part 8#10|
|09||Verifying that the DKIM CNAME records configured properly | Office 365 | Part 9#10|
|10||Enabling Outbound DKIM signing + Verifying the process of Outbound DKIM signing in the Office 365 environment | Part 10#10|
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.
When we use the Office 365 portal admin for enabling outbound DKIM signing for our domain name, the following steps will be implemented:
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.
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:
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
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:
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.
The task of enabling outbound DKIM signing for a public domain name in Office 365 based environment include a couple of tasks.
|Step 1#5||preparing the required DNS infrastructure for outbound DKIM|
DKIM is based on a concept in which mail server that gets E-mail signed with DKIM signature, will need to query DNS, regarding the “DKIM selector” that signed the E-mail.
Regarding the subject of – implementing outbound DKIM in Office 365, and the required DNS records, the subject is a little tricky because of a couple of reasons:
1. The use of CNAME records instead standard single TXT record.
In the Office 365 environment, we need to create a CNAME record that includes two host names versus a that “standard” single DKIM TXT record implementation.
The reason for using a “CNAME record” is, because in a scenario in which we implement outbound DKIN signing in o3655, the DKIM selector name who appears in the E-mail header, is just a “logic” hostname (dummy host name).
In other words, the “DKIM selector host name” who appears as the “entity” that adds the DKIM signature doesn’t exist.
DNS queries for the DKIM selector host name who appears in the E-mail header will be redirected to the “real” TXT record that represents the “real” Office 365 DKIM selector.
2. The requirement for using two CNAME records
In the Office 365 environment, we need to create two CNAME records, that will implement the “redirection” process to the Office 365 DKIM selector host name TXT record.
I believe that the reason for the “two CNAME records” is, for load balancing and prevent a scenario
of – a single point of failure.
3. The “process” of getting the information about the host names for the DKIM CNAME records.
At the current time, the task of getting the required host names who will be used for creating the DKIM CNAME records is not so simple.
To get the required host names who will construct the CNAME DKIM records, the options that are available for us are:
Option 1 – Calculating the host name based on the “onMicrosoft” domain prefix.
In the “old days,” this was the only available option.
If you are still interested in “understanding” the logic of the “Office 365 DKIM CNAME” record and how to calculate “manually” this value, you can read the article- Calculating manually the value of the Office 365 DKIM selector hostname | Part 6#10
Option 2 – using the PowerShell command Get-DkimSigningConfig
To get the required value of the Office 365 DKIM record hostname, we can use the PowerShell command – Get-DkimSigningConfig.
An example of the syntax that we use is:
Get-DkimSigningConfig <domain name> | FL *CNAME
To get more details about the way we use the PowerShell command Get-DkimSigningConfig, read the following article –Get the value of the DKIM record for a Domain, using PowerShell | Office 365 | Part 7#10
To simplify the process of “fetching” the required information about the “Office 365 DKIM host name records”, I have written menu based PowerShell script.
In the article – Get the value of the DKIM record for a Domain, using PowerShell | Office 365 | Part 7#10, you can find more details about how to activate the PowerShell script, and how to “read” the information about the “Office 365 DKIM CNAME” records.
|Step 2#5||Creating the required two CNAME required for Outbound DKIM signing using GoDaddy DNS|
In this step, we will need to create two dedicated CNAME records, that will use for publishing information about our domain name DKIM infrastructure.
In the article – Creating the required two CNAME required for Outbound DKIM signing using GoDaddy DNS | Part 8#10, I provide a step by step demonstration to the process of creating the required “DKIM CNAME” records, by using the GoDaddy DNS admin management interface.
|Step 3#5||Verifying the information on the DKIM CNAME record|
Tetchily speaking, this step is not a “mandatory step.”
However, my recommendation is to implement this step, in which we verify that the “Office 365 DKIM CNAME” records were published and created using the “right syntax.
In the article – Verifying that the DKIM CNAME records configured properly | Office 365 | Part 9#10, we review how to verify that the “Office 365 DKIM CNAME” record syntax is “proper”, and that the DKIM CNAME record implements successfully the “redirection mechanism” that direct DKIM DNS queries to the TXT records of the “Office 365 DKIM selector.”
|Step 4#5||Verifying the information on the DKIM CNAME record|
Given that we have published the required “Office 365 DKIM CNAME” records, all we need is just to “activate” the DKIM signing for our public domain name.
We review this “activation” in the following article – Enabling Outbound DKIM signing + Verifying the process of Outbound DKIM signing in the Office 365 environment | Part 10#10
|Step 5#5||Verifying the process of Outbound DKIM signing|
Although we are not “obligated” to perform these steps, it’s very important that we will check the “outbound DKIM signing” process that should be implemented by the Office 365 DKIM selector, and verify that this outbound DKIM signature process is implemented successfully.
We review how to verify the scenario of sends E-mail that includes outbound DKIM signature in the article – Enabling Outbound DKIM signing + Verifying the process of Outbound DKIM signing in the Office 365 environment | Part 10#10