Automatic encryption for selected contacts


is there a way to automaticaly encrypt while sending only for specified e-mails? If not it would be great to have such option (like a enryption white list).

For now I see that the only options are to either
enable for all or
for none or
to indivualy select everytime when sending.

This makes it easy to forget encrypting and makes the use of e-mail encryption not very intuitive.

Thanks in advance

1 Like

eM Client will only encrypt to those recipients whose public keys you have.

So set eM Client to encrypt by default, and if you don’t want to encrypt to recipient A automatically, don’t add his public key to eM Client.

1 Like

This option does its job. Using it since that. Thank you!

@Gary I started using eM Client and set it to encrypt by default. However, when sending e-mail to recipients whose keys are not available, a popup windows always requires me to confirm that I want to send that particular message unencrypted. Is there a way to tell eM Client to “encrypt by default if a key is available” ?


I think you have that setting already selected, so every message you send will be encrypted, as long as you have the recipient’s public key. If you don’t have their key, then you are given the popup asking if you to confirm you want to send unencrypted.

Right, but is there a way to avoid the popup every time?

Yes, turn off encryption by default.

Then if you send a message to someone you don’t have a public key for, you will not be reminded that you are sending it unencrypted.

It would be very practical if the encryption functionality in eM Client could be set up as follows:

  1. If I have entered a digital certificate (SMIME or PGP) for my account, then I’d be able to pick the following settings:
    1.1 Always sign emails
    1.2 Always include my public key in the email
    1.3 Auto-encrypt if the public key of email recipient is present
  2. Expected behavior:
    2.1 When receiving an email that includes a public key, auto-insert it in my library
    2.2 When sending to two recipients and there’s a public key for one of them, but not the other, then:
    2.2.1. Auto-encrypt the email to the recipient for whom I have a public key If I have a GPG private key for my account, and there is a GPG public key in my library for the recipient, auto-sign & encrypt the email using the GPG option If I have an SMIME private key for my account, and there is an SMIME public key in my library for the recipient, auto-sign & encrypt the email using the SMIME option If both I and the recipient have GPG and SMIME keys, use the preferred method that I have selected
    2.2.2. Auto-sign the email to the recipient for whom I do not have a public key, as follows: If I only have either GPG or SMIME, use the one that I have If I have both GPG and SMIME private keys, use the preferred method that I have selected

We already have these options.

1.1 and 1.2 are exactly like that in the settings.

1.3 you can do by choosing to encrypt by default. Then if there is a key, it will encrypt. If you don’t have the recipients key, it won’t encrypt.

Please have a look at Menu > Setting > Signing and Encryption > Account policies.

You can set this globally for all your accounts, or have different policies per account.

Thank you for your prompt reply. Good to know that it’s already been implemented, good work!

However, there should be an option to do this “silently”, i.e. not to ask for confirmation when sending to a recipient for whom there is no public key!

The issue with not having a warning is that you might be sending sensitive data that you expect to be encrypted, but it is not, and you will not know.

Yes, this is a concern.

If there are two recipients and one has a public key and the other does not.
And I’m prompted to send the email unencrypted.
Does it go to both recipients unencrypted?

The popup asks if you want to send it unencrypted.

If you choose YES, the message is sent unencrypted, to both recipients.
If you choose NO, the message is not sent and you remain in the compose window.

I guess we’d better leave it as it is then. Thanks.