Table of Contents
Some Manual Intervention Might Still be Required
Message center notification MC291056 (updated October 19) covering a simplified configuration for Domain Keys Identified Mail (DKIM) in Microsoft 365 Defender for Office 365 was a good reminder to check that all the domain names registered for my tenant were in good health.
DKIM uses a private key to include an encrypted signature in a domain’s outbound email. The public key for the domain is published in its DNS records. Receiving domains use the public key to decode the signature in messages to confirm that email comes from the domain it appears to be from rather than a spoof attempt. You can choose to use either 1024-bit or 2048-bit DKIM keys.
Microsoft configures DKIM for the tenant service domain automatically (the onmicrosoft.com domain assigned to each tenant). If a tenant has one or more custom domains, as most Office 365 tenants do, administrators should configure DKIM for each domain used for email (accepted domains).
All outbound email sent from Exchange Online is signed with DKIM. Exchange Online uses the service domain name if DKIM is not configured for a custom domain (like Office365itpros.com). It’s better for email authentication if the domain used for DKIM matches the domain sending email. Hence the logic behind the need to check that all your custom domains are configured.
Check Your Domains
The first place to check is the Domains section of Settings in the Microsoft 365 admin center. I look there to make sure that Microsoft 365 considers each of the registered domains to be healthy. This has nothing to do with DKIM because Microsoft 365 doesn’t take DKIM into account when it checks a domain. However, it’s good to make sure that Microsoft 365 doesn’t consider any of the domains to have problems with their basic set of DNS records. Interestingly, I noted that the details available for a domain now include the set of Groups and Teams which use the domain for their primary SMTP address (Figure 1).
Although this information is easy to find elsewhere, it’s good to have it here in case you want to remove a domain and need to reassign SMTP addresses to keep email flowing. In passing, the Apps section lists Azure AD registered apps which use the domain as a required URL.
A New DKIM Page
MC291056 notes the introduction of a new DKIM configuration page in the Microsoft 365 Security Center. The page lists the accepted domains for the tenant and allows administrators to select individual domains to enable or disable DKIM (Figure 2).
Everything was in order except for the tonyredmond.email domain. The domain works for email, but DKIM wasn’t enabled because the CNAME records for the domain weren’t published in DNS. This status is also viewable in PowerShell by running the Get-DkimSigningConfig cmdlet to check the domains:
Get-DkimSigningConfig | ? {$_.Enabled -ne $True } | Format-Table Domain, Enabled, Status, LastChecked
Domain Enabled Status LastChecked
------ ------- ------ ------------
tonyredmond.email False CnameMissing 20/01/2016 18:58:29
Microsoft’s documentation explains what needs to be done. Because GoDaddy is the domain manager, I had to create the CNAME records in DNS for the DKIM signatures for the domain. You can get the values for the CNAME records using the Get-DkimSigningConfig cmdlet:
Get-DkimSigningConfig -Identity tonyredmond.email | Select -ExpandProperty Selector1CNAME selector1-tonyredmond-email._domainkey.xxxxxx.onmicrosoft.com Get-DkimSigningConfig -Identity tonyredmond.email | Select -ExpandProperty Selector2CNAME Selector2-tonyredmond-email._domainkey.xxxxxx.onmicrosoft.com
A quick visit to GoDaddy’s Domain Manager and the two records were inserted (Figure 3).
After adding the records to DNS, it will take a little time to propagate the new data to Microsoft 365. An hour is usually enough. After Microsoft 365 knows about the CNAME records for DKIM for the domain, you can enable DKIM by moving Sign messages for this domain with DKIM signatures from Disabled to Enabled (Figure 4).
Of course, you can enable the domain using PowerShell.
Set-DkimSigningConfig -Identity tonyredmond.email -Enabled $True
Key Rotation
When a domain is enabled for DKIM, you can also configure it for key rotation. The documentation for the Rotate-DkimSigningConfig cmdlet says that you don’t need to do this because Microsoft 365 rotates private and public keys automatically to reduce the chance of an attacker compromising the keys used to sign messages. This assertion might cover the service domain, but I don’t see any problem in going ahead and rotating DKIM keys for all custom domains used to send email. Happy signing!
Learn about protecting Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant.
On what MS considers to be a problem or not on the DNS records page, I noticed that even though we (like everyone else) are off Skype for Business Online now, that page flags you if you don’t still have all four of those records. Only one of them, as far as I’ve determined, has relevance for Teams (to allow connection with Skype consumer): _sipfederationtls._tcp.
Also, it’s worth noting that at some point in the last year or two, 2048-bit DKIM became available. There’s a way to check what you have and upgrade, if needed. Anyone who enabled DKIM more than a few years ago will be at 1024, but there’s a way to check.
https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/use-dkim-to-validate-outbound-email?view=o365-worldwide#steps-to-manually-upgrade-your-1024-bit-keys-to-2048-bit-dkim-encryption-keys