S/MIME and PGP: Encrypting the Email Message Itself

Short answer: TLS encrypts the connection between mail servers, but the message is readable on every server that handles it. S/MIME and PGP encrypt the message itself, so only the holder of the right private key can read it, and they can add a digital signature that proves who wrote it and that it was not changed. They are strong, but they need keys, certificates and discipline, so most small businesses use them only for sensitive exchanges.

What TLS does and does not do

When two mail servers pass a message to each other, they usually agree on encryption with TLS, which stops someone on the network from reading it in transit. The article on TLS and STARTTLS for email explains this. But TLS protects the pipe, not the letter. At each server, the message is decrypted, stored and passed on, so administrators, backups and any compromised server along the path can read it. If one hop does not support TLS, the message can travel in clear text, depending on the policy.

For ordinary correspondence this is acceptable. For contracts, medical details, payroll data or passwords, many people want more. That is the gap that message-level encryption fills.

How message encryption works

Both S/MIME and PGP use public-key cryptography. Each person has two keys: a public key that can be shared with everyone and a private key that stays secret. To send you a protected message, the sender encrypts it with your public key. Only your private key can decrypt it. For a signature, the process is reversed: the sender signs the message with their private key, and anyone can verify the signature with the public key, which shows that the message came from the key owner and was not altered on the way.

The result is end-to-end protection. The message stays unreadable on the servers in between, including your own mail provider.

S/MIME: certificates from an authority

S/MIME is built into many mail programs, including Outlook, Apple Mail and several mobile apps. It relies on certificates issued by certificate authorities, much like the certificates for websites. You obtain a certificate for your email address, install it in your mail program and send a signed message to a contact. Their program stores your public key from the signature, and from then on they can send you encrypted messages.

Strengths: works inside common mail programs, fits company environments with central management, and certificates provide a clear chain of trust.
Weaknesses: certificates expire and must be renewed, free options are limited, and webmail support varies. If you lose the private key, you lose access to old encrypted messages.

PGP and OpenPGP: keys you manage

PGP, and the open standard OpenPGP, does not rely on certificate authorities. You generate a key pair yourself and share the public key, for example on a key server, on your website or by e-mail. Trust is based on verifying fingerprints with the other person or through people you both know.

Strengths: free, flexible and popular among developers, journalists and privacy-minded users. You control the keys.
Weaknesses: setup is harder, mail programs often need an extension, and mistakes in key handling are easy to make. Most casual contacts will not have a key.

The two systems are not compatible with each other. A person with an S/MIME certificate cannot decrypt a PGP message, and the reverse. Choose the one your contacts use.

What encryption does not hide

Even with a perfectly encrypted body, some information remains visible. The sender and recipient addresses, the date and the subject line normally travel in clear text, because mail servers need them to deliver the message. Do not put secrets in the subject. Attachments are encrypted together with the body, but the file names may be visible in some setups. Encryption also does not protect a message once it is opened. If the recipient’s computer is infected, or they forward the decrypted message, the protection ends there.

Encryption is also not authentication of your domain. Whether a message may claim to come from your domain is decided by SPF, DKIM and DMARC, as described in how the three differ. A DKIM signature is created by the mail server and covers the domain, while an S/MIME or PGP signature is created by the person and covers the individual and the content. They complement each other.

Do you need it?

Ask three questions. What would happen if this message were read by a stranger? How many of my contacts can actually use encryption? Can I manage the keys safely for years? For many small businesses, the answer leads to a simpler option for sensitive material: share it through a secure portal or an encrypted file link and send only the link by e-mail. That way the recipient needs no key, and you control access and expiry.

Message encryption makes sense when you regularly exchange sensitive data with a small group of known partners, such as a law firm and its clients, an accountant and a payroll provider, or a medical practice and a laboratory. In those cases, agree on the method, exchange the keys or certificates in advance and test with a harmless message.

Consider also how the day-to-day experience feels. With S/MIME, the usual routine is to send a signed message once, after which the contact can reply with an encrypted one. Most mail programs show a small lock or a ribbon icon when a message is signed or encrypted, and a warning when a signature does not verify. Teach staff to read those signs and to treat a warning as a reason to stop and check, not to click through. A signature that fails because a certificate has expired is a nuisance, but a signature that fails because the content was changed is exactly what the system is designed to detect.

Mobile devices deserve a thought as well. If you read encrypted mail on a phone, the private key must be on that phone, which increases the places where it could be lost. Use a device passcode, enable device encryption and be able to wipe the phone remotely. If staff use personal phones, decide in advance whether they may hold company keys at all.

Practical rules if you use it

Protect the private key. Use a strong passphrase and keep a secure backup in a separate location. Without the key, old messages cannot be read.
Verify the other person’s key. Check the fingerprint by phone or in person for important contacts, or rely on certificates from a trusted authority.
Plan for renewal and revocation. Certificates expire, and keys can be lost or stolen. Know how to revoke and replace them.
Be careful with search and archiving. Encrypted mail cannot be searched by the server, and company archives may need a policy for decrypting.
Do not rely on it alone. Keep devices updated, use strong passwords and two-factor sign-in on the account.
Test regularly. Send a test message after a new certificate, a new device or a change of mail program.

A compromised mailbox defeats the best encryption, so also read about what to do when an email account is compromised.

A worked example

A small accounting firm receives salary data from clients each month. Until now, the clients have sent spreadsheets by ordinary e-mail. The firm’s owner wants better protection, but most clients are not technical. She first considers S/MIME certificates for everyone and rejects it as too heavy. Instead, she sets up a secure upload link for each client and asks them to send data only through it. For the two larger clients who have their own IT staff, she agrees on S/MIME: both sides obtain certificates, exchange signed test messages and then send encrypted messages for payroll files. She writes a one-page procedure with the renewal dates and the name of the person who keeps the backups of the keys. The effort is modest, and the sensitive data no longer sits readable in mailboxes and archives around the world.

Check your mail domain first

Message encryption is an extra layer on top of correct basics. Make sure the domain itself is set up properly. Run a free check with Site AI Audit and read the e-mail section for your SPF, DKIM, DMARC and MX results.

The bottom line

TLS protects mail on the way, S/MIME and PGP protect the message itself. They are powerful but demanding, and they only work if both sides take part. Use them for sensitive exchanges with known partners, and use secure links for everyone else.

FAQ

Is S/MIME or PGP better?

Neither is better in general. S/MIME suits organisations that use mail programs with built-in support, and PGP suits technical users who want to control their own keys.

Does encryption hide the subject line?

Normally not. The subject and the addresses travel in the clear, so keep secrets out of them.

Can my provider read encrypted messages?

Not the body, if the message is encrypted on your device with the recipient’s public key. The provider can still see the addresses and the time.

What happens if I lose my private key?

You cannot read old encrypted messages. Keep a secure backup of the key and its passphrase.

Does a signature mean the message is safe?

It proves who signed it and that it was not changed. It does not prove that the content or the attachments are free of malware.