DKIM verification broken on Outlook 365/Exchange because of tampered HTML

[monperrus]

Hi Outlook365/Exchange team,

I'm doing end-to-end DKIM verification on my outlook.com inbox.
I notice that all HTML messages are DKIM invalid.
The reason is that the outlook MUA tampers with the HTML, breaking the DKIM cryptographic signature.
Reference: https://github.com/lieser/dkim_verifier/issues/300#issuecomment-1824874545

How to fix this such that we can do proper end-to-end DKIM integrity verification?

Thanks a lot!

--Martin

[#2]

I just sent myself an html email from Gmail to Outlook and I got a DKIM pass. Outlook mailbox is on Exchange Online with custom domain:

Authentication-Results: spf=pass (sender IP is 209.85.128.173)
 smtp.mailfrom=gmail.com; dkim=pass (signature was verified)
 header.d=gmail.com;dmarc=pass action=none header.from=gmail.com;compauth=pass
 reason=100

[#3]

@DomP66thanks for looking into this.

yes, the outlook server is able to verify the authenticity of the gmail message.

however, we, users are not able to verify the authenticity using tools such as https://github.com/lieser/dkim_verifier/

this is because the message has been tampered by outlook/exchange server, and we don't have access to the original message sent by gmail.

as a conclusion, we have no guarantee that the header is correct and that the message was actually sent and signed with the given dkim key.

[#4]

I see. Well if you don't trust Outlook enough to believe the Authentication-Results header, it's arguable whether you should be trusting Outlook at all with your emails!

[#5]

@DomP66 

Trust but verify.

Modifying email content undermines the whole integrity of DKIM.

Interestingly, outlook/exchange does not modify simple text/plain messages, only text/html ones.

[#6]

Outlook modifies all html prior to </head>, maybe as an anti-malware measure, maybe to format nicely on outlook.com. It's definitely deliberate though, and therefore unlikely to change.

[#7]

Note that there are two different issues with Outlook.
First the one already discussed here, Outlook modifying HTML mails.

Like you wrote reading the Authentication-Results header should be a possible workaround to use.
Unfortunately this is where the second Problem with Outlook comes in play:

The Authentication-Results header that Outlook is writing is not a valid one that follows the specification in the RFC.
One violation being that it is missing the in my opinion important part of the authserv-id.

See https://github.com/lieser/dkim_verifier/issues/300#issuecomment-1428735628 and https://answers.microsoft.com/en-us/outlook_com/forum/all/authentication-results-header-written-by-o... for details.

[#8]

It would definitely be nicer if Microsoft abided by the RFC, but if that's not going to be the case, you might have a decision to make for your extension: make the extension more useful to Outlook.com users, or doggedly stick to RFCs.

Not an easy decision to make, I accept that. Sticking to the RFC and encouraging people to use an alternative email provider would probably be my option.