Business email encryption: what S/MIME and OpenPGP are and when they help

When you email contracts, financial reports or employee records, you need to know who can read them and how recipients can check that they came from you. Email encryption and digital message signing address different problems. S/MIME and OpenPGP support both, but require preparation: compatible applications, identity checks and careful protection of private keys.

A secure connection is not the same as end-to-end content encryption

TLS protects the connection between your email application and its server, or between mail servers, when negotiated. It does not automatically make a message inaccessible to the systems processing or storing it. Check connection security for sending and receiving separately, alongside your service’s transport policy.

For example, your application may show a secure connection while an email about salaries remains accessible in the mailbox to anyone who gains access to the account.

• Transport encryption protects data on the connection concerned.
• Content encryption transforms a message so that reading it requires the corresponding private key.
• Digital signing allows recipients to check message integrity and its association with a signing key.

A signed message is not necessarily encrypted. An encrypted message does not, on its own, prove who sent it. To protect correspondence and help verify its sender, you can use encryption and signing together.

How S/MIME certificates work

S/MIME uses digital certificates that associate an identity or email address with a public key. The corresponding private key must be kept secure. S/MIME certificates are often used in organisations that can centrally manage identities and email applications.

What you exchange with the recipient

To encrypt a message for a business partner, you need their certificate containing a public key suitable for encryption. For an encrypted reply, they need yours. A signed email can carry the public certificate if the application supports that workflow.

For example, before sending a contract to your accountant, send a signed message and ask them to do the same. Check the address in the certificate, its validity, permitted uses and any trust or revocation warnings.

Do not dismiss an unfamiliar certificate warning simply because the displayed name looks right. Confirm unexpected changes through an established channel. An email certificate is not the same as the TLS certificate used by your website.

Signing an email with S/MIME does not automatically create a qualified electronic signature. If a document requires a particular form of signature, check the applicable requirements separately.

How to use OpenPGP keys

OpenPGP also uses public and private keys, but identity verification does not necessarily depend on a certificate issued by a central authority. You publish or share your public key and keep your private key secret. Applications can manage signing and encryption separately, including through subkeys.

To send an encrypted report to a consultant, import their public key and verify its fingerprint: an identifier calculated from the key. The consultant needs your public key to verify your signature or send you an encrypted reply.

• Compare the full fingerprint through an established channel, such as a phone conversation using a previously verified number.
• Do not assume a key is authentic simply because it appears in a public directory or arrived by email.
• Agree how you will announce key replacement, expiry or compromise.

For example, if you receive the message „This is my new key; send the report here”, verify the change before proceeding. Encrypting a document to an impostor’s key protects their access to it, not yours.

Compatibility issues and the limits of protection

S/MIME and OpenPGP are not interchangeable. Both parties need the same technology and compatible applications. Support can vary between desktop software, mobile applications and webmail, even when they access the same mailbox.

For example, you might be able to read a message on your laptop but not in your browser because the necessary feature or access to the private key is missing. Test signed messages, encrypted messages, attachments and replies separately.

• Metadata may remain visible: sender and recipient addresses, routing information and, in many configurations, the subject line.
• Device security still matters: a compromised computer can expose a message after decryption.
• Recipients can copy the content: encryption does not stop them forwarding it after decryption or photographing their screen.
• Filtering may be restricted: systems unable to decrypt the content cannot fully inspect it for threats.

Choose a subject such as „Documents for review” rather than one revealing a medical matter. Keep multifactor authentication enabled and applications updated: encryption does not replace either measure.

Plan recovery before a private key goes missing

Resetting a mailbox password does not automatically recover a private key. If you lose the decryption key and have no usable copy or prepared recovery mechanism, old messages may become impossible to read.

For example, when replacing a colleague’s laptop, importing their messages is not enough: you also need the correct private key. For S/MIME, an export intended for recovery must include the private key, not just the public certificate.

• Keep protected copies of decryption keys according to company policy, separate from the main device.
• Define who may access those copies and under what conditions, with access recorded.
• Test restoration on an authorised device and check that an old message opens.
• Prepare to revoke compromised certificates or keys and notify business partners.
• When an employee leaves, manage access to the archive separately from permission to sign new messages.

Expiry or revocation does not re-encrypt the archive or erase existing copies. Retain old decryption keys for as long as you have a legitimate need for the associated messages. These technologies do not ordinarily provide forward secrecy: a later compromise of the key can expose old encrypted messages retained by an attacker.

Start with a two-person pilot

Choose a technology you can manage and your business partners can use. S/MIME may suit a centrally managed environment; OpenPGP may work well with partners who already have key-verification procedures.

1. Select two users and documents containing no sensitive information.
2. Check applications, identities and the exchange of certificates or public keys.
3. Send a signed message, then a signed and encrypted message with an attachment.
4. Test replies, mobile access, archiving and recovery after moving to another device.
5. Write a short procedure covering warnings, key changes and incidents.

For example, make a signature warning a reason to pause the exchange of confidential documents until it has been checked, rather than something to dismiss in order to continue.

For your business’s online infrastructure, explore GazduireOnline.ro web hosting and use the contact form to ask about available email options. Before extending encryption across your team, confirm compatibility and test recovery: both matter just as much as successfully sending that first protected message.