Technically, this is possible – but the results will be less than ideal. You can use Gmail’s “Send As” feature to send a secure email from Gmail that will appear in your recipient’s inbox to have come from your third-party provider address, but the secure policy is still owned by the Gmail address.

This leads to some undesirable behavior. If your recipient uses Virtru, their reply will be sent by their mail provider, which parses the “reply-to” address (the address you “sent as” – the third-party address), so their reply will be sent back to your third-party address, then be automatically forwarded to Gmail. When you attempt to open it in Gmail, you’ll be denied access, because this is not the intended recipient of that email.

However, if your recipient does not have Virtru installed and reads in our Secure Reader, their reply will be sent back to the address that owns the secure policy – the Gmail address – instead of being sent to the reply-to address. You will be able to read their reply in your Gmail inbox, but it will not be delivered at all to your third-party inbox.

The strength of an encryption tool depends on the length of the keys used to encrypt the data being shared. Encryption keys are measured commonly used computing units called bits. The more bits in a key, the more difficult it is to guess, and thus the safer the encrypted data is from hackers.

AES 256-bit encryption refers to the length of Virtru’s keys, which meets or exceeds most requirements.

Perfect Forward Secrecy (PFS) provides stronger security by ensuring that the session’s establishment keys are ephemeral. In other words, PFS ensures that an attacker cannot decrypt past messages if the user’s private key is lost.

Customers manage their own keys, which are stored in IBM facilities in Virginia and Oregon. Authentication services are run in AWS data centers in both East and West Coast of the US.

For customers who want to host encryption keys on on their own premises or in the cloud environment of their choice, contact about the Virtru Customer Key Server.

Client-side encryption protects a message the moment someone composes it, and it ensures that only the sender and recipient can decrypt the message to view the plain-text content.

Point-to-point encryption, or transport level security (TLS), provides an encrypted pipe through which messages can be transmitted. Unlike client-side encryption, TLS does not encrypt the actual message at rest. Instead, it ensures that unencrypted content is secure when travelling between mail servers. As a result, mail providers typically have access to the unencrypted messages that reach them throughout this process.

In order for TLS to work, both the sender and recipient’s email system must have TLS enabled. If the recipient’s server does not support TLS, the communication will not be allowed. This means the email will not reach its intended recipient.

Given these circumstances, and the fact that some on-premise email platforms do not support TLS, client-side encryption is the only way to ensure that content will be secure no matter where it travels.

Activation emails contain an authentication code that allows the key server to ensure only those users with authenticated access to the inbox may read the encrypted message. The activation emails do not contain encrypted content or encryption keys.