Encryption involves prorotol (TLS version), initial key exchange method, cipher suite for use after key exchange, and MAC algorithm to verify packet integrity.  Outbound, SM also requires a verifiable certificate.  So the problem can be a mismatch on those other options.  Sorry, but for inbound traffic, I am at a loss how to detect what setting created the problem.

We still receive TLS 1 traffic from important sources, so we allow weak TLS inbound, and we have not locked down those other settings aggressively.  Admittedly, that leaves all senders more vulnerable to a man in the middle attack., but what else to do?   In theory, a sender could detect and correct for encryption setup failures by switching to plaintext, but I have no confidence that senders will do so. More likely, they will just keep trying and repeating the failure. Hence, I take what they offer.

Outbound, we use a gateway that enforces TLS and valid certificates, but can redirect to secure web relay for destinations that do not meet our requirements.

In late 2022 on a server with normal volume of 3 million messages per month, we removed support for SSL 3.0 and TLS 1.0/1.1.  We then started seeing occasional instances of the "secure connection failed" event logged, and dug into who and what was at the other side.  In 100% of the cases it was junk senders-- spam sources, hacked, etc.  We found no instances of legitimate senders generating this error.  

We allowed 1.0/1.1 thinking any TLS was better than none, but then decided it was time to stop perpetually supporting the dinosaurs.  If a sending server couldn't speak TLS 1.2 which was released in 2008, that was probably the least of its security problems.
 

@jay, well said, and thank you for this input.