welp.email Docs Open welp.email →

welp.email — email, but secure

welp.email is end-to-end encrypted mail. Your subject and body are sealed in your browser before they ever leave it, so the server only ever stores ciphertext. If the server is compromised, an attacker gets nothing readable — not a subject, not a body, not a filename.

There are no passwords. You sign in with a passkey (Face ID, Touch ID, a security key), which also unwraps the encryption keys that live only on your devices.

Getting started

  1. Create your inbox. Pick a name — that's your address, you@welp.email — and create a passkey. Your encryption keys are generated right there in the browser.
  2. Write someone. Hit Compose, type their address, write, and Send securely. welp.email seals the message to the recipient's public key before sending.
  3. Read. Everything in your inbox is decrypted on your device as you open it. Search works too — it runs locally, because the server can't read your mail to search it for you.

A verified badge on a message means welp.email checked the sender's signature: it really came from them, and it arrived sealed.

Conversations

Replies group into a single conversation. Open one and you see the whole thread — the first message and every reply, flat and in order, with older messages collapsed to a line you can click to expand. Reply sits right below the latest message.

Screening & spam

Someone who has never written to you does a small automatic check before their first message lands — a proof of work their computer solves in a moment. It's invisible to real senders and instant for anyone you've written to, but it makes bulk spam expensive. You can tune how strict this is in Settings → Screening; people you write to are always let straight through.

Writing mail

Keyboard shortcuts

Press ? anywhere in welp.email for the full list. The essentials:

c Compose
j / k Next / previous
e Archive
r Reply
# Delete (to Trash)
/ Search
⌘↵ Send
? This help

Importing your Gmail

Import (also in the account menu) copies your old mail into welp.email. Everything runs in your browser: each message is converted and sealed to your key on this device, then stored like any other welp.email message — the server only ever receives ciphertext, and your Google sign-in never leaves the browser. Labels come along inside the sealed message; spam and chat histories are skipped; re-running an import is safe.

From Google Takeout — no setup: export at takeout.google.com (Mail, mbox format) and choose the file on the import page.

Straight from Gmail — click Connect Gmail and approve read-only access in the Google window; your Google sign-in and token stay in this browser. While welp.email's Google app is in Google's "testing" tier, an account must be on its tester list to connect — ask us, or use Takeout, which needs nothing.

Self-hosting? Register your own OAuth client (Web application, your origin, Gmail API enabled, consent screen in Testing) and either set KEYMAIL_GOOGLE_CLIENT_ID on the server or paste the client ID on the import page — it stays in your browser.

Sending from a linked Gmail address

Mail you write from a linked Gmail or Google Workspace address goes out through that Google account. Google's permission to send lasts about an hour, so after that welp.email asks Google again in a small window.

Two settings can make it last. The Mac and iPhone apps can keep a long-lived permission in the device's own keychain, where the server never sees it. And in Settings → Accounts and addresses you can let the server keep it for one address, so every device sends without asking. That second one is off unless you turn it on: anyone who took over the server could then send email as that address.

Running your own server? Both need a one-time setup in Google Cloud, described step by step in docs/google-linked-send.md in welp.email's source.

Apps & newsletters

Websites can offer Sign in with welp.email. Allowing one tells it your welp.email address and lets it write to you — into its own Apps or Newsletters tab, never your inbox. An app can never read your mail, see your keys, or send as you, and you can cut any of them off instantly in Settings → Connected apps. Prefer one single inbox? Settings → Where app mail goes folds the tabs away.

Building an app? The developer reference lives at /docs/api.

Custom domains & aliases

A mailbox can answer to more than one address. Bring your own domain and you@yourdomain.com becomes an alias for your welp.email inbox — same keys, same inbox, one place to read. Or give a different name its own separate mailbox on the same domain. Aliases are transparent: mail sealed to either address opens in the same inbox.

The address lives on your domain; the mail is handled at welp.email. Your address reads you@yourdomain.com, but you keep signing in at welp.email and your domain doesn't have to serve — or point at — anything. It works just like an MX record does for ordinary email: one small record delegates your mail, nothing else moves.

DNS: keymail-only (recommended)

One TXT record delegates your domain's keymail to the server that handles it. That's the whole setup — no A record, no certificate, nothing served on your domain, your website and existing email untouched.

