Email does use TLS for encryption to the server but once it hits the server (usually owned by a mega corp like google) it gets decrypted so they can read it.

Email encryption is different because HTTPS certifies that you are connected to the owner of that domain name. How do I certify to you that the email you just received came from me and not someone pretending to be me?

The only bullet proof secure way is if I visit you in person and hand you a copy of my public key and then you use that key to verify my emails. We have had tools to do this with email for over a decade but they are so inconvenient that no one uses it outside of a few privacy nuts.

Thanks for the namecalling.

I use PGP quite often. And I know how hard it is and how much it lacks.

But I'm no 'privacy nut'.

A legitimate easy and underused option is how kraken employs it. I've uploaded my public key. They now send all transactional, security and other mail signed and encrypted. This is a solid solution to phishing.

The only part 'missing' is how I get my pub key on my kraken account. For me it was an export+copy+paste. But it should probably as easy as an OAUTH alike flow between kraken and my mailprovider. 'Kraken wants to import your public key to sign and encrypt it's emails to you'. An UI thing.

When you access any website using HTTPS the parties involved are You and the Webserver, and the data is encrypted in transit over the open internet. When you request a page, the webserver needs to know what page you request in plain text, so it makes sense for the webserver to have access to the request. With email, the parties who want to communicate are (e.g.) You and Me, and the parties involved are (You, Your company email server) and (Your company's email relay server, My company's spam-filter and DR email clone server), (that and My company's email server) and (My company's email server, Me).

There isn't anything quite like the Browser - Webserver simple connection to encrypt. I would like my connection encrypted to my mailserver using SMTP/POP3/IMAP/HTTP + TLS, which it can be. I would like my email server to talk to your email server using TLS which it can do, but isn't guaranteed, there are several approaches to it (STARTTLS and others). I would like incoming mail to be spam-filtered which means a service that can read the content. My company would like incoming email to be malware and phishing filtered, which means accessing the content. My company would like outgoing email to be signatured and branded, same again. My company requires email to be archived for legal reasons and cloned off-site for DR reasons. The design of SMTP involves store-and-forward, failover and fallback options, multiple MX records, so there's not a trivial path email always takes from sender to recipient. Attackers will try to intercept SSL connections and force fallback to plain text SMTP and people would rather email arrives than doesn't arrive. Tons of companies are using ancient not-updated network equipment which proxies and edits SMTP traffic as it goes through. Coworkers would like Webmail which almost necessarily requires the server having access to unencrypted email to show it to you in a browser.

Trying to put some kind of "secure" on top of that pile of entrenched systems is much harder than saying "the biggest players don't want it", what would it be, which layers would it go in, which sides would manage it, how would it interact, who would standardise on it, how much bother is it for users and for people who forgot their password? The main approach is to public/private key outside email and send encrypted blobs to each other, which is full of key management problems, or a service which intercepts email and pulls the text out and sends on a HTTPS link and a blank "someone sent you an encrypted message. Sign up and login to view it" which sucks, but is a lot more practical and does actually work.