Microsoft missing public DNS TXT entry for DKIM records (msn.com)

Mailman List Mirror (Read Only)
1

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

2

"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.

Patrick

3

..

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

4

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

5

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

6

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