The current state of encrypted email — the good, the bad, and the unpleasant
Most enterprise email providers encrypt customer data at rest and in transit. Gmail does it by default. The Secure/Multipurpose Internet Mail Extensions (S/MIME) is a protocol that enables sending digitally signed and encrypted messages. It is typically used for highly-sensitive emails among regulated organizations, such as government agencies and businesses that work with them.
While more organizations have real needs for E2EE emails, few have the resources to implement S/MIME. IT teams need to acquire and manage certificates and deploy them to each user, resulting in additional efforts and costs. And end users have to figure out whether they and the recipient have S/MIME configured (few do), and then go through the hassle of exchanging certificates before the encrypted emails can be exchanged. This often results in frustration and the inability to send encrypted emails.
Alternatives to S/MIME, such as encryption features from email providers or proprietary point solutions, present significant drawbacks as well: the former requires sharing encryption keys, increasing data privacy and sovereignty risks, while the latter complicates end user experiences with custom applications, portals, or browser extensions. We think there should be a simpler and more efficient way.
Sending end-to-end encrypted emails to any inbox with Gmail
The idea here is simple. Email messages are encrypted with just a few clicks in Gmail regardless of who they are being sent to — no need for end users to exchange certificates or use custom software. The emails are protected using encryption keys controlled by the customer and not available to Google servers, providing enhanced data privacy and security. And the IT team no longer needs to go through the complex S/MIME setup or certificate management. This is how it works behind the scenes: