First is certificate management. There is currently no automated way for mail providers to obtain TLS certificates for domains whose MX records point to them - i.e. there is no SMTP/MX equivalent to the Baseline Requirement's "Agreed-Upon Change to Website" domain validation method, or ACME's HTTP-01 challenge type. And in general domain operators don't want their mail providers to have certificates which could be used to impersonate their websites.
The certificate problem could be solved with SRVName certificates, which permit certificates to be scoped to a particular service on a host. Combined with an automated SMTP/MX-based validation method, this would permit mail providers to easily and securely get certificates for the domains whose mail they host. But there are thorny security-critical compatibility problems which are blocking the deployment of SRVName certificates. I wrote about the problem near the end of this blog post: https://www.agwa.name/blog/post/avoiding_dnssec
Second is that you need a mechanism for servers to remember that they should use TLS with a particular recipient domain, similar to HSTS. This could probably be accomplished with a simple SMTP extension that's included in the EHLO response.
> The certificate problem could be solved with SRVName certificates, which permit certificates to be scoped to a particular service on a host.
What about extended key usage extension, doesn't it function similarly without needing to fiddle with SANs? https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1....
Are there any situations today where that happens?
edit: I actually read the spec, and apparently the listing of allowed servers is a side aspect of the spec, the main meat is opting in to tls overall; that was not immediately obvious from the article. In that context your question makes more sense. To answer more comprehensively, I don't see why similar mechanism that functions well with HTTP would not work here; that the server would send STS policy to the client after connection which the client then caches and consults on subsequent connections. This is how HSTS works.