LiveChat 
Support 
How to Send Encrypted Email: The Three Levels of Email Encryption Explained
If you have ever wondered how to send encrypted email, you have probably also discovered that “encrypted” is one of the most slippery words in all of computing. People say it like it means one specific thing. It does not. There are actually three different layers of email encryption, and most of the panic, confusion, and false confidence around secure email comes from not knowing which layer you are talking about.
The good news is that this is far less intimidating than it sounds. Once you understand the three levels, the practical steps fall into place, and you can stop worrying about whether your everyday mail is “really” protected. Let’s walk through it calmly, because security should make you feel safer, not more anxious.
Key Takeaways
• “Encrypted email” is not one thing — there are three distinct levels: in transit (TLS), end-to-end (E2EE), and at rest.
• TLS likely already protects your everyday email as it travels between mail servers. It is automatic on most modern providers, but only works if both ends support it.
• End-to-end encryption (S/MIME or PGP) is the only level where *no server in between* can read your message — but it requires the recipient to participate.
• For everyday privacy, TLS is enough. For truly sensitive or regulated material, you need E2EE — and a recipient set up to decrypt it.
• Know which level your situation actually demands before assuming “encrypted” means “private from everyone.”
What does “encrypted email” actually mean?
Here is the most important thing to understand before you change a single setting: when someone says “send me an encrypted email,” they could mean three completely different things, and getting it wrong has real consequences.
The honest, slightly uncomfortable truth is this: most people who believe they are “sending encrypted email” only have the first layer — transport encryption (TLS) — which scrambles the message *while it travels* between mail servers but leaves it perfectly readable to the mail providers on each end. That is genuinely fine for everyday privacy. It is *not* what “encrypted” implies when you are sending a medical record, a legal contract, or a password. For that, you need end-to-end encryption, where only you and the recipient hold the keys and no server in the middle can ever read the contents. The catch that quietly stops most people: true end-to-end encryption requires the *recipient* to participate — to exchange keys or use a compatible system — which is exactly why it remains rare. So the real answer to “how do I send encrypted email” is: TLS is probably already protecting your mail in transit (verify it is on), but if you mean “no one but the recipient can ever read this,” you need end-to-end encryption *and* a recipient who can decrypt it. Knowing which layer your situation actually demands is the entire game.
Once you internalize that, everything else is just configuration.
What are the three levels of email encryption?
Email can be encrypted at three different stages of its life: while it moves, while it sits, and end to end. Each protects against a different threat, and each has different requirements. Here is the complete picture in one place.
| Level | What it encrypts | Who can still read it | How you get it | Best for |
|---|---|---|---|---|
| 1. In transit (TLS) | The connection between mail servers | Both mail providers (sending & receiving) | Usually automatic — if *both* servers support it | Everyday mail; baseline privacy |
| 2. End-to-end (E2EE) | The message content itself | Only the sender and the recipient | S/MIME (certificates) or PGP/GPG (keys), or an E2EE email service | Truly sensitive, confidential, or regulated material |
| 3. At rest | The stored copy on the server | The provider (holds the storage keys) | Provider feature — server-side storage encryption | Protecting stored mail if the server is breached |
Notice the middle column. That is where the real difference lives. With TLS, your provider can still read the message. With end-to-end encryption, *nobody* in the middle can — not even the email service itself. At rest encryption protects the copy sitting in storage, but the provider typically still holds the keys, so it is a defense against theft of the physical data, not against the provider itself.
How does encryption in transit (TLS) work?
Transport Layer Security (TLS) is the baseline — the workhorse of email privacy. When your email client sends a message, and when one mail server passes it to the next, TLS encrypts that *connection*. An eavesdropper sitting on the network between the servers sees scrambled noise instead of your message.
The reassuring part: on virtually every modern, reputable email provider, TLS is already on by default. You are almost certainly using it right now without having configured anything.
The honest caveat: TLS is opportunistic. It only protects a given “hop” if both ends support it. If your message passes through an older server that does not negotiate TLS, that hop may fall back to plaintext. And critically — once the message arrives, the receiving provider can read it, because TLS only protects the journey, not the destination.
How to verify TLS is working:
- Check that your client uses secure ports — IMAP over SSL/TLS (port 993) and SMTP with TLS (port 587 or 465) rather than their unencrypted equivalents.
- Many webmail interfaces and clients display a small lock or “encrypted” indicator on received messages showing the connection was secured.
- Your provider’s documentation should confirm TLS is enforced for connections.
For everyday correspondence, TLS is genuinely enough. Do not let anyone make you feel otherwise.
How does end-to-end encryption (E2EE) work?
This is the level people *imagine* when they say “encrypted email.” With end-to-end encryption, the message is scrambled on your device and can only be unscrambled on the recipient’s device. The mail servers in between carry sealed gibberish they cannot open. There are three practical paths.
1. S/MIME (certificate-based). S/MIME uses digital certificates issued by a certificate authority. It is built into many mainstream email clients, which makes it the smoother option for organizations. You obtain a certificate, install it, and your client handles the encryption. The trade-off is that managing certificates at scale takes some administrative effort.
2. PGP / GPG (key-based). PGP (and its open implementation GPG) uses a pair of keys — a public key you share and a private key you guard. Anyone with your public key can encrypt a message only your private key can open. It is powerful and free, but more technical: you generate keys, exchange public keys, and often install a plugin or use a client that supports it.
3. A secure email service or portal. Some email services offer built-in E2EE between users, or a “secure send” feature that delivers the message through a password-protected web portal instead of normal email. This sidesteps the key-exchange burden for the recipient — handy when sending sensitive documents to someone who is not technical.
The hurdle nobody warns you about: with S/MIME and PGP, the recipient must be able to decrypt the message. That means they need the right certificate or your public key, and a compatible client. This *key exchange* is the practical reason end-to-end encryption is still uncommon — it takes two prepared parties, not one. Portal-based “secure send” exists precisely to dodge this problem, which is why it is popular for one-off sensitive documents.
How do you actually send an encrypted email, step by step?
Let’s make this concrete. Here is the practical sequence, matched to the level you need.
| Your situation | The level you need | What to do |
|---|---|---|
| Everyday email, normal privacy | In transit (TLS) | Verify TLS is on (secure ports, provider confirms) — usually nothing else needed |
| Sensitive doc to a non-technical person | Portal / password-protected send | Use your provider’s “secure send” or share via an encrypted portal with a password sent separately |
| Confidential mail to a prepared contact | End-to-end (S/MIME or PGP) | Exchange certificates/keys in advance, then encrypt in your client |
| Regulated data (health, legal, finance) | End-to-end + compliance controls | Use E2EE plus a provider that meets your regulatory requirements |
Practical steps for everyday TLS:
- Confirm your client connects over IMAP/SMTP with SSL/TLS (ports 993 and 587/465).
- Confirm your provider enforces TLS for outbound and inbound connections.
- Send normally — the encryption is automatic.
Practical steps for end-to-end:
- Decide on a method: S/MIME (certificate) or PGP (keys).
- Obtain your certificate or generate your key pair.
- Exchange with your recipient — give them your public key/certificate and get theirs.
- In your client, choose the “encrypt” option when composing.
- Send. Only your recipient can open it.
A caveat worth repeating: end-to-end encryption typically protects the *body* and attachments, but the subject line and metadata (who, when, message size) often remain visible. Never put sensitive details in the subject line.
Secure email foundations, done right with DarazHost
If all of this has you thinking about your own setup, this is exactly where the right foundation matters. DarazHost business email enforces encryption in transit (TLS) by default, so your everyday mail is protected the moment it leaves your outbox as it travels between servers. We support secure IMAP/SMTP connections, and we set you up with proper SPF, DKIM, and DMARC authentication so your domain’s mail is both protected and trusted. You get private, controlled email on your own domain — not a shared, ad-scanned mailbox — which is the bedrock of real email privacy. And because the encryption *level* you need depends on your situation, our 24/7 support is here to help you configure exactly what your needs require, from baseline transport security to the foundations for end-to-end workflows. Secure email foundations, handled properly, so you can focus on the message instead of the plumbing.
For the full picture of running professional, secure email on your own domain, see our complete guide: Business Email Hosting: The Complete Guide to Professional Email on Your Own Domain.
When do you actually need end-to-end encryption?
This is where a lot of well-meaning advice goes wrong by implying everyone needs maximum encryption all the time. They do not, and chasing it unnecessarily creates friction that makes people give up on security entirely.
Use TLS (the everyday baseline) for: ordinary correspondence, newsletters, scheduling, general business communication. The vast majority of your email lives here, and it is already protected in transit.
Step up to end-to-end encryption for:
- Health records and medical information
- Legal documents and contracts
- Financial data, account numbers, and credentials
- Anything covered by a regulatory regime (privacy, healthcare, finance laws vary by region — check what applies to you)
- Genuinely confidential personal or business matters
The deciding question is simple: *”Would it be a problem if a mail provider — or anyone who breached one — could read this?”* If yes, you need end-to-end encryption and a recipient prepared to decrypt it. If the honest answer is “it would be mildly awkward but not damaging,” TLS is doing its job.
Frequently asked questions
Is my email already encrypted? Almost certainly *in transit*, yes. Modern providers enable TLS by default, which encrypts your message as it travels between servers. However, it is *not* end-to-end encrypted unless you specifically set that up — meaning the mail providers on each end can still read it. Verify your client uses secure ports (993 for IMAP, 587/465 for SMTP).
What is the difference between TLS and end-to-end encryption? TLS encrypts the *connection* between mail servers, so eavesdroppers on the network cannot read your message — but the providers themselves can. End-to-end encryption (S/MIME or PGP) encrypts the *message itself*, so only you and the recipient can read it; no server in between, including your provider, can decrypt it.
Can I send an encrypted email to someone who is not set up for it? With S/MIME or PGP, no — the recipient must have the right key or certificate and a compatible client. This key-exchange requirement is the main reason E2EE is uncommon. The workaround is a portal-based “secure send” feature, which delivers the message through a password-protected web page that anyone can open without prior setup.
Does email encryption hide the subject line? Usually not. Even with end-to-end encryption, the subject line and metadata (sender, recipient, time, message size) typically remain visible. Never put sensitive information in the subject line — keep it in the encrypted body.
Is encryption at rest the same as the message being private? No. Encryption at rest protects the stored copy on the server against physical data theft, but the provider typically holds the storage keys and can still access the content. It is a useful defense layer, but it is not the same as end-to-end privacy.
The reassuring bottom line
Sending encrypted email is not really about one magic switch — it is about matching the right level to the right situation. Your everyday mail is most likely already protected in transit by TLS, and that is genuinely enough for the vast majority of what you send. When something truly sensitive comes along, you step up to end-to-end encryption, accepting that the recipient needs to be set up to decrypt it. Build on a solid foundation — secure connections, proper authentication, private email on your own domain — and the rest becomes a calm, deliberate choice rather than a source of worry.
