Microsoft missing public DNS TXT entry for DKIM records (msn.com)
Apologies if this message is the wrong listserv to ask this question but we are scratching are heads here. We run our own exim mail server and are receiving reports of end users getting bounce back messages when they send email from msn.com to our mail server. Our mail server checks if DKIM email headers are present and if they are, tries to validate them. If the check fails, we reject the message. We are noticing that Microsoft, specifically, msn.com, does *not* publish DKIM DNS text records but sends email with the DKIM email headers. Is this normal or correct? Anyone have information or a contact at Microsoft that can fix this -- publish their DKIM records? It seems to me that if msn.com is going to include DKIM headers in their outgoing email, they should also publish their DKIM public key. If they are not going to publish their DKIM public key, then they should not include DKIM headers in their outgoing email. Other Microsoft email accounts and services such as hotmail.com and outlook.com publish their DKIM records. Again, it seems msn.com should as well. If we look at a bounce back messages we see the following snippet: Generating server: PH7PR84MB1704.NAMPRD84.PROD.OUTLOOK.COM ... Remote server returned '550 5.0.350 Remote server returned an error -> 550 DKIM: encountered the following problem validating msn.com:;pubkey_unavailable' Original message headers: ... DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=msn.com; s=selector1; ... When we try and perform a TXT DNS query to fetch the DKIM record: selector1._domainkey.msn.com we see that Microsoft does *not* publish their DKIM records: adam@defiant ~ $ dig selector1._domainkey.msn.com TXT ; <<>> DiG 9.18.25 <<>> selector1._domainkey.msn.com TXT ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13050 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;selector1._domainkey.msn.com. IN TXT ;; ANSWER SECTION: selector1._domainkey.msn.com. 21170 IN CNAME www-msn-com.a-0003.a-msedge.net. www-msn-com.a-0003.a-msedge.net. 240 IN CNAME a-0003.a-msedge.net. ;; AUTHORITY SECTION: a-msedge.net. 184 IN SOA ns1.a-msedge.net. msnhst.microsoft.com. 2016092901 1800 900 2419200 240 ;; Query time: 20 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) ;; WHEN: Wed Apr 03 23:04:31 PDT 2024 ;; MSG SIZE rcvd: 173 Again, this problem does *not* exist when we perform the same query to hotmail.com and outlook.com as those domains publish their DKIM TXT records: selector1._domainkey.outlook.com and selector1._domainkey.hotmail.com -- Adam Brenner https://aeb.io/
"if msn.com is going to include DKIM headers in their outgoing email, they should also publish their DKIM public key." Yes, and mailop seems a place to post this. https://www.mailop.org/ Patrick
On Thu, Apr 4, 2024 at 1:23 AM Adam Brenner via NANOG <nanog@nanog.org> wrote: ..
It seems to me that if msn.com is going to include DKIM headers in their outgoing email, they should also publish their DKIM public key. If they are not going to publish their DKIM public key, then they should not include DKIM headers in their outgoing email.
Microsoft can still sign the message, Even if the signature cannot be verified because they have not yet published the Public Key, for whatever reason. That is a partial/incomplete implementation of DKIM then. The Interpretation of the results by Recipients should be the same as if that Message had not been signed at all. And that domain has not published the policy record to indicate messages must be signed. RFC6376 6.3 Interpretation of Results [ Page 50 ] If the email cannot be verified, then it SHOULD be treated the same as all unverified email, regardless of whether or not it looks like it was signed. See Section 8.15 for additional discussion.
Other Microsoft email accounts and services such as hotmail.com and outlook.com publish their DKIM records. Again, it seems msn.com should as well.
-J
On 4/4/24 12:43 AM, Jay Acuna wrote:
On Thu, Apr 4, 2024 at 1:23 AM Adam Brenner via NANOG <nanog@nanog.org> wrote: ..
It seems to me that if msn.com is going to include DKIM headers in their outgoing email, they should also publish their DKIM public key. If they are not going to publish their DKIM public key, then they should not include DKIM headers in their outgoing email. Microsoft can still sign the message, Even if the signature cannot be verified because they have not yet published the Public Key, for whatever reason. That is a partial/incomplete implementation of DKIM then.
There is one potential reason a site might want to do this which is to essentially invalidate signatures from a non-repudiation standpoint. Simply unpublishing the key while not 100% foolproof is essentially saying "we don't take responsibility for mail signed with this key anymore" -- sort of like the expirey tag in the header but with attitude. The entire kerfuffle about Her Emails (ie Hillary's email server) was in part about the fact that the mail on it could still be verified and thus not denied. After, there were calls for providers to publish their private keys on a regular basis but that went nowhere that I've heard of. That's probably not what's going on here -- maybe they just botched a key rollover -- but it still amusing to me that we got non-repudiation along for the ride [*]. Mike [*] while DKIM only speaks at the domain level and not an individual account, if providers always require submission auth before signing that seems pretty airtight to me
It appears that Michael Thomas <mike@mtcc.com> said:
verified and thus not denied. After, there were calls for providers to publish their private keys on a regular basis but that went nowhere that I've heard of.
$ host -t txt k2402._domainkey.gurus.org k2402._domainkey.gurus.org descriptive text "v=DKIM1; h=sha256; p=MIIBIj... ; n=Signing=20key=20at=20https://www.iecc.com/dkimkeys/k2402 ;" That's probably not what's going on here -- maybe they
just botched a key rollover -- but it still amusing to me that we got non-repudiation along for the ride [*].
Well, they could have gotten equally good non-repudiation by not signing at all. R's, John
It appears that Adam Brenner via NANOG <adam@aeb.io> said:
mail server. Our mail server checks if DKIM email headers are present and if they are, tries to validate them. If the check fails, we reject the message.
MSN's setup is broken but let me strongly reiterate the advice DON'T DO THAT. If a DKIM signature isn't valid, you ignore it. If you do anything else, as you have just discovered, you will be sorry. R's, John
participants (5)
-
Adam Brenner -
Jay Acuna -
John Levine -
Michael Thomas -
nanog＠planhack.com