The one-word answer is "federation."<p>What makes email (by which, here and below, I mean SMTP) universal is what makes it hard to retrofit (with new protocols or standards): it's federated, relying only on DNS for namespacing (i.e., for discovering the authoritative owner for a given user identifier), and it's widely implemented.<p>Skipping over the "secure-at-rest" statement for a moment, the difference between HTTPS and email is that HTTPS has <i>user-facing</i> security: the choice to use encryption is user-facing (if the user manually typed "HTTPS"), the actual use of encryption is user-visible (in the URL bar), and what to do if authentication fails can be decided by the user (with an error message and a possible user override).<p>Email does not have this, which results in a few distinct problems:<p>1. Users do not, typically, know if they are going to be using secure transport, so there's no market incentive at work here (to use a provider who offers, say, STARTTLS or DANE). Hypothetically, a provider could offer users the ability to require STARTTLS on a sent message (see <a href="https://datatracker.ietf.org/doc/draft-fenton-smtp-require-tls" rel="nofollow">https://datatracker.ietf.org/doc/draft-fenton-smtp-require-t...</a> and associated discussions in the working group for arguments against this approach) or could try to expose DANE or MTA-STS (<a href="https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/" rel="nofollow">https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/</a>) status at message compose-time, but since delivery time and compose time are different, and delivery happens asynchronously in the background (from the user's perspective), it's hard to really make this a UI feature.<p>2. Absent something like "require-tls", MTAs can't always determine encryption support for a given recipient. Because recipient MX resolution ultimately has to support unencrypted DNS, senders <i>always</i> have to support falling back to unauthenticated MX records and, consequently, unauthenticated delivery. One of the few (or, as tptacek says, only) useful applications of DNSSEC is solving this problem: by allowing authenticated discovery of <i>DNSSEC</i> <i>support</i> from the root server on down, DNSSEC allows senders to see if a recipient domain <i>should</i> support DNSSEC, <i>does</i> support DNSSEC, and, via DNSSEC, what the authenticated MX (and, optionally,TLSA) records are for that domain and the MX. But DNSSEC has a host of its own problems, is not widely deployed, and would not fix #1 above, so senders still wouldn't know <i>if</i> their message would be encrypted in transit!<p>3. PGP and S/MIME are the standards for end-to-end encryption and can be layered on top without support from the MTA or host, but both suck for a variety of reasons: they're often hard to use, they break webmail (which is by far the most common usage), they often break multi-device or multi-client usage (e.g. webmail and smartphone), they don't provide modern cryptographic features (like PFS), they often have no good/secure means of automated key discovery (unless you want to meet a bunch of beardy men at a party), etc.<p>If all of that is too longwinded, I think the simple explanation is federation, without a resource locator that indicates preference for or support of secure delivery, resulting in a protocol that is hard to retrofit against downgrade attacks.