There are a multitude of online tools that help diagnose issues with various mail services, but understanding what these tools actually check is valuable. One example is around manually checking published DomainKeys Identified Mail (DKIM) records. DKIM is described in RFC 4871. As an interesting piece of history DKIM went through a previous iteration "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)" which was RFC 4870.
Quick DKIM Overview
Please read the RFC or a related post for all of the background details on how DKIM operations. For the purposes of this post we will assume some existing understanding of how selectors work with the given domain and associated asymmetric cryptography. A brief discussion on selectors is included below.
A domain can have one or more DKIM selectors. Office 365 will create two selectors and they are always call Selector1 and Selector2. Different solutions will use other naming conventions. If we know that a domain is enabled for DKIM with Office 365 then we know the names of the two possible selectors. In normal operations only one is used for signing until there is a need to rotate. So if Selector1 does not work, simply try Selector2 for Office 365 signing.
However for those other services, we need to know the name of the selector(s), and to retrieve the name look at the properties of an email signed by that domain. The selector is visible in the message headers.
DKIM relies on asymmetric cryptography, where the private key is stored on the signing infrastructure. The corresponding public key is published to the public DNS zone in a TXT record.
Many infrastructure providers automate the key management, publishing the public key to a zone that they control. To ease administrative overhead, the customer admin creates a CNAME record in their external DNS zone that references the public key TXT record in the vendor's zone. This level of abstraction means that once the customer admin has created the required CNAME records they typically do not have to make any further changes. This is very different that the customer admin obtaining the public key and publishing the key material directly to a TXT record in their zone. Every time the keys need to be rotated, the customer admin would have to repeat the process. SendGrid calls this feature Automated Security.
As we saw in the DMARC post, subdomains are used to store these records. For DKIM this is the ._DomainKey domain. Note the period (full stop in UK English). The full format would be:
SelectorNameGoesHere._DomainKey.Domain.com
Interactive Nslookup Example
In this example, we will look at the wingtiptoys.ca domain which leverages DKIM signing in Office 365.
Optionally the DNS server could be set using the server command.
server 8.8.8.8
Office 365 leverages CNAMEs to provide the level of abstraction noted above, or set it and forget it (should you want to call it that). That means we can review the initial CNAME records, then change gears to obtain the underlying TXT records.
First up, let's obtain the Selector1 and Selector2 CNAME records for the wingtiptoys.ca domain.
set q=cname
Selector1._domainkey.wingtiptoys.ca
Selector2._domainkey.wingtiptoys.ca
canonical name = selector1-wingtiptoys-ca._domainkey.wingtiptoyscanada.onmicrosoft.com
canonical name = selector2-wingtiptoys-ca._domainkey.wingtiptoyscanada.onmicrosoft.com
To retrieve the value contained behind the CNAME, need to change the query type to TXT as this is what the DKIM payload is actually stored in. If you do not do that, all you will get is the information about the CNAME record.
set q=txt
selector1-wingtiptoys-ca._domainkey.wingtiptoyscanada.onmicrosoft.com
selector2-wingtiptoys-ca._domainkey.wingtiptoyscanada.onmicrosoft.com
Failing to Change to TXT
Note that we need to ensure that the query retrieves the correct type of DNS record at the right time.
In the example below, once we have retrieved the CNAME record and can see where it points the type of record retrieved is not changed.
Checking for a CNAME record in the wingtiptoyscanada.onmicrosoft.com domain will fail to produce the expected result.
The command should have been changed so that we are retrieving a TXT record.
Cheers,
Rhoderick
