Is there no alternatives to DNSSEC that would have allowed the equivalent of DANE to be provided somehow?
Using TLS provided by the mail server may have been possible, similar to how the HSTS header is sent over the HTTPS connection. But unfortunately the MTA-STS policy if for the receiving domain (@example.com) and the receiving mail server may be run on a completely different domain. We need a signal that cryptographicly relates to the receiving domain.
Or are you saying you're not doing STARTLS at all and servers delivering mail to you have to do an SSL handshake before getting to speak SMTP to you? I'm quite surprised if that's compatible with the wider SMTP world.
We could have added a field so that when a server announces that they support STARTTLS, they can say that this fact should be cached for X days.
250-AUTH LOGIN PLAIN
250-STARTTLS
250-STARTTLS-CACHE-90-DAYS
One challenge for your suggestion is that the mail server is often run by a different organization, on a different domain from the receiving address. The HTTPS web server, on the other hand, has a TLS certificate for the mta-sts subdomain of the receiving address. This gives confidence that the MTA-STS policy is set by the receiving domain, not the receiving mail server.
I also asked why this is better than just standardizing on a port and using SMTP over TLS with existing certificate infrastructure, but they did not answer that question.
To enable MTA-STS for inbound email: Add DNS entries for the MTA-STS record and mta-sts.<domain>. Run a web server that serves the mta-sts.txt file (or use static hosting, like GitHub pages/Netlify/AWS S3/etc). Set up HTTPS on the web server. The repo in the post shows an NGINX approach with Let's Encrypt.
To enable MTA-STS for outbound email: you'll need to configure https://github.com/Snawoot/postfix-mta-sts-resolver. Be sure to read through the DANE related challenges in the README as there are some tradeoffs.