When I use the DKIM inspector tool on my domains some are failing for some Office 365 selectors with “Missing DKIM records”. I get a similar problem with the mxToolbox DKIM test utility.
e.g. selector1 might fail, but selector2 would be fine.
This used to be fine with both selectors working. Nothing in the DNS has changed in a long time.
Is this expected behaviour from Microsoft? Is it actually a problem?
We noticed this symptom too, on several domains. We were going through the process recently to enable DKIM on our Outlook365 domains, and noticed many were fine, but about a third were missing selector2, and a handful were missing both selector2 and selector1.
So, using an example to illustrate, we have a CNAME in place for selector1._domainkey.ExampleDomain.tld & selector2._domainkey.ExampleDomain.tld, which point to selector1-ExampleDomain-tld._domainkey.ExampleDomain.onmicrosoft.com & selector1-ExampleDomain-tld._domainkey.ExampleDomain.onmicrosoft.com. (The exact selector record has to be pulled from your Microsoft365 Admin portal, but you get the idea.) Our CNAMEs were functioning and correct, but one or both of those OnMicrosoft.com records were missing.
We opened a case with Microsoft Unified Support for Exchange Online. They suggested:
Rotate is only available on the admin page when DKIM is enabled on your domain; it didn’t sound like there was a PowerShell command to do it (that they shared.)
We did not end up needing to change our CNAME, but the selectors changed. I used AppMailDev to test when done: DKIM Test - DKIM Verify - DKIM Validator
It looks like that did the trick for me.
One more note: if you don’t DKIM enable this with your domain, it does not mean Exchange Online isn’t DKIM signed. Microsoft will DKIM sign outbound email from Exchange Online, but they do it using their own onmicrosoft.com selector. When analyzing your domain through dmarcian, you will see “Microsoft Office 365” as “DKIM 0%”. This is true, since DKIM isn’t aligned with your domain, but with onmicrosoft.com. However, the emails will still be signed if you inspect the headers. So when verifying, pay special attention to the d= field in the DKIM-signature header.
Cheers, and I hope this helps.
Hi. Many thanks for that long response, over the week-end as well.
I’ve found these two posts which seem relevant:
It seems to be an issue across a significant number of tenants. Since DKIM tests themselves are working, just one of the two selectors failing, I’ll see if it resolves itself without rotating the selectors.
Best Regards
Jeremy
Hi guys,
I have the same issue. I have full admin on my tenant and my own domain but the person that is helping me either has no idea how DKIM works or how I can be provided with the 2nd selector’s private key.
Tried rotating the keys and it doesnt work. i have basically on my domain a DKIM score result of 0% at the moment
Are both selector1 and selector2 failing? If so, that’s probably a call to Microsoft if you’re sure the DNS records are correct. If one of them is working, I think that’s probably ok as the sending email includes the selector name used to sign the email.
Send a test email from your Office 365 mailbox to an external email address. Grab the headers. Go here:
https://testconnectivity.microsoft.com/ and select the Message [Header] Analyzer. Paste your headers in and run it.
Search for the DKIM-Signature in the output and you should see something like this:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=<>; s=selector2;
You won’t get a DKIM score unless you send email to a mail server that sends DMARC reports. Office 365 doesn’t. G-Mail does, so send a few test emails to a G-Mail account and wait a few days.
Hi Jeremy,
Selector 1 is fine Selector 2 i dont have the private key and talking to microsoft support engineer its like talking to a wall he keeps saying that the private key cannot be given to me. either they have a serious flaw in the system or this person doesnt know how it works.
Hi Jaquilina
Actually the engineer is correct.
Microsoft will hold a private key and a public key associated with each of the selectors. When Office 365 signs an outgoing message it will sign it with the private key associated with one of the selectors and include the selector name in the email (as my earlier post).
On receipt of a DKIM signed email the receiver will pull the public key from DNS based on the selector name in the email. Either the public key will be embedded in a DNS TXT record in your DNS, or, as is more usually the case, your DNS selector record has a CNAME which redirects the recipient query to a Microsoft (or other email sender) DNS server which itself returns the public key.
With the sender’s public key the recipient can then verify the message signature.
These are the principles of asymmetric cryptography. I hope this makes sense.
I would have thought, normally, that both selectors would function properly, however, technically, it is only necessary for one of them to function at any one time, as it is the sender which chooses which selector to use when the message is signed. Microsoft must be doing something internally (such as upgrading the servers) causing them to take one selector offline temporarily.
Best
Jeremy
Hey Jeremy,
I understand how it works but there has to be some way to get the private keys with out having to involve them.
If we have no way to get the key’s that we need to put in the DNS txt record then is one selector enough what is the point of having more than one?
This is the response i keep getting from their support
Good day,
Unfortunately we can’t provide or retrieve a private key selector 2 since this is kept from our data centers. I already asked assistance from our engineers about this issue.
Like i said before there is a serious flaw in their infrastructure if i cannot retrieve my own keys.
Hi jaquilina,
Microsoft occasionally rotates (changes) the keys, and you typically authorize O365 selectors via CNAME records, e.g.
selector1._domainkey.YOURDOMAIN.COM CNAME selector1-YOURDOMAIN-COM._domainkey.TENANT.onmicrosoft.com and
selector2._domainkey.YOURDOMAIN.COM CNAME selector2-YOURDOMAIN-COM._domainkey.TENANT.onmicrosoft.com
In this setup Microsoft holds the private keys, and publishes the public keys for you via the CNAMEs. You do not need the private key Microsoft uses to sign your mail.
If you need to send and DKIM signed mail without using O365’s services, you should use a separate selector and key pair for that.
I got this answer earlier today from Microsoft.
So it seems they are doing some restructuring in terms of DKIM.
MS is cutting down on the number of DKIM txt Records for every tenant. In theory selector 2 will be deprecated. Their DKIM should still work as normal, right now selector 2 is nothing but a placeholder waiting to be removed.
Only the TXT record for the active selector will be published at any given time. So This is by design and expected, as this is not the active selector and TXT entry may or may not exist.
From the customer perspective there is nothing really to say as this does not affect the DKIM functionality.
You must still add the two CNAME entries as if a rotation happens these must exist. Creating the second record is important to do but only one of the selectors may be available at the time of creation. In essence, the second selector may point to an address that has not been created yet. It is still recommended that the second CNAME record is created since it will come in handy when the keys rotate and, as an admin, there would be nothing to do and the rotation would be seamless.
My question is it safe to remove selector 2?
Do you mean Is it safe to remove the selector2 CNAME?
Key rotation is afaik done like this:
If the provider skips the period using selector2 and just changes or removes selector1 keys, then any messages still in transit will fail DKIM validation.
If selector2 is used without the proper CNAME record present, then selector2 DKIM signatures are not authorized, and vaildation will also fail.
So, I wouldn’t recommend removing any of the two DKIM CNAME records.
O365 has been using selector2 for our tenant for +6 months, and our selector1 CNAME currently points to a non-existing TXT record. Good to know that unused O365 selector DKIM records may not be present. I hadn’t thought of that.
do you have the private key to go along with it. My issue is Selector 2 is failing due to me not having the private key to go along with it.
We do not have access to the private keys used for O365’s DKIM message signing. Private keys are supposed to be kept strictly confidential, and should only be shared on a need-to-know basis, and we do not need to know.
Private signing keys should be known only (i.e. be private) to the system/org tasked with signing (in this case Microsoft/O365)- when keys are known by others, they can sign messages using that signature, and message authenticity becomes less certain.
Are you using selector2 to sign messages yourself?
Hi Niels,
Understood. Regarding selector 2 DKIM is completely failing for me.
From the exchange admin centre I rotated my keys again to see if it puts me back on Selector 1 and not 2. Hopefully this sorts my issue and hopefully helps others with this issue as
well.
Regards,
Jonathan
To give you an update I have rotated back from selector 2 to selector 1 and now I have 100% compliance. It seems like microsoft are phasing out selector 2 hence the 0% DKIM compliance showing up for me on the dashboard.
To add the microsoft support person advised the second selector can be deleted given that they will eventually be phasing it out completely from their side.
Hope this helps others in any way with their issues they are having.
