[NOTICE] New account registration is currently closed. Existing members are unaffected.
itpromail
home / blog / encryption

Web Key Directory Explained: How Clients Discover Public Keys

Web Key Directory lets mail clients fetch OpenPGP keys over HTTPS from the recipient's own domain, removing most manual key exchange.

July 11, 2026 · Encryption · ITProMail team

Encrypting to someone with OpenPGP requires their public key, and getting that key is the step most people skip. Keyservers solved part of this years ago but brought their own problems, including keys that could not be deleted and spam that flooded the network. Web Key Directory (WKD) takes a different approach. It publishes keys on the recipient's own domain, and a mail client looks them up over HTTPS using nothing more than the address it is sending to.

What WKD does

WKD is specified as an IETF draft and is implemented in GnuPG, Thunderbird and several other tools. A domain owner publishes each user's OpenPGP public key at a predictable URL under /.well-known/openpgpkey/. A client that wants to encrypt to alice@example.com builds that URL from the address, requests it over HTTPS, and imports the key if the response is valid. No account, no key-server query and no manual import step is needed on the sender's side.

How the URL is built

The local part of the address, the bit before the @, is lowercased, hashed with SHA-1 and encoded in z-base-32. That hash becomes the file name. The domain serves the key at one of two locations.

The direct method uses the mail domain's own web server:

https://example.com/.well-known/openpgpkey/hu/ZBASE32_SHA1_OF_LOCALPART?l=alice

The advanced method uses a dedicated subdomain, which lets the mail domain and the web domain differ:

https://openpgpkey.example.com/.well-known/openpgpkey/example.com/hu/ZBASE32_SHA1_OF_LOCALPART?l=alice

The l parameter carries the local part in plain text so the server can respond. Clients usually check the advanced location first and fall back to the direct one. A domain that supports WKD also serves a policy file at /.well-known/openpgpkey/example.com/policy. The file is often empty. Its presence tells clients that the domain has opted in.

Looking up a key by hand

GnuPG can perform the lookup directly:

gpg --auto-key-locate wkd --locate-keys alice@example.com

The companion tool gpg-wks-client can check whether a key is published for an address. Use it when a recipient reports that encryption fails, to see whether the problem is publication or the client.

What WKD proves, and what it does not

WKD authenticates the domain, not the person. The key is trusted because it was served by whoever controls the domain's web server, and that control is protected by DNS and TLS. Anyone who can change the content of that server, or who compromises it, can publish a different key. WKD therefore gives you roughly the same assurance as the domain's HTTPS certificate, and no more. For a contact whose identity matters, compare fingerprints through another channel, as described in the PGP documentation.

The hashing is not a privacy feature. Anyone can compute the same hash for a guessed local part, so a common address such as info or support is trivially discoverable. The hash only prevents casual reading of the URL.

Lookups also leak something. Each lookup is an HTTPS request to the recipient's domain, which reveals the sender's IP address and that the sender is trying to encrypt to that address. Clients may cache results, and a domain operator can log requests. If that matters for a given correspondent, be aware of it before relying on WKD.

Publishing keys for your domain

For a hosted domain, ITProMail publishes WKD entries from the Encryption section of the account menu (Account > Encryption), so a sender using a WKD-aware client can find your key without you sending it first. Check that the key you publish is the one you actually use, and that its expiry date is set to something you will renew. Revoking a key that has been published through WKD means removing or replacing the entry; clients that already cached the key will keep it until they refresh.

Practical checks

  • Confirm the policy file and the hashed key URL both return over HTTPS, with a valid certificate.
  • After changing keys, check the new key is served before telling correspondents to use it.
  • Keep a backup of the private key and a revocation certificate; WKD does not help if the key is lost.
  • Remember that WKD keys are only as trustworthy as the web domain serving them.

WKD removes the most common obstacle to opportunistic OpenPGP use: finding the key. It does not remove the need to verify it when the message matters.

Related reading