No, it's a very bad idea.
In fact, as it turns out, most STARTTLS servers/clients do not implement any sort of a retry algorithm without StartTLS should a TLS connection fail to negotiate.
As such, even advertising STARTTLS as an option already reduces your chances of getting (and sending) emails!
Just search, and you'll find many people not being able to send ANY email to Microsoft Outlook domains handled by *.protection.outlook.com cluster:
Sendmail messages rejected from Microsoft when using TLS
reason: 403 4.7.0 TLS handshake failed
To summarise issues presented in the above two posts:
- can send any mail to any host other than those handled by Outlook, with or without STARTTLS,
- can send mail without a client certificate and without STARTTLS to Outlook,
- or with a zero-length client certificate,
- but not with a certificate that Microsoft doesn't like, and upon failure, the clients (well, servers acting in client mode) don't attempt to re-send the message without STARTTLS if the recipient's server does advertise STARTTLS!
Likewise, when your host acts as a server, a similar situation may occur outside of your control if you decide to enable STARTTLS — when a client server sees that your server in server mode offer STARTTLS, they try to negotiate TLS, but if negotiation fails, they simply wait, and retry the same steps again, keep on failing until the message has to be bounced back to sender!
And this does happen pretty frequently with various domains in the STARTTLS land!
Sadly, as much as I used to be a STARTTLS supporter in the past, I'm now very disenfranchised that I was misled by the risk-free advertisement of what I thought was supposed to be opportunistic encryption.
Not only should you not require STARTTLS, but it may even be prudent to completely disable it, if you want to ensure the interoperability.