DKIM selector1 record missing at 365

Brass Contributor

Anyone else seeing DNS failures resolving the selector1 TXT record supplied by EXO for each domain?  selector2 is fine. I'm seeing that across my fleet of customer tenants.

 

 

 

@@PS C:\Users\AlanMcFarlane\Documents\Temp> Resolve-DnsName -Type cname -Name selector1._domainkey.XXundeesen.org | fl

Name     : selector1._domainkey.XXundeesen.org
Type     : CNAME
TTL      : 14371
Section  : Answer
NameHost : selector1-XXundeesen-org._domainkey.Xsen.onmicrosoft.com


@@PS C:\Users\AlanMcFarlane\Documents\Temp> Resolve-DnsName -Type TXT -Name selector1-XXundeesen-org._domainkey.Xsen.onmicrosoft.com
Resolve-DnsName : selector1-XXundeesen-org._domainkey.Xsen.onmicrosoft.com : DNS name does not exist
At line:1 char:1
+ Resolve-DnsName -Type TXT -Name selector1-XXndeesen-org._domainkey.DS ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (selector1-dunde...onmicrosoft.com:String) [Resolve-DnsName], Win32
   Exception
    + FullyQualifiedErrorId : DNS_ERROR_RCODE_NAME_ERROR,Microsoft.DnsClient.Commands.ResolveDnsName


@@PS C:\Users\AlanMcFarlane\Documents\Temp> Resolve-DnsName -Type TXT -Name selector2-XXndeesen-org._domainkey.XSEN.onmicrosoft.com |Fl

Name    : selector2-XXndeesen-org._domainkey.XSEN.onmicrosoft.com
Type    : TXT
TTL     : 3594
Strings : {v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDWc7LSbVYlbIU5iacAKqoglZISad9rZBna+O8rc9j5iOMyzvgGuoEtFx8MXyuq2nVQXkVWgjPxbOB4Ov3FYaFDPTJtP4Gc9PcAc+ncu0UTfGgsVlcAU5ahISHr+0xKLJ7EzNtTxvjTeeQV5CtndtAMSfFCMixHzfIn0sRgv1tnlQIDAQAB;}

 

 

 

Domain names slightly modified for privacy!

20 Replies

@Alanjmcf 

 

use Set-DkimSigningConfig with -PublishTxtRecords

@Pierfish 

I didn't mention that I've changed nothing and this has suddenly affected twenty tenants in the last week (or thereabouts).

 

That seems set already as I'd expect. (Doesn't appear in Get-'s output.)

@@PS C:\Users\AlanMcFarlane\Documents\Temp> set-DkimSigningConfig -Identity XXndeesen.org -PublishTxtRecords
WARNING: The command completed successfully but no settings of 'XXndeesen.org' have been modified.

 

I'm seeing the same behavior, and yeah haven't changed a thing here either. Best open a support case, I will ping few folks just as well.

 

For the record, I fixed it by running:

 

Rotate-DkimSigningConfig -Identity domain.com

@VasilMichev 

 

but you have changed the certificate with this. that's why you have a new record published.

I’ve sent a grand total of two emails from two tenants and both were sent with selector2. So after that huge test…hopefully the lack of selector1 isn’t breaking email delivery.

Maybe all tenants did a key rotation to selector2 and something stopped them creating selector1.

My experiences with support recently have been somewhat lacking (they don’t escalate clear issues etc) so reporting it here was my alternative. :-,)
From a quick check (from my iPhone) looks like the records are back — well for that one domain at least.

Just a wee blip I guess. But I also wonder why key rotation apparently happened for all domains at the same time. Maybe to do with https://www.microsoft.com/en-us/microsoft-365/roadmap?featureid=56752
I checked an hour or three ago and it is NOT fixed. The selector1 record is still missing except for those domains where I did the PowerShell command suggested by @Pierfish That brings the record back to life — even though that option is already set to true.

@Alanjmcf 

Exact same issue here. Microsoft hosed my selector1 but selector2 was fine. I was also able to fix it with Set-DkimSingingConfig -Identity <mydomain.com> -PublishTxtRecords

 

