We have a two-prong approach. Outbound, we require TLS1.2. If a servers cannot negotiate TLS, the message is blocked until we configure a rule to redirect that traffic to our secure-web-relay service.
Inbound, we accept anything, because security is the sender's choice. If servers cannot negotiate TLS 1.2, they could theoretically fall back to no encryption, which seems worse, but the norm seems to be that the sender just gives up and the message is lost.
In reviewing my data, I see a lot of blocked traffic that uses weak or no encryption. From a dataset that is limited to allowed traffic, I have two server organizations using TLS 1.1, and 121 server organizations using no encryption. The two TLS1.1 organizations are definitely-wanted message sources. The unencrypted list includes some sources that are surprising, because I would expect them to have higher standards. Some of the unencrypted sources are worthy of an audit because they may indicate unwanted messages leaking though my filters.
There are some theoretical ways that a middleman could force a connection to weak TLS, capture the encrypted traffic, and then crack the session offline. This is really a sender problem. If they are worried about it, they should refuse to send using the weaker TLS.
There is a specification, I think called HSTS, where a sender can say that receivers should only accept TLS1.2 connections. It is not something that I have attempted to implement, so I don't know how many senders have implemented it.