Secure Email, Explained

Secure email is not one switch or one protocol. A message moves through several systems, and each security layer answers a different question: is the connection private, is the sender genuine, has the message changed, who can read it, and how is it stored?

This guide starts with the route every email takes, then shows where Owlat adds protection — including where those protections deliberately stop.

The short version

• TLS encrypts the network connection between two systems. Each mail server still receives the readable message.
• SPF, DKIM and DMARC help authenticate the sending domain and detect tampering. They do not hide the message body.
• End-to-end encryption encrypts the message itself. Intermediate mail servers carry ciphertext rather than readable content.
• Encryption at rest protects stored data if disks, object storage, or database backups are exposed. The running service can still decrypt data for authorized use.

How an email travels

When you select Send, your mail app submits the message to an outgoing mail server. That server looks up the recipient domain's MX records in DNS, connects to a receiving mail server over SMTP, and transfers the message. The receiving server filters and stores it; the recipient later reads it through webmail or an IMAP connection.

Most modern links use TLS. Submission from an app usually uses TLS on port 587 or 465, server-to-server SMTP upgrades with STARTTLS on port 25, and mailbox access uses HTTPS or IMAPS. This prevents a passive observer on the network from reading the traffic.

But ordinary TLS is hop-by-hop. A TLS connection ends at each mail server, where the message is available in plaintext for routing, spam filtering, indexing, forwarding, and storage. A new encrypted connection begins for the next hop. The provider at either end — and any relay that terminates a hop — may therefore be able to read the message.

Why STARTTLS needs reinforcement

SMTP was designed before encryption was normal. STARTTLS lets two mail servers upgrade a plaintext connection, but ordinary SMTP delivery is often opportunistic: if TLS is unavailable, delivery may continue without it. An active attacker can try to remove the STARTTLS offer or redirect delivery to the wrong server.

Two standards make that harder:

• MTA-STS tells compatible senders to require certificate-verified TLS to the domain's expected mail servers.
• DANE publishes TLS certificate associations in DNSSEC-protected TLSA records, letting a sender authenticate the receiving server without relying only on the public certificate-authority system.

TLS-RPT adds visibility. Receiving domains publish where aggregate reports should go; sending systems report failed or downgraded TLS delivery attempts.

Authentication is not encryption

Email authentication makes impersonation and undetected modification harder, but it does not make the message secret.

These checks complement one another. A message can be perfectly authenticated and still be readable by every server that handles it. It can also be encrypted but signed by an unknown key, meaning the content is private while the sender's identity remains uncertain.

What end-to-end encryption changes

With end-to-end encryption, the sender obtains each recipient's public key and encrypts the message before transport. Only the matching private key can open it. Mail servers still need enough outer metadata to route the message — such as envelope addresses — but the protected content travels as ciphertext.

A digital signature is normally added at the same time. On receipt, the recipient can check that the protected content has not changed and that it was signed by the expected key.

This introduces a key-management problem: software must find the right public key, notice unexpected key changes, protect private keys, and provide a recovery path that does not create a hidden master key. Much of Owlat's improvement is in handling those operational details automatically and visibly.

How Owlat improves secure email

Owlat combines independent controls instead of presenting any one of them as complete protection.

1. Safer transport for every message

Owlat requires TLS for incoming SMTP delivery by default. A sender that does not upgrade receives an error before Owlat accepts or stores message bytes.

For stronger downgrade resistance, operators can publish an MTA-STS policy, enforce other domains' MTA-STS policies on outbound delivery, choose an outbound TLS floor, and evaluate DANE TLSA records in report or enforce mode. TLS-RPT ingestion and the delivery dashboard make failures visible before a policy is tightened.

These controls protect ordinary internet mail too — including messages to providers that do not support Owlat's end-to-end encryption. See Transport Security for setup and exact operator controls.

2. Automatic end-to-end protection between capable workspaces

Sealed Mail protects personal Postbox messages with interoperable OpenPGP/PGP-MIME. Owlat creates a key for each address, discovers a recipient's published public key, signs the original message, and encrypts it to every recipient before SMTP delivery.

The full original message is sealed, including the real subject and body. The outer message uses Subject: ... and retains only what the mail system needs for delivery. Intermediate MTAs therefore carry routing metadata and ciphertext rather than the readable message.

Sealing is all-or-nothing. It happens only when every recipient has a usable trusted key. If one does not, the composer says why and exposes a distinct Send unsealed action — Owlat does not silently describe a partly protected message as sealed.

3. Key discovery with change warnings

Owlat publishes address keys through Web Key Directory (WKD) and advertises them in a signed instance manifest. On first use, the sender pins the discovered fingerprint — a trust-on-first-use model.

If the key later changes without a valid signed rotation, Owlat stops sealing to that address and shows a key-change warning. An owner or admin must review and accept the replacement before sealing resumes. This prevents a newly observed key from being trusted silently.

4. Honest security states in the interface

The reader keeps encryption and sender authenticity separate:

• Sealed — sender verified means Owlat opened an end-to-end encrypted message and verified its signature.
• Sealed — sender not verified means the content was encrypted, but the signer could not be confirmed.
• Encrypted — can't decrypt means the message was encrypted for the address, but this workspace has no matching private key.
• Verified sender, Sender not authorized, and related sender badges report SPF, DKIM and DMARC results independently of Sealed Mail.

An absent badge is not silently treated as success. See Sealed Mail for every composer and reader state.

5. Stored bodies and secrets are sealed too

Owlat seals message bodies and stored raw .eml blobs at rest with AES-256-GCM under keys derived from the instance secret. DKIM private keys and SMTP relay credentials are also sealed under a separate MTA secret. Authorized readers receive plaintext through a checked decrypt-serving path rather than a direct ciphertext storage URL.

This protects database and storage snapshots, but it is distinct from end-to-end encryption: a running Owlat workspace must be able to open mail for authorized reading, search, and optional AI features. Short search fields and vector embeddings are documented exceptions to full-body ciphertext storage. The precise trust boundary and storage design are covered in Sealed Mail at Rest.

The trust boundary, stated plainly

Sealed Mail is end-to-end between the sending and receiving Owlat workspaces. Relay servers between them cannot read the protected subject or body. At the destination, the Owlat workspace opens the message so authorized users can read and search it and, if enabled, use it with workspace AI features.

That is different from device-only encryption where private keys never leave a person's phone or computer. Self-hosters control their endpoint and its instance secret; managed-workspace users trust their Owlat workspace as the endpoint. A recovery kit can restore an address's private key, and anyone who obtains that kit can read mail sealed to it.

What is protected at each point?

Further reading

• Sealed Mail — composer behavior, badges, policies, and key-change alerts.
• Sealed Mail Recovery Kit — backup and restore for address keys.
• Transport Security — MTA-STS, DANE, TLS-RPT, and TLS configuration.
• How Email Works — SMTP, DNS, message anatomy, and deliverability in depth.
• Sealed Mail at Rest — storage envelopes, migrations, exceptions, and decrypt-serving paths.