I then ran the Dmarcian DKIm inspector on selector1 and it's working again. I was getting a "missing data" error before I fixed it.

 

Thanks to this thread!

Looks as if both records are back for all my tenants.

Same problem, selector1 is no more existing at the DNS of onmicrosoft.com.
So I've made a switch over. I think something has gone wrong on the DNS of onmicrosoft.com
I hope that DMARC shows now aligned DKIM
I've created also a support case

From O365 support I got the following reaction:

As discussed over the call, only 1 selector will be visible globally since one selector works at a time to digitally sign the email. It is the new update from Microsoft that the selector which is active to encrypt the header of the email will be visible globally as public key of that selector only will be available globally on DNS.

But the rotation was not ready after 12 hours, so DKIM was not ok.
So I had followed the option to reinsert the TXT key's with
 
Set-DkimSigningConfig -PublishTxtRecords -Identity %domainname%
 
And both the selector key's are in the DNS.

Additional to work is that you do a rotate. 
I've seen that making first a rotate, the key's where faster available than without a rotate

Rotate-DkimSigningConfig -Identity %domainname%

I’m guessing this is normal intentional behaviour now ie: after a key rotation (and after sufficient time for emails using the old key to be delivered), they remove the old key, and don’t bring a new key back to that selector until the next key rotation.

 

I can’t see any issues that creates for email delivery — a bit annoying for diagnostics tools though!

@Alanjmcf The strange is that from halve the domains the seclector1 was not available in de DNS from Microsoft office 365. But there was no switchover for this domains inplace.
Only when you make a switch over and reinserting the DKIM key's into de DNS from Microsoft Office 365 it works again, and DMARC gives a valid DKIM signature when sending e-mail.
More domains, not only the one of us, has this problem I think there has been an incident.
When dkimconfig of office 365 says, use Selector1 and the key is not available, then I think there was an issue on microsoft side.
But our dkim issue has been solved after switching command and reinserting the key's into the Office 365 DNS.
I don't know that for every one is this the solution.

To know in the future that the dkim records are away, I have scheduled a powershell script that check every day the presents off this records. Because no good working dkim can impact the delivery of mails

 

@Pascal Wenders 

Could you please share the PowerShell scripts to check every day the presents off this records. I am having same issue.

@VasilMichev have noticed the same thing with our tenant.  Lots of our domains Selector1 stopped resovling, but selector2 works.  Seems to be a big problem on the Microsoft side.  I have a support case, and if I can get past Tier 2 and talk to somebody who actually understands the problem, hopefully Microsoft will fix it because I don't want to script having to do this for the high number of domains I have.

Any updates on this issue?  I've had this same issue for several months now.  I haven't tried rotating yet.

@Omayaki  It is straight true, for us it works.

$mailfrom = "#####@####.###"
$mailto = "#####@####.###"
$subject = "DKIM text record check for domain "
$body = "Selector"
$body2 = "is empty"
$domain = ""
$extdomain = ""
$microsoft365 = ""
$space = " "
$dot = "."


$domain = "<domainname without extension, example microsoft"
$extdomain = "com"
$microsoft365 = "<domainname>.onmicrosoft.com"

 

$selector_nr = 1
$nslookup = nslookup -type=txt selector$selector_nr-$domain-$extdomain._domainkey.$microsoft365
$subjectmail = "$subject $domain.$extdomain"
$bodymail = "$body$selector_nr $body2
Please perform the procedure to correctly set the selector records for this domain"
If ($nslookup.count -lt 4) { Send-MailMessage -From $mailfrom -to $mailto -SmtpServer <mailserver> -Body $bodymail -Subject $subjectmail }

 

$selector_nr = 2
$nslookup = nslookup -type=txt selector$selector_nr-$domain-$extdomain._domainkey.$microsoft365
$subjectmail = "$subject $domain.$extdomain"
$bodymail = "$body$selector_nr $body2
Please perform the procedure to correctly set the selector records for this domain"
If ($nslookup.count -lt 4) { Send-MailMessage -From $mailfrom -to $mailto -SmtpServer <mailserver> -Body $bodymail -Subject $subjectmail }