The Spark Team
Smart. Focused. Email.
Fast, cross-platform email designed to filter out the noise - so you can focus on what's important.
Definition
💡Email encryption: the process that scrambles your message into unreadable code so only the intended recipient (or their device) can turn it back into words. Most of your email is quietly encrypted the second you hit send. Whether it stays that way for the whole trip is a different question. Almost all email is encrypted in transit by default (that's TLS, and it happens automatically). Real end-to-end encryption, where nobody but you and the recipient can ever read the message, is a separate, optional layer you have to turn on yourself.
What email encryption is and isn’t
Most people assume that "my email is encrypted" means nobody but the recipient can read it. Usually, that's not quite true.
Modern email typically travels over TLS (transport layer security), the same technology behind the padlock in your browser's address bar. It encrypts the connection between mail servers, hop by hop. Gmail talking to Outlook, Outlook talking to your company's server, and so on. Each hop is locked. But at each server along the way, the message itself sits there decrypted, readable by whoever runs that server. That's encryption in transit, and it's automatic on virtually every major provider today.
End-to-end encryption is different, and stricter. Only you and your recipient hold the keys. Not your email provider, not their email provider, nobody in between. Spark's end-to-end encryption glossary entry covers that specific mechanism in more depth. For most everyday email (scheduling lunch, forwarding a meme), TLS is plenty. For a signed contract, a medical record, or a client's bank details? That's when the difference between these two things is actually import for you to understand.
Email clients usually connect to your provider over TLS automatically, no setup required on your end.
Types of email encryption
You've got three worth knowing.
TLS (in transit) is the default: quiet, automatic, no action needed. It stops someone from reading your mail while it's moving across the internet. It does not stop the mail server itself, or anyone who compromises that server, from reading a message once it lands. Good baseline. Not bulletproof.
S/MIME uses a certificate tied to your identity to encrypt and digitally sign messages end to end. Common in enterprise and government settings, where IT issues the certificate for you. Outlook supports it natively. Free personal Gmail doesn't. S/MIME in Gmail is only available through paid Google Workspace plans, configured by an admin, not something you turn on yourself.
PGP (Pretty Good Privacy) relies on a public and private key pair you generate and manage yourself. No certificate authority, no company issuing anything, just you holding the keys. Powerful, genuinely private. But also the most manual of the three, which is exactly why it never went mainstream outside privacy-focused and technical circles.
Email encryption best practices
Know what "encrypted" actually means before you trust it. Confidential mode isn't encryption. It's an expiring, revocable link.
Turn on two-factor authentication regardless. Encryption protects a message in transit. It does nothing if someone just logs into your account directly.
Use S/MIME or PGP for anything genuinely sensitive: contracts, medical details, financial records. For a grocery list, TLS alone is fine.
Password-protect attachments when full encryption isn't available. A locked PDF, sent with the password over a separate channel (a text, a call), covers a surprising number of cases.
Check with your recipient's IT team before assuming S/MIME will just work. Certificates on both ends need to line up, or the message won't decrypt cleanly.
Related terms