Today, SMTP can be trivially MITM'd by anyone on a network, not just state actors, even if TLS is supported. All you have to do is remove "STARTTLS" from the servers EHLO response and then everything is in the clear.

Forcing a MITM to compromise DNSSEC before they can read the cleartext is a worthwhile barrier to add IMO.

Thanks for that. Do you have an understanding of what would happen if SMTP servers switched to demanding TLS (i.e. bouncing the message if next hop doesn't offer STARTTLS?) with validated certs?

It would hurt mail reachability, but are there any useful numbers as to how badly?

Additionally, it seems as though a solution analogous to HSTS might be better than involving DNSSEC. An SMTP server could advertise that it should be connected to only over TLS - information that could be cached by the sending system.

There is still a MITM problem on 1st connection, but that's an issue for many systems and avoids trusting DNSSEC.

I'm not sure what proportion of servers use TLS. I imagine a lot of mail would go missing if you started to require it though. IIRC, Google started publishing numbers somewhere.

The good thing about involving DNSSEC+DANE is that, even the first time an SMTP server connects to another, it knows that it must use TLS and must expect a particular certificate. With HSTS you don't get that protection on the first connection.

I guess I would prefer that SMTP "skip over" the CA/DNSSEC model and go straight to something like HSTS+TACK to add the expectation of validity to the expected certs, rather than place trust in the DNSSEC roots.

I guess DANE (with or without DNSSEC) could also be used to cover the first connection, but I guess I'd prefer a world where the previous connection was used as the primary point of trust (the HSTS+TACK approach) rather than the "trusted root" (DNSSEC or CA).