; "keymail for this domain is handled at welp.email"
_keymail.yourdomain.com.  TXT   "v=keymail1; host=welp.email"

Then welp.email maps the address to your inbox — as an alias of an existing mailbox, or its own:

keymail alias add you@yourdomain.com <your-mailbox>

Other keymail servers looking up you@yourdomain.com follow the delegation to welp.email, which returns your keys and preserves your domain in the sealed address. Done — you send and receive as you@yourdomain.com without leaving welp.email.

Prefer a branded host? Point host=mail.yourdomain.com and add mail.yourdomain.com CNAME welp.email — welp.email fetches a certificate for that subdomain automatically. Or hand welp.email the whole apex (yourdomain.com A <welp.email IP>) if you want the app served there too. The plain TXT above is the simplest.

DNS: keymail + the email bridge

Add this if you also want to receive ordinary email — messages from Gmail, Outlook, anyone — at your welp.email address. welp.email runs a border MX that turns real email into its front door: an unknown sender is politely refused at the door with a link back to you, so nothing unsealed is accepted by default, and no mail is ever sent on your behalf.

On top of the keymail-only records above, add an MX:

; route ordinary inbound email to the welp.email bridge
yourdomain.com.          MX     10 welp.email.

This is a full mail takeover for the domain — remove any existing MX records first, and know that regular inbound email will now be handled by welp.email's doorbell, not your old provider. A sender who verifies themselves through the doorbell reaches you fully end-to-end sealed; a first-party allowlist (receipts, alerts) is opt-in and clearly marked.

Prefer keymail-only until you've decided you want the world's email pointed here — the bridge is the bigger commitment, and it's a single record to add whenever you're ready.

Self-hosting

The server is one static binary, keymail. Run it on a machine you control and your mail lives there, with the same rule as everywhere else: the server holds public keys and ciphertext, and your private keys stay in your browser. There are two ways to do it.

Your own domain

Point a DNS name at your box, open ports 80 and 443, and start the server. It fetches its own certificate from Let's Encrypt. You are you@km.you.example, and every keymail server in the world can write to you, because keymail servers look up the host in the address and connect to it. There is nothing to register with welp.email or anyone else.

KEYMAIL_HOST=km.you.example KEYMAIL_TLS=1 ./keymail serve -data /var/lib/keymail
./keymail inbox create you -data /var/lib/keymail -host km.you.example

The second command prints a claim link. Open it in a browser and your keys are minted there. That is the whole setup.

A standalone server does not yet have passkey sign-in, the encrypted key vault, or the bridge for ordinary email. Those run on welp.email today and are next to arrive for self-hosters.

Keep your @welp.email address

Your mailbox can move to your box and keep its address. welp.email remembers where it went and does one of two things: forwards everything to you, so nobody has to know, or tells senders where you are so they deliver to you directly. You keep signing in at welp.email either way; it passes your browser's requests through to your machine.

Start the server on your box, telling it that its addresses are written on welp.email:

KEYMAIL_HOST=km.you.example KEYMAIL_HOME=welp.email KEYMAIL_TLS=1 ./keymail serve -data /var/lib/keymail

By default your server tells senders its own name so they can reach you directly. Set KEYMAIL_ADVERTISE_ENDPOINT=0 to stay behind welp.email instead, so your box's name never appears in an answer. Add -bridge-key with a long random secret if you also want ordinary email, from Gmail and the like, handed on to you.

Move the mailbox. Export it from welp.email, then import it on your box. The export is your mailbox exactly as the server held it: ciphertext and public keys, never anything readable.

# on welp.email, signed in: download https://welp.email/api/export as you.tar
# on your box:
./keymail inbox import you.tar -data /var/lib/keymail

Tell welp.email where the mailbox lives now. For the moment that is a request an operator runs for you; a button in Settings is coming. Either way, welp.email only accepts the change if your box already answers for your address with the same keys, so nobody can point your name at a server that does not hold your mailbox.

After the move, welp.email keeps one line about you: your address and the server it lives at. No ciphertext, no keys. A compromised welp.email could misroute your mail; it could not read it.

The full guide, including how to move back, is docs/selfhost.md in the source repository.