Sealed Mail — End-to-End Encryption

Sealed Mail encrypts your personal (Postbox) mail end-to-end when the people you write to can receive it — so the message body and its real subject are unreadable to anyone in between, including the servers that relay it. When a message can't be sealed, Owlat tells you plainly and sends it normally rather than pretending it was protected.

Sealing applies only to Postbox — everyday person-to-person email. Campaigns and transactional mail are never sealed; they stay plaintext by design.

What sealing means

When a message is sealed, Owlat encrypts the entire original message — including its real Subject: line and body — before it leaves your workspace, and signs it with your address's key. Only the recipient's Owlat workspace holds a key that can open it.

Because the real subject is encrypted too, the message that travels on the wire carries a placeholder subject of just ... and only the routing headers a mail server actually needs to deliver it. Your recipient sees the true subject once their workspace opens the message.

When mail auto-seals versus sends in the clear

Owlat can only seal a message when every recipient has a usable sealing key that it has discovered and trusts. This is all-or-nothing: if even one recipient can't receive sealed mail, the whole message is sent normally (a partially-sealed message would leak to the recipient who has no key).

The composer shows a lock indicator that tells you exactly what will happen before you send:

The exact "won't seal" reasons you may see, in plain language:

• "Some of your recipients can't receive sealed mail yet, so this message will be sent normally."
• "Sealed mail is turned off for your workspace, so this message will be sent normally."
• "Sealed mail is available for these recipients, but your workspace is set to ask before sealing, so this message will be sent normally."
• "This address doesn't have a sealing key yet, so this message will be sent normally."
• "Add a recipient to see whether this message can be sealed."

Reading the badges on a message

Sealed Mail surfaces two independent, honest badges on a message you receive. Each one only ever claims what was actually checked — an absent badge means Owlat couldn't confirm something, never that it silently passed.

The Sealed badge (encryption)

Shows whether the message arrived encrypted, and whether its signature checked out:

• "Sealed — sender verified" — the message was encrypted end-to-end and Owlat confirmed it was really signed by the sender. Detail: "This message was encrypted end-to-end, and we confirmed it was really signed by the sender."
• "Sealed — sender not verified" — the message was encrypted end-to-end, but Owlat couldn't confirm who signed it. Detail: "This message was encrypted end-to-end, but we couldn't confirm who signed it."
• "Encrypted — can't decrypt" — the message was encrypted just for its recipient, and this workspace holds no key that can open it. Detail: "This message was encrypted just for its recipient, and Owlat doesn't hold a key that can open it." This usually means the instance was rebuilt without importing the recovery kit.

A plaintext message shows no Sealed badge at all.

The sender-authenticity badge

Independently of encryption, Owlat checks whether a message's stated sender is authorized to send for its domain (using SPF, DKIM and DMARC), and renders one honest state:

• "Verified sender" — "We confirmed this message really was sent for {domain}."
• "Verified via forwarder" — a forwarding service you trust confirmed the message really was sent for the domain before passing it on (normal for mailing lists, whose own checks break in forwarding).
• "Sender not authorized" — "Sent by {other-domain}, which is not authorized to send for {domain}." The classic impersonation shape — treat it with suspicion.
• "Failed sender check" — the message claims to be from a domain but failed that domain's authentication checks. Treat it as suspicious.
• "Unverified sender" — "We couldn't confirm this message really came from {domain}." Owlat simply doesn't know; it never upgrades "don't know" to "verified".

The badge's expandable detail may add plain-language warnings when something looks off — for example that the sender's domain uses look-alike characters, that replies would go to a different domain, or that this is the first message from this address.

Key-change alerts

Owlat pins each recipient's sealing key the first time it seals to them. If that key later changes without a signed statement from the recipient's workspace, Owlat keeps the old pin and stops sealing to that person until you confirm the change — it never silently adopts a new key. You'll see a banner in the thread:

This person's sealing key changed — The key Owlat uses to seal mail to {address} is different from the one you trusted before. Until you confirm the new key, messages to them are sent normally instead of sealed. Only accept it if you were expecting this change.

Accepting the new key requires an owner or admin (it re-pins the key for the whole workspace). If you're not an admin, the banner asks you to have one review it: "Ask a workspace admin to review this key change before sealed mail resumes to this person." Only accept a key change you were actually expecting — an unexpected change can be a sign someone is trying to intercept your mail.

The workspace sealing policy

Owners and admins choose how eagerly the workspace seals, in Settings → Sealed Mail. The choice (locked decision D2) is one of:

• Seal automatically (recommended, the default) — when everyone you're writing to can receive sealed mail, Owlat encrypts the message before it leaves.
• Keep available, but never automatic — Owlat keeps discovering keys and shows when a message could be sealed, but never seals on its own; messages are sent normally until you switch back to automatic.
• Never seal — all Postbox mail is sent normally, even when a recipient could receive it sealed.

Related

• Sealed Mail recovery kit — how to keep the keys that open your sealed history, and what happens if they're lost.
• Transport Security — the operator-side transport hardening (MTA-STS, DANE, TLS reporting) that protects mail on the wire.
• Sealed Mail at Rest — how stored message bodies are sealed in the database.