According to the logs, the SMTP client is apparently not communicating with any Office365 server. This is strange, because it did actually attempt to connect to 'smtp.office365.com', which was correctly resolved to 220.127.116.11 and 18.104.22.168 (both are actually Office365 servers).
However, the actual communication shows otherwise:
Response: 220 mail.software-concept.de ESMTP ready.
Response: 250-mail.software-concept.de Hello nb-fardy**** [192.168.51.39]
TLS: Verifying server certificate ('CN=*.software-concept.de').
These log entries prove beyond reasonable doubt that the application was not communicating with Office365 servers. What remains is to determine the reason.
a) One possibility is that your application uses a custom transport layer that routes connections to different IP addresses than those specified in Connect method call.
b) A more likely possibility is that your customer have configured their router or firewall so that it intercepts some or all SMTP connections, and silently passes them to a different IP address. To determine whether this is the case, ask the customer to try running "telnet 22.214.171.124 587" or "telnet outlook.office365.com 587" from Windows command line (at the same machine). The responses are supposed to look like "220 AM0PR10CA0009.outlook.office365.com Microsoft ESMTP MAIL Service ready at Fri, 4 Sep 2020 13:58:58 +0000".
As a side note, it looks like your application (or your customer) disabled some essential parts of certificate validation (such as the host name check). This is dangerous and strongly discouraged.
Smtp class connects to outlook.office365.com, but the server responds with a mail.software-concept.de certificate, it should have failed (and it would have failed with default settings). Please be advised that disabling parts of certificate validation makes your application vulnerable to trivial man-in-the-middle attacks, making TLS essentially useless.