Microsoft's e-mailservers break DKIM on non-ascii characters

There seems to be some kind of character encoding issue in DKIM signatures applied by Office365 servers. We just had a DKIM fail ('body hash did not verify') and tracked it down to non-ascii quotes being in the body. When we replaced them with ascii-quotes, the DKIM was valid again.

This is our chain:

appserver -> on-premise smtp -> Office365 (which signs the message with DKIM)

I can reproduce it with this bash script:

#!/bin/bash

# A test script for triggering the character encoding DKIM bug.

{ 
  echo "HELO origindomain.nl"; 
  sleep 0.5
  echo "MAIL FROM: wiebetest@ourdomain.com" 
  sleep 0.5
  echo "RCPT TO: wiebe@someotherdomain.nl"
  sleep 0.5
  echo "DATA"
  sleep 0.5
  echo "Subject: $RANDOM Conversation buster: My DKIM test"
  sleep 0.5
  echo "From: wiebetest@ourdomain.com"
  echo "TO: receiver@ourdomain.com"
  sleep 0.5
  echo "Hello receiver,"
  echo ""
  echo "Non-ascii char: “"
  sleep 0.5
  echo ""
  echo "."
  sleep 0.5
} | telnet smtp.onpremise.local 25

When I remove that non-ascii char, the dkim is valid:

Authentication-Results: mx.google.com; dkim=pass arc=pass; header.s=selector2

But when I have the non-ascii there:

Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify); arc=fail (body hash mismatch); header.s=selector2

The first Outlook server in the received chain is:

Received: from smtp.onpremise.local (1.2.3.4) (Wiebe: redacted) by HE1EUR01FT055.mail.protection.outlook.com (10.152.1.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3455.23 via Frontend Transport; Tue, 13 Oct 2020 10:47:51 +0000

When people send me non-ascii chars just with Outlook clients it works fine, so it appears to happen when the body does not specify a character encoding.