Automatic key discovery (WKD)
Your public key is published at your address, so other mail programs can encrypt to you without asking — and when you write outside, we find their key for you.
PGP has always had one awkward step: before you can encrypt to someone, you have to get their public key somehow. The Web Key Directory removes that step in both directions.
- Other people's mail programs can find your key by your address alone, and encrypt to you without you sending them anything.
- When you write to an address outside Private.Ki, we look for a key published at that address. If there is one, your message is end-to-end encrypted automatically — nothing to import, nothing to tick.
Both halves are on by default and there is nothing to configure.
Your key is published at your address
If you have a full account and your keys have been created, your public key is served at a standard address derived from your own:
https://openpgpkey.privateki.net/.well-known/openpgpkey/privateki.net/hu/<hash of your name>
Every OpenPGP-capable mail program knows how to build that URL — GnuPG, Thunderbird, Proton, Mailvelope, FlowCrypt and others. The practical effect: somebody who has only ever seen your address in a signature can write you an encrypted message on the first try.
Anyone who can guess your address learns two things: that an account exists at it, and what its public key is.
That is the point of a public key — it is the thing an account exists to hand out, and it is the same key every signed-in Private.Ki user could already fetch. Whether an address exists was also already answerable, because the sign-up form has to tell people whether a name is taken.
Nothing else leaves. No display name, no sign-up date, no account type, no indication of how much mail you have. The directory host keeps no access log, so there is no record of who looked you up.
Who is not published
These answer the same empty "not found" as a name nobody holds:
- Anonymous accounts. If you started without signing up, nothing about you is in the directory — see Keep your anonymous identity.
- Accounts whose keys have not been created yet, because there is nothing to publish.
- Closed and deactivated accounts, which stop publishing immediately.
There is no per-account switch to opt out while keeping the account open. If that matters to you, say so to support — but be aware that a published public key is what makes incoming mail encryptable at all.
Writing to someone outside Private.Ki
Nothing changes in how you use the composer. Type the address, and:
- If a key is found, the recipient chip gets a lock, Encrypt and Sign stay on, and no warning appears. The message is encrypted on your device exactly as it would be with a key you had imported by hand.
- If no key is found, you get the usual Sending non-encrypted email to: warning and the switches go off — the behaviour described in Encrypted email with external contacts.
Your browser never contacts the recipient's domain. Our server does the lookup, so the other side's provider sees one request from us and learns only that somebody here is writing to that address — not who, and not from which network.
If the published key has expired or is not usable for encryption, your device treats it as if there were none, and the unencrypted-mail warning appears. That decision is made on your device, not on our server.
Which providers this works with
It is per address, not per provider. A domain may run a directory while a particular user there has never published a key — then there is no key for that person, and the warning appears as usual.
Verified by real lookups on 8 October 2026, these domains served a published key:
| Domain | Note |
|---|---|
proton.me |
Keys found for the addresses we tried |
systemli.org |
Key found |
mailfence.com |
Key found |
posteo.de |
Keys served, but the ones we tried had already expired — an expired key counts as no key |
| Self-hosted domains | Anyone running their own mail can publish this way, and many do |
Not reachable this way: Gmail, Outlook, Yahoo and iCloud publish no directory at all. Neither does Tuta (formerly Tutanota): their encryption is their own scheme rather than OpenPGP, so there is no public key to fetch and mail to a Tuta address leaves here unencrypted unless you have imported a key the person uses separately.
For everyone else, the old route still works and still wins: ask for their key and import it, or have them send it as an attachment.
What our server sees
Cannot see
- The content of a message that was encrypted because a key was found — it is encrypted on your device, as always
- Any record of who looked your key up; the directory host writes no access log
Can see
- That it fetched a key for one outside address, cached briefly so the same address is not fetched again
- Your public key — it is public by design
The details
This is the OpenPGP Web Key Directory (draft-koch-openpgp-webkey-service). The directory name is z-base-32 of the SHA-1 of the lowercased local part of the address; ?l= is accepted and ignored. A hit returns the binary key as application/octet-stream with Cache-Control: public, max-age=3600; .../policy answers an empty 200 to say the domain takes part; every other path on the host is a 404, plain HTTP is redirected to HTTPS, and the host sends HSTS and writes no access log.
Published are active, non-staff accounts that have keys — and any additional receiving address pointing at such an account, which answers with the owner's key. A tag added to an address (see Tagged addresses) is not a directory entry of its own.
On the sending side the server tries the advanced method first and then the direct method, over HTTPS only, with a five-second total budget, a cap on the response size, every host checked to be a public address before it is contacted, and redirects re-checked the same way. The answer is accepted only if it is a public key whose user ID names the address that was asked for. Results are cached for 24 hours, a miss for one hour, and nothing is written to a database. A hosted address is refused outright — those keys come from our own directory. Your device then pins the key on first use and judges its validity itself, exactly as it does with an imported key.
Common questions
Do I have to do anything to publish my key?
No. It happens when your keys are created and stays current if your key ever changes.
Does this replace importing keys by hand?
Only when the other side publishes. An imported key is still used in preference and is still the answer for anyone whose provider has no directory.
Could someone put a fake key at my address?
Not at your address — the directory is served from our host, under our certificate. Faking another domain's directory would need a certificate for that domain, and the result would still be just a key, shown as an external key and pinned on first use, which is the same exposure as importing a wrong key by hand.
Someone's provider is in the list but no key is found
Then that person has not published one. It is decided per address, not per provider.
Can I see which key was used?
Yes — the lock on the recipient chip in the composer, and the icons on the sent message. See Check the encryption status of a message.