Give me a bit to parse our incoming postfix gateway logs and the TLS versions and Ill let ya know what we see.

We disabled too and within 24 hours started getting tickets about missing emails.

Thank you echoDreamz

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.

Wow echoDreamz, I honestly expected much lower 1.0 and 1.1. Thank you!

I predict a worldwide email interruption in the next few months.

The trouble lies that SmarterMail server can't "bounce" the message. TLS is at the OS level. So the sender's mail server has to figure it out.

Then the sender is like "this company sucks, they can't even receive an email"

No need to panic.  "Disabled by default"  means that admins can turn it back on if desired.  For most purposes, off is appropriate. 

We have allot of customers on older versions of Outlook that use TLS 1.0 and 1.1. Also, ASP.NET 4 websites that send emails that use TLS will use TLS 1.1.

Douglas HSTS is a header for websites and tells the web browser to only accept HTTPS connections for the domain. As far as I am aware I don't think you can use it on mail servers, except for the webmail service.

Out of interest Gmail.com still support TLS 1,0 and 1.1 while hotmail.com does not.

As TLS 1.0 and 1.1 will only disabled by default, it should mean you can use IISCrypto (https://www.nartac.com/Products/IISCrypto) to re-enable TLS 1.0 and 1.1 on the server if you need to use it.

Yep, older versions of Outlook sucks on the security front. Keep in mind that TLS 1.0 has been already deprecated if you are working inside any kind of security business framework and TLS 1.1 is on the way out and for some already is DONE!

I do believe that thru the Registry you can change the behavior of the .NET Frameworks. I'll provide more details about that...

The NIST (US National Institute Standards and Technology) via 800-52 Revision 2.0 (see https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf), published August 2019, already states that "servers should not be configured to use TLS 1.1 and shall not use TLS 1.0, SSL 3.0, or SSL 2.0.".

In addition, "[US Federal Government] Agencies shall support TLS 1.3 by January 1, 2024. After this date, servers shall support TLS 1.3 for both government-only and citizen or business-facing applications. In general, servers that support TLS 1.3 should be configured to use TLS 1.2 as well. However, TLS 1.2 may be disabled on servers that support TLS 1.3 if it has been determined that TLS 1.2 is not needed for interoperability.".

Also, note that you can only acquire TLS 1.3 natively in SChannel on Windows Server 2022 or later. Microsoft has chosen to not backport this to Windows Server 2019 BTW.

The next B.I.G. is also Cipher Suites; it is not enough to manipulate the various Encryption options like SSL and TLS, but you also need to manage your cipher suites as a lot of them are broken. I'm not sure how this is done for SMTP, POP and IMAP, however, for IIS that is all set up in Windows Registry. Here is the bit in 800-52 about that; "requires that TLS 1.2 be configured with cipher suites using NIST approved schemes and algorithms as the minimum appropriate secure transport protocol...".

A great place to test your IIS is via www.SslLabs.com by Qualys, Inc. The web site will test every SSL and TLS variation plus all of the security holes and Ciphers. Even, the SmarterTools.com Web site has weak ciphers enabled and thus only get a "B" Score Qualys. You can find Qualys recommended best practices here "https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices".