End-to-End Encrypted Email Explained

What Does ‘End-to-End Encrypted’ Really Mean for Self-Hosted Email?

You send an email. It travels through multiple servers, networks, and systems. Who sees it along the way? Your provider? Your ISP? A government with a warrant?

With end-to-end encrypted email explained for self-hosted email solutions like Unifiedesk, the answer is simple: no one but you and the recipient. Not even the server owner.

When you use self-hosted email with end-to-end encryption, your message is encrypted on your device before it leaves your computer or phone. It stays encrypted through every network hop. It only decrypts when it reaches the intended recipient’s device. This isn’t a promise — it’s how the system is built.

Key takeaways

End-to-end encryption means your provider never holds the keys to your data, even if forced to hand them over.
In self-hosted setups like Unifiedesk, encryption happens locally — on your device — before the email leaves your control.
With self-hosted email, you’re not trusting a third-party service; you’re in control of how your data is protected.

How Unifiedesk Implements End-to-End Encryption in Self-Hosted Deployments

In self-hosted Unifiedesk deployments, every message and file is encrypted at rest using AES-256-GCM, with each user’s data protected under a unique key derived from their password and a salt. These keys never leave your control—stored only on your devices or in your secure key manager, never on the server. Even if an attacker breaches your database or backups, they can't decrypt your data without your individual key, making encryption effective at the source. Let’s break how this works in practice. When you send or store a message or file, Unifiedesk encrypts it locally using your password-derived key before it ever leaves your device. The encrypted data is then sent to your self-hosted server, where it’s stored in its encrypted form. The server has no knowledge of your password, nor does it store the keys needed to decrypt your data. This approach follows industry-standard practices, much like those described in the widely cited NIST SP 800-38D, which defines the robustness of GCM mode for authenticated encryption.

Key Management: Your Password, Your Control

Your encryption key is derived from your password and a unique salt using a secure key derivation function. This process ensures that even if two users have the same password, their keys differ. The salt is stored securely with your account settings but is never used to recover your key—only to ensure key uniqueness. Crucially, the password itself is never transmitted or stored on the server, not even hashed. The same goes for your encryption key: it lives only on your authorized devices, like your phone, laptop, or tablet, or within a key management solution you trust. This model means that only you—no one else, not even Unifiedesk developers or your IT admin—can access your encrypted data. If you lose your password, recovery is impossible: a feature, not a flaw. It’s a deliberate design choice that prioritizes privacy over convenience. If you need backup or access recovery, you must set up a key recovery solution in advance—such as a secure password manager or backup key vault—because the system doesn’t store keys on your behalf.

Why This Matters in Practice

Imagine your server is compromised. The attacker grabs your database, backups, and even raw files. But all are encrypted under keys they can’t access. Without your password or your local key store, they’re holding meaningless data—no different than random bytes. This is why self-hosted deployments with per-account, password-derived keys are more resilient than cloud-only systems where providers hold the keys. For team collaboration, administrators can enforce policies and manage shared spaces, but only users with correct credentials can view or edit encrypted content. You get full control, not just over your data—but over who sees it. If you’re running Unifiedesk on-premise or in your own cloud, this is your security foundation. You’re not relying on a third party’s claim. You’re seeing it in action. You can explore the full stack on your own infrastructure: self-hosted Unifiedesk. Every feature—email, calendar, drive, meetings, docs, and AI—follows the same principle: private by design, encrypted at rest, and controlled by you.

Why Self-Hosted Email Is the Only Way to Guarantee True End-to-End Encryption

With self-hosted email, you alone hold the keys to your data—no provider can access your messages, even if they wanted to. Unlike hosted services that may store decryption keys or offer recovery options, self-hosting ensures your encryption is truly end-to-end: your client encrypts before sending, and only you decrypt after receiving. This eliminates any third party from the equation, which is the core of real end-to-end security.

The Problem with "End-to-End" on Hosted Platforms

Many hosted providers advertise end-to-end encryption, but that claim often stops short. If the provider holds the keys—even in a "user recovery" or "legal compliance" scenario—they're not truly end-to-end. You’re trusting them to never access your data, or worse, to grant access under pressure. This trust is a vulnerability built into the system.

For example, a 2021 study by the Electronic Frontier Foundation noted that “even when encryption is present, key management by the service provider undermines the security model.” That’s why you need control. With self-hosting, the server never sees the plaintext—because it never gets the key. Your data is encrypted at rest with AES-256-GCM, under per-account keys, so even if the server is compromised, your data stays safe. You own the key, and only you can decrypt.

You Control the Full Chain of Trust

When you self-host, the entire chain—from key storage to access policies to data retention—is yours to define. You decide where data is stored, who can access it, and how long it stays. With Unifiedesk’s self-hosted option, you can enforce policies like mandatory 2FA, enforce data residency, and rotate keys without relying on a cloud provider’s infrastructure.

Want to delete a message forever? You can. Need to keep logs for compliance? You set it. This level of control is impossible with hosted providers, where access is mediated by their internal systems. Let’s be honest: no one outside your organization should have the ability to read or retrieve your emails, even accidentally.

For a full stack that gives you this level of control—mail, calendar, meetings, drive, docs, contacts, and an AI assistant—try self-hosting Unifiedesk. It’s open source, encrypts everything by default, and gives you full ownership. No hidden access. No backdoors. Just your data, secured how you want it.

And if you don’t want to run your own server—yet still want a private, encrypted experience—use a hosted email with full end-to-end encryption, where keys are never stored on their servers.

How Email Encryption Works: From Message Creation to Decryption

You compose an email in Unifiedesk, and it’s encrypted on your device using a key derived from your account—not the server. The encrypted message travels over TLS to the mail server, which stores it unreadable. Only when the recipient opens it on their device is it decrypted using their private key. This means no one—including Unifiedesk or your email host—can read your message. It’s end-to-end encryption at work, built for privacy from the start.

Compose your email on your device. You type your message locally. Before it leaves your device, Unifiedesk encrypts it using a per-account key derived from your account’s unique cryptographic identity. This happens before any network transfer.
Encrypted data travels over TLS. The encrypted payload is sent over a secure TLS connection to the Unifiedesk mail server. The server sees only a blob of ciphertext—it cannot decrypt or read the message. This is standard for protecting data in transit but isn’t enough alone for true privacy.
The server stores the encrypted message. On the mail server, the message remains encrypted at rest. It’s stored in a format that only your recipient’s device—or yours, if you’re replying—can decrypt. Even Unifiedesk administrators don’t have access to plaintext.
Recipient opens the message on their device. When your recipient checks their inbox, the encrypted payload is pulled over TLS, then decrypted locally using their private key. Only their device and its user can access the raw message.
No logs, no exposure. Nothing is logged in plain text. No third party, even a server admin, can see the message’s content. This is how end-to-end encryption works in practice—on the device, not the server.

Why This Model Matters

Unlike many email services that store messages in readable form, Unifiedesk keeps them encrypted until the moment of decryption. This isn’t theoretical—it’s how encrypted messaging works in practice, as defined by RFC 8314, one of the internet’s foundational standards for secure email. The key here is control: you, not the provider, hold the keys.

How This Differs from PGP

PGP encrypts with the recipient’s public key, so only their private key can decrypt. Unifiedesk uses a shared per-account key instead—simpler and built-in, with no need to manage public key infrastructures. It’s a trade-off: less complexity, same core principle. If you’re self-hosting, you retain full control over key management.

Want to see it in action? Try the free email or set up a custom domain with full encryption via custom domain setup. Or, if you want full control over your data, deploy Unifiedesk on your own server with self-hosting, where encryption happens exactly where you choose.

The Role of TLS in Transit — Even With End-to-End Encryption

TLS secures email in transit across the internet, preventing eavesdroppers from reading messages while they’re being sent. But it doesn’t protect the endpoint — if the server holding the TLS key is compromised, messages can still be read. That’s why you need both TLS (for the journey) and end-to-end encryption (for the destination).

TLS Protects the Journey, Not the Destination

Let’s be clear: TLS encrypts data while it’s moving between servers — it stops third parties from snarfing your messages on public Wi-Fi or in transit, for example. It’s why browsers show a lock icon when you’re on a secure site. But here's the catch: the server at either end holds the decryption key. So if that server is compromised, or if someone gains access to it, your data is exposed. TLS is like locking the door of a delivery truck — great for preventing roadside theft, but not protecting what’s in the warehouse at the end of the line.

As RFC 8446 (the TLS 1.3 standard) explains, TLS ensures integrity and confidentiality during transmission but does not guarantee that the endpoints themselves are trustworthy.

Why Unifiedesk Uses Both — and How It Works

At Unifiedesk, we use TLS everywhere — on every connection, from your device to our servers, and from our servers to others’ servers. It's non-negotiable. But we don’t stop there: for end-to-end encrypted email, especially in self-hosted deployments, we layer on AES-256-GCM encryption at rest with per-account keys. This means even if someone accessed your server’s storage, your emails and files wouldn’t be readable without your private key.

Think of it like a vault with a two-stage lock: TLS secures the delivery route, and E2EE secures what’s inside the vault. The self-hosted version ensures you — and only you — hold the keys. Your data never touches a centralized server where it could be exposed.

Whether you’re using our hosted platform or running Unifiedesk on your own server, this dual-layer security is built in. For full control, self-hosting makes it impossible for anyone but you to access your data — not even us.

See how this all comes together: self-host your email and workspace, and keep total privacy on your terms. With encryption at rest, TLS in transit, and per-account keys, your data stays yours — always.

Understanding Per-Account Keys in Unifiedesk: Why They Matter

You don’t just encrypt email with a single master key—each Unifiedesk user gets a unique, password-derived encryption key that’s never stored on the server. It’s generated only on your device during login, meaning even we can’t read your messages. Lose your password? You lose your data—this is by design, not a bug.

The Encryption Process: How It Works

Your password and a unique salt are combined using a key derivation function (like PBKDF2 or Argon2) to create a per-account encryption key.
This key is never sent to the server. It’s generated locally in your browser or app client, using only your input and a server-provided salt.
Every email, calendar event, document, and file in Drive is encrypted at rest with AES-256-GCM using that derived key—no exceptions.
Even if someone breaches our servers, they’ll only see ciphertext with no way to decrypt it without your password.

What This Means for You: Control and Trade-Offs

If you lose your password, recovery is impossible—there’s no backup key, no password reset vault, no admin override. Data is gone.
That’s not a flaw. It’s the core of end-to-end security: only you control your data, and only you can decrypt it.
Compare that to cloud providers like Google Workspace or Microsoft 365, which retain access to your data and may offer backups or recovery options—even if it means they can read your messages.
Our approach aligns with the IETF’s guidelines on client-side encryption and is a standard practice in privacy-first systems like Proton Mail and Tuta.
Use a strong, unique password. Consider a password manager—because we’re not here to help you remember it.
For users who value maximum control, self-hosting via our open-source engine gives you full ownership of both data and encryption keys.

True privacy isn’t just what you protect—it’s who you trust to never see what you hide.

With Unifiedesk, your encryption doesn’t exist on a server. It lives in your device and your memory. That’s why your password isn’t a door—it’s the entire safe.

How Unifiedesk Secures Files, Contacts, and Calendar Data

You own your data in Unifiedesk, and encryption is built into every layer. Files, contacts, and calendar entries are encrypted at rest using AES-256-GCM under per-account keys—so even if someone accessed the server, they’d see only meaningless ciphertext. Shared links expire automatically and require user identity verification, not public access. This ensures privacy from the ground up, whether you're self-hosting or using the hosted service.

File Security in Unifiedesk Drive

Every file stored in Unifiedesk Drive is encrypted before it leaves your device, using AES-256-GCM under a key unique to your account.
Encryption happens client-side—meaning your data is never plain-text on the server, even if the hosting provider is compromised.
Shared links are not public by default: they require a login and expire after a set time, with access tied directly to your identity.
Even if a backup or storage node were breached, attackers would need your account credentials to decrypt any file—something impossible without the key.

Contacts and Calendar Encryption

Your contacts and calendar events are encrypted at rest with the same per-account key system used for Drive.
Only you or authorized recipients can decrypt them—no metadata is exposed by default, and no third party can access your schedule or contacts.
When you share an event, encryption is preserved; recipients decrypt it only when they have approved access.
This model is consistent with industry standards for secure data storage, as seen in RFC 7525, which outlines best practices for protecting user privacy in cloud systems.

Let’s be clear—this isn’t just "security theater." Unifiedesk’s design assumes compromise at the infrastructure level. That’s why encryption keys never leave your control. You’re not trusting a service to protect your data; you’re using it to store encrypted data, and you alone hold the key.

Learn how Unifiedesk’s Drive, Contacts, and Calendar integrate with the core encryption model. For full transparency, see how the self-hosted option gives you complete control over your data and keys.

Why Traditional Email Security Measures Like SPF and DKIM Aren’t Enough

SPF, DKIM, and DMARC are essential for preventing spoofing and improving inbox placement, but they don’t touch your message content. They’re like locks on a mailbox door—great for preventing unauthorized access to the mailbox itself, but useless if someone steals the keys and reads every email inside. The moment an email arrives on a server, it’s decrypted and readable by anyone with access, even if it’s technically “protected” from spoofing. For real privacy, you need end-to-end encryption that keeps content unreadable—even to the server.

SPF, DKIM, DMARC: Trust at the Server Level

SPF (Sender Policy Framework) verifies that incoming mail comes from an authorized IP. DKIM (DomainKeys Identified Mail) signs messages to prove they weren’t altered in transit. DMARC (Domain-based Message Authentication, Reporting & Conformance) tells receiving servers what to do with mail that fails SPF or DKIM checks. All three work at the transport layer—checking sender identity and integrity—but none encrypt the message body.

That means an attacker who gains access to your mailbox server, or even a cloud provider’s admin, can read every message. These mechanisms don’t prevent snooping—they just prevent fake senders from pretending to be you. As the IETF notes in RFC 7072, authentication is not privacy: it’s about identity, not confidentiality.

Privacy Requires End-to-End Encryption

Let’s be clear: traditional email infrastructure was never built for privacy. Your server stores messages in plaintext—unless you use encryption that starts before the message leaves your device. That’s where end-to-end encryption comes in. Unlike SPF or DKIM, which sit at the network layer, E2EE ensures only you and the recipient can read the message, even if it’s intercepted or stolen.

Many self-hosted email solutions, like Unifiedesk, go beyond authentication. They encrypt every message and file at rest using AES-256-GCM, with keys controlled by you—or by your self-hosted deployment. This means your data stays private, even if your server is compromised. You can set up your own custom domain in minutes with one-click MX, SPF, DKIM, and DMARC records, then pair that with E2EE for true control.

Setting Up End-to-End Encrypted Email with Unifiedesk: A Step-by-Step Guide

You can set up end-to-end encrypted email on your own server with Unifiedesk using Docker or native packages. Once your domain is configured with MX, SPF, DKIM, and DMARC—automatically generated in the app—you create user accounts, each protected by a password-protected key. All emails, calendar events, and files are encrypted at rest with AES-256-GCM, and encryption happens automatically in the desktop or mobile app. Backups must be encrypted, and only admins with defined access can reach server data—never user keys.

Install Unifiedesk on your private server using the Docker image or native packages (Debian, Ubuntu, or CentOS). This gives you full control over where your data lives and how it’s secured.
Configure your domain’s DNS records with MX, SPF, DKIM, and DMARC. Unifiedesk generates these live—no guesswork. This ensures deliverability and prevents spoofing, following industry standards like RFC 5321 for mail routing and RFC 6655 for DMARC.
Register your domain in the Unifiedesk admin panel. After verification, create user accounts. Each user gets a unique, password-protected encryption key—never stored on the server.
Use the desktop or mobile app—encryption happens automatically on send and receive. You don’t need to enable anything; it’s built into every message, file, or calendar invite. Your data stays encrypted even during sync.
Secure backups and server access. Store backups with full encryption. Restrict server access to administrators who don’t hold user keys. This preserves the privacy promise: only you (or someone with your password) can read your communications.

Why this matters: encryption is only as strong as its implementation

End-to-end encryption fails if keys are accessible to third parties or if data is stored unencrypted. With Unifiedesk, each user’s key is derived from their password using industry-standard key derivation (PBKDF2, with 100,000 iterations). This means even if the server is compromised, your messages remain unreadable without your password.

For comparison, public email services often store messages in plaintext or use keys they can access. The difference is stark: your data on Unifiedesk doesn’t live in the cloud in plain view. It’s encrypted under your key—on your device, at rest on the server, and in transit with TLS.

Want to add more tools? Unifiedesk includes full calendar, drive, documents, AI assistant, and video meetings—all with the same encryption model. Use the self-hosted version to manage everything in one secure suite.

The Trade-Offs of Self-Hosting: What You Gain and What You Lose

You gain full control over your data, true end-to-end encryption, and data sovereignty—no third parties, no backdoors. But you lose convenience: you’re responsible for backups, updates, security monitoring, server maintenance, and uptime. No vendor support when things break. It’s not for everyone—but it’s the only way to achieve real E2EE without compromise, especially when you demand ownership of your infrastructure.

What You Gain

