@CliffsEsport

FreeBSD required PGP-signed emails for things like having the mail admin team do things. They checked the PGP key against the key in the handbook. I ended up with this flow every time I wanted to send them an email:

1. Generate a new key pair.
2. Commit the new public to the handbook.
3. Use the private key to sign the message.
4. Send the message.
5. Discard the key pair.

The security of the PGP keys was therefore bounded by the security of my SSH key. At which point, we can remove email entirely from the attack surface and I can just give them access to a file on a shared server. I don't think they still use it (or, at least, don't require it).

One of the free TLS certificate providers used to offer S/MIME certificates and that worked a bit better. Most mail clients support S/MIME. It would be nice if Let's Encrypt with DNS authentication would sign S/MIME certificates (or, ideally, sign certs that allowed signing S/MIME certs in a specific domain, though I'm not sure that's a thing the certificates can encode). Even then, there's a problem of what do you do in the case of failure? I had some people who used S/MIME with a cert that they wanted you to install separately outside of the PKI, but if you didn't then all emails from them just showed up as failed authentication. What do you do? It turns out: just trust them.

Certificate revocation and rollover is also a while problem with S/MIME, you really need to do the checks as the email arrives because there's no guarantee that the certificate will still be valid when you get around to reading the message (or, especially, if you reread it a year later).