It's not hard to imagine a system where you can contact the server in the MX record for a domain over HTTPS (really just TLS) and query it for a specific email address to get the public key for that user.

Sure if someone knocks over TLS then your email encryption will be in trouble, but you will also have plenty of other problems at that point.

> query it for a specific email address to get the public key for that

This is actually possible for OpenPGP, with WKD ("Web Key Directory"): https://datatracker.ietf.org/doc/html/draft-koch-openpgp-web...

It's an expired draft, but is relatively widely supported: https://wiki.gnupg.org/WKD#Implementations

In a draft published in May of this year. This should have been a draft in the 90s.

It should have been in mail systems forever. Whenever you create an account the first email should have been the server sending you your private key in some format that every email client understands and would then prompt you to automatically install it in your client for that server.

    Welcome to your new email account!  
    
    Your private key is attached in the standard format.  

    When your client asks you to install the key say "Yes", and allow it to automatically sign your email using that key for this account.

    Don't forget to check the box to automatically encrypt mail when possible.

If email worked like this I bet secure POP and IMAP would have been implemented much faster than they were in real life.

The first draft was published in 2016: https://datatracker.ietf.org/doc/html/draft-koch-openpgp-web...

Even before that, there were other mechanisms proposed for this, such as https://datatracker.ietf.org/doc/html/draft-shaw-openpgp-hkp... (from 2003). Unfortunately it didn't catch on; I agree it would've been nice to have such a mechanism earlier.

What if your mail server decides to advertise their public key instead of your public key, allowing them to read all of your email with you being none the wiser?

One way to solve this problem is Key Transparency, which aims to provides a mechanism to verify that you're receiving a legitimate key, somewhat analogous to Certificate Transparency.

We've implemented this at Proton: https://proton.me/support/key-transparency (although it's still in beta, and opt-in for now - but obviously the aim is to enable it by default).

There's also a (relatively new) working group at the IETF, to work on standardizing (a version of) this: https://datatracker.ietf.org/wg/keytrans/about/.

Then you might want to change email providers.

Really paranoid folks could set up services online that check for this, but I kind of doubt it would happen very often because it would be a major stink for that email service if they were caught, and catching them isn't that hard.

Did you just invent keyservers??? WOW!!!! I wonder if next you will invent the ftp protocol or some other thing that has existed for decades.

Discoverable keyservers are novel I think.

The problem with existing keyservers is that there are several of them and you never know which one someone's public key might be living in. There may even be multiple potential keys for a single email address across the different servers. They are effectively useless for email encryption in their current form. It's a very rare email client that will even query the most popular ones looking for someone's key. In fact I don't know of a single email client that does.

Openpgp keys in DNS, 2016: https://www.rfc-editor.org/info/rfc7929

Certificates in DNS, 2006: https://www.rfc-editor.org/info/rfc4398

Why not use the SRV record which has been created for this purpose, advertising seervices, specifically and use port 11371/tcp which has been registered with IANA for OpenPGP HTTP Keyserver? Why create new non standard mechanisms when these already exist? One could even use a different port and protocol with SRV records.