DKIM - old txt rather than CNAME
Hey,
Got an issue here at the moment with our DKIM, which seems to be refering to an old Google Workspace DKIM that was deleted from our CloudFlare DNS record.
However when I do a NSlookup it appears to be using the old public key rather than microsoft Cname key?
Selector2:
C:\Users\XXX>nslookup -q=txt selector2._domainkey.mantrasystems.com
Server: xxxx
Address: xxxx
Non-authoritative answer:
selector2._domainkey.mantrasystems.com canonical name = selector2-mantrasystems-com._domainkey.mantrasystems.onmicrosoft.com
selector2-mantrasystems-com._domainkey.mantrasystems.onmicrosoft.com text =
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwOGhW5w3vTC3j59hP9DeFARJRvcnzftb2bn/KNdwaUesVYIalDQXKrgi6BZZps6C/mX5Brc18JSPKuUvhuK4T//pZKX/OimvEuxHTtyTs2ij7b4CAZBvn4t8Ts+OLf2Fwx0UMd/Cm8slYHnwxnFWT9DKnXTjeLKRqHu3zxEuyE5kelzfx/kZJH/cLgFl0y48"
"qozfoscVwz0qsAQzfovh/wgmeKG9090EMBrgUT6+FJ1XAcg+8nzVbBc7RnFpk0jYK/W7InBXzmLzfQiCzT9jauWsiO1wuRhStHS9bZC1BcqhQ+6JrWcydUvRfoClblNNSWD2Nc/3TsAM1izuXx9lQIDAQAB;"
24 Replies
This happens on mantrasystems.com and mantrasystems.co.uk it looks to be looking at an old DKIM rather than the new CNAME.
I have no idea how to resolve this however our outbound email address seem to be failing dkim as this key is not the correct one.
That DKIM record has nothing to do with Google, and is actually coming from Microsoft Office 365.
"
selector2._domainkey.mantrasystems.com
" as you can see under "Non-authoritative answer
", is a canonical name (CNAME
) to "selector2-mantrasystems-com._domainkey.mantrasystems.onmicrosoft.com
".
That output you're demonstrating is actually following your CNAME
record, and getting the actual (final) TXT
response from the record on "selector2-mantrasystems-com._domainkey.mantrasystems.onmicrosoft.com
".
(And same applies to the .co.uk
, both for selector1
and selector2
).See I was under this impression however,
This public key was orginally set in Google "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwOGhW5w3vTC3j59hP9DeFARJRvcnzftb2bn/KNdwaUesVYIalDQXKrgi6BZZps6C/mX5Brc18JSPKuUvhuK4T//pZKX/OimvEuxHTtyTs2ij7b4CAZBvn4t8Ts+OLf2Fwx0UMd/Cm8slYHnwxnFWT9DKnXTjeLKRqHu3zxEuyE5kelzfx/kZJH/cLgFl0y48"
Now I don't understand why this is showing up? I'm assuming this is the reason our dkim is failing here? As this doesn't exist?
I appreicate that, but I'm just going off what I've been told by Microsoft
We have checked the last message header sample you gave and saw the error: DKIM=fail (body hash did not verify)", it means that the DomainKeys Identified Mail (DKIM) signature verification failed because the hash value of the email's body did not match the value stored in the DKIM signature. As previously mentioned, this would be the expected result as the DKIM records being detected and published is still the records that were from Google. The old cache records will need to be cleared out and this would be on your host provider. Unfortunately, Microsoft cannot clear these old records as we only provide the DNS records to be published.
I've sent a reply over to them, stating this. However I'm under the impression they'll send it back to me.
Thank you for your answer :). Microsoft are trying to blame this on CloudFlare, however I don't see it within Cloudflare, hence the question to you lot 🙂
The phrase you did mention from them, Microsoft seem to refer to "cache records", ...
?dns-cache
DNS cache
Resolving DNS entries is complex and involves many parties (your browser, your operating system, your router and then your ISP's resolver).
Any and all of these intermediaries can potentially cache your DNS request and serve stale content, even though you just updated it.
Quick fixes:
1. Use a different browser
2. Restart your PC
3. Change your DNS from your ISP's to Cloudflare's: https://one.one.one.one/dns/#setup-instructions
COULD maybe be related as well, if they checked the records just before they were added, then the fact that they didn't exist when they originally checked it, could be cached for a little while.
Both actual existing DNS records, as well as non-existing DNS records will be cached.
In that case, there's no other ways than to wait a while, and try again.
I think this issue has been an issue since we moved from Google Workspace to Microsoft and I've not noticed.
We removed the public key which came from Google Workspace over 5 months ago, so I'm not sure as to why this is caching. But we'll see what Microsoft say to the response.
Thank you again for assisting me
It won't be the Google record that is interfering in any way, when we're talking that long time...
Also, normally, Google is using "
google
" as it's default selector, compared to Microsoft which takes "selector1
" and "selector2
", so unless you can demonstrate otherwise, I wouldn't suspect they are related at all.
Anyway, there are various online checkers you can check by sending a message to, to see what they actually see.
That may be worth a try...
Sending a message to the Port25 (now Postmark) tool, - [email protected]
.
Sending a message to the https://mail-tester.com/ tool, - using the generated address on their website.
Just to mention two examples.Sorry,
I'm talking about the Public Key
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqwOGhW5w3vTC3j59hP9DeFARJRvcnzftb2bn/KNdwaUesVYIalDQXKrgi6BZZps6C/mX5Brc18JSPKuUvhuK4T//pZKX/OimvEuxHTtyTs2ij7b4CAZBvn4t8Ts+OLf2Fwx0UMd/Cm8slYHnwxnFWT9DKnXTjeLKRqHu3zxEuyE5kelzfx/kZJH/cLgFl0y48"
This key is Google Workspace rather than Microsoft
The selector1 etc is Microsoft.
No, that key is NOT Google Workspace, as we've told you several times now.
Oh okay, I was under the impression that this is Google Workspace as I found this key within an old TXT record that was removed a while ago.
This key was the same as the public key but I have generated a new record last week to see if I can clear it some how

It was the same key which is why it making me believe its was from google.
How exactly are you getting those two to be the same?
1. What about "
p=MIIBIj
" (Microsoft) versus "p=MIGfMA
" (Google)?I've regenerated it hence why it isn't the same now. But it was the extact same
2. What about "
goggle._domainkey
" versus "selector._domainkey
"?
It is NOT going to be the exact same from two different email providers..
You're going to have to look a little better at it, comparing from character to character...Okay I appericate that 🙂 thank you, I've replied to Microsoft I'll see what they said however the last time I spoke to them, They stated that they only provide the CNAME and then this is hosted within a DNS provider (CloudFlare) in mycase.
The
CNAME
is added on your DNS provider, yes.
But a CNAME
tells the requestor to make another query, towards the target of that CNAME
record.Thank you this is information that I didn't really know. DNS is not my strong point :D.
I'll pass this information over to Microsoft and ask them to investigate it on their side.
DNS over Discord: TXT records
selector2._domainkey.mantrasystems.com TXT @1.1.1.1 +noall +answer
diggy diggy hole
From the above, what you literally see is:
1. Can I have the
TXT
for selector2._domainkey.mantrasystems.com
?
2. (Cloudflare) Please ask selector2-mantrasystems-com._domainkey.mantrasystems.onmicrosoft.com
instead!
3. Can I have the TXT
for selector2-mantrasystems-com._domainkey.mantrasystems.onmicrosoft.com
?
4. (Microsoft) The TXT
for selector2-mantrasystems-com._domainkey.mantrasystems.onmicrosoft.com
is "v=DKIM1; k=rsa; p=MIIBIj...
"
With the "v=DKIM1; k=rsa; p=MIIBIj...
" being supplied to you directly by Microsoft's DNS.We don't have TXT records we only use CNAMEs.
should this be a TXT rather than a CNAME?

CNAME
records are simply aliases, that say "Go to this other location, to try to get the information you want
".
Keep them as they are right now.
And keep disturbing Microsoft Support, if you continue to see issues.Thank you matey 🙂