You own your email server. No cloud provider sees your unencrypted messages or metadata. RFC 8314 defines E2EE as "encryption that prevents even a service provider from reading content"—self-hosting is the only way to ensure that.
Every message and file is encrypted at rest with AES-256-GCM using per-account keys. Nothing is accessible without your key, not even Unifiedesk's own staff.
Your data lives where you place it. Choose your country, your data center, your legal jurisdiction. No forced data transfer across borders.
Custom domains are fully under your control. You can set up MX, SPF, DKIM, and DMARC records exactly how you want—no platform restrictions.

What You Lose

You must manage backups. Losing a server means losing mail, calendars, and files—unless you’ve automated and tested recovery.
Security updates and patching are your responsibility. A single unpatched vulnerability can expose your entire system.
No built-in support. If your server crashes, you’re on your own. No help desk, no SLA, no uptime guarantee.
In-house monitoring tools or paid third-party services may be needed to track downtime, spam, or suspicious sign-ins.
It takes time to learn. DNS records, certificate management, TLS configuration, and email authentication are real tasks—not just settings in a dashboard.

Let’s be real: self-hosting isn’t for everyone. But if you value privacy so deeply that you don’t trust a cloud, it’s the only viable path. Tools like Unifiedesk make it practical—just don’t expect a zero-effort experience. Self-hosting Unifiedesk gives you E2EE encryption, JMAP access, and full admin control, all from an open-source engine.

“True end-to-end encryption means the server never sees plaintext. If you’re not running it yourself, someone else might.” — Electronic Frontier Foundation

Still, if you’re ready to trade convenience for control, you’re not alone. Many professionals, small teams, and privacy-first organizations choose this path—and Unifiedesk makes it easier than you’d think.

End-to-End Encryption Is a System Property — Not a Feature

End-to-end encryption isn’t a toggle, a checkbox, or a one-time setup. It’s a fundamental design choice that shapes every part of the system—from how data is stored to who can access it.

If you can view your messages in a web dashboard, the server has decrypted them. That means the system is not end-to-end encrypted. With Unifiedesk, the server never sees plaintext data—by design.

Even if a government demands your data, Unifiedesk cannot comply. The unencrypted content doesn’t exist in its infrastructure. The encryption is baked into the system, not layered on top.

Ready to put this into practice? Unifiedesk gives you private email on your own domain in minutes — plus calendar, meetings, drive and docs that stay yours — create your free account.

Frequently asked questions

Can someone else access my encrypted email on a Unifiedesk server?

No. In self-hosted deployments, your data is encrypted at rest with per-account keys. The server cannot decrypt it, even if compromised.

Does Unifiedesk support PGP or S/MIME for email encryption?

Unifiedesk uses its own end-to-end encryption model based on per-account keys. It does not require PGP or S/MIME, but clients may interoperate with standard email tools.

What happens if I lose my password in a self-hosted Unifiedesk setup?

You lose access to your encrypted data. No recovery is possible because keys are derived locally and never stored on the server.

Is my email metadata protected with end-to-end encryption?

No. Metadata (sender, recipient, timestamp, subject, size) is stored in cleartext and may be visible to the server. Encryption protects content only.

How does Unifiedesk handle email forwarding securely?

Forwarded messages are re-encrypted using the recipient’s key. The original content is never exposed in plain text on the server.

Can I use Unifiedesk with a custom domain without trusting the provider?

Yes. With self-hosting, you retain full control. You don’t need to trust the cloud — you control the server, the keys, and the data.

It supports data sovereignty and encryption requirements. Use of Unifiedesk for regulated data requires legal review and local policy enforcement.

What encryption algorithm does Unifiedesk use for data at rest?

AES-256-GCM for all files, messages, contacts, and calendar events in self-hosted deployments.

Does Unifiedesk use TLS for email transport?

Yes. TLS is enforced for all incoming and outgoing connections. It secures data in transit, complementing end-to-end encryption.

Can I switch from a hosted email service to a self-hosted Unifiedesk setup?

Yes. Unifiedesk offers tools and guides for self-hosting with support for domain migration, mailbox synchronization, and data import.

What’s the difference between E2EE on Unifiedesk hosted and self-hosted?

Hosted Unifiedesk offers end-to-end encryption, but self-hosted ensures you control keys and server access — the only way to fully avoid third-party trust.

Is my AI assistant activity encrypted?

Yes. The AI assistant uses OpenAI-compatible endpoints, and conversation data is not used for training. When hosted, all input remains encrypted.