Using keys.openpgp.org: upload, verify, search and remove keys

Updated November 2026

keys.openpgp.org is a public keyserver that treats your name and email address as personal data. It hands out the technical part of any key to anyone, but it only publishes an email address after the owner clicks a confirmation link. For GnuPG, set keyserver hkps://keys.openpgp.org and use the upload page or one curl command to publish your key.

How it differs from older keyservers

Old keyservers such as the pgp.net servers published whatever was uploaded and copied it to the other servers. keys.openpgp.org launched on June 12, 2019 as a community project, and it splits each key into two parts:

Non-identity data: the public key material, subkeys, self-signatures, expiry dates and revocations. Stored and handed out freely, as long as the data passes a cryptographic check.
Identity data: the user IDs, meaning name and email address. Published only with the owner's consent, given by confirming the address.

Some other rules follow from that:

Each email address belongs to at most one key. If you confirm the address for a new key, it disappears from the old one, so a search by address returns one key, not a list.
Search is by exact address only. You cannot search for part of an address, such as everyone at one domain, or by name.
User IDs without an email address, and photo IDs, are removed on upload and never stored.
Third-party signatures (other people's certifications of your key, the basis of the web of trust) are not published by default, because anyone could use them to attach junk to your key. The exception is certifications that you, the key holder, mark as "attested" with your own software.
Uploads through the HKP interface (/pks/add, used by gpg --send-keys) are limited to 1 MiB.
The service is not part of the old SKS pool and, as of November 2026, is not federated: other people cannot run servers that join it.

The server runs the Hagrid software, which is built on Sequoia-PGP. Since 2023 the service has had a written constitution and an elected board.

Set it as your keyserver

Add this line to ~/.gnupg/dirmngr.conf (the GnuPG manual prefers it there; the keys.openpgp.org guide also accepts gpg.conf), then reload:

keyserver hkps://keys.openpgp.org

gpgconf --reload dirmngr

Debian's GnuPG already uses it by default. Thunderbird has used it by default since version 78, GPG Suite for macOS since 2019.1, OpenKeychain for Android since 5.3 and Sequoia's sq since 0.32.0. If Tor is installed, you can also reach the service as an onion service; the address is on the usage page linked in the Sources.

Upload and confirm your key

The quickest way is to pipe your public key to the server. It prints a link to the confirmation page:

gpg --export alice@example.org | curl -T - https://keys.openpgp.org

Key successfully uploaded. Proceed with verification here:
https://keys.openpgp.org/upload/…

Open the link and ask for a confirmation email for each address you want listed. Click the link in each email. Only then can people find the key by that address.

Or export the key to a file and choose it on the upload page at https://keys.openpgp.org/upload:

gpg --export alice@example.org > alice.pub

gpg --send-keys <FINGERPRINT> also uploads, but it cannot start the email confirmation. Use it to send updates (a new expiry date, a new subkey, a revocation) after the addresses are confirmed. Export only your public key; never upload the output of --export-secret-keys.

Why not encrypted confirmation mails? The service says that it would make little difference, because an attacker gains nothing from uploading a key they cannot use. It sends confirmation mails over secured connections where the receiving provider supports MTA-STS.

Find someone's key

By email address (the address must match exactly and must have been confirmed):

gpg --auto-key-locate keyserver --locate-keys bob@example.org

By fingerprint or long key ID, which also finds keys whose addresses were never confirmed:

gpg --keyserver hkps://keys.openpgp.org --recv-keys <FINGERPRINT>

Then check the fingerprint against one the owner gave you:

gpg --fingerprint bob@example.org

Short 8-digit key IDs are rejected. A request such as search=0x93298290 returns HTTP 400 (tested November 2026).

Without gpg, use the search box on the front page, or fetch keys straight over HTTPS with the server's own "VKS" interface. Hexadecimal digits must be uppercase with no 0x:

curl -fsSL https://keys.openpgp.org/vks/v1/by-fingerprint/<FINGERPRINT>
curl -fsSL https://keys.openpgp.org/vks/v1/by-keyid/<16-HEX-KEY-ID>
curl -fsSL https://keys.openpgp.org/vks/v1/by-email/bob%40example.org

Each returns an ASCII-armored key with the content type application/pgp-keys, or HTTP 404 if there is none. The usual /pks/lookup interface works too; see HKP and /pks/lookup.

Keep keys up to date

Run this now and then, or from a timer, to fetch new subkeys, new expiry dates and revocations for every key you hold:

gpg --refresh-keys

Keep in mind the rate limits: lookups by fingerprint or key ID are limited to five per second (with a burst of 1,000), and lookups by email address to one per minute (with a burst of 50). Over the limit, the server answers HTTP 429.

The "no user ID" problem

If a key has no confirmed address, the server sends it without any user ID. Unpatched GnuPG refuses such a key and prints:

gpg: key <KEYID>: no user ID

That means it also ignores a revocation or a new expiry date sent that way. In June 2019 the keys.openpgp.org team wrote a patch, which Debian, Fedora, NixOS and GPG Suite adopted. Upstream GnuPG declined it in March 2020 (bug T4393). To check your GnuPG, import the service's test key, then refresh it by fingerprint:

curl https://keys.openpgp.org/assets/uid-test.pub.asc | gpg --import
gpg --keyserver hkps://keys.openpgp.org --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E

A patched GnuPG says not changed; an unpatched one says no user ID. Debian 13's GnuPG 2.4.7 passed this test in November 2026. If yours fails, confirm your own address on the server so that your contacts receive your updates, or refresh the key from another source.

Remove your address or key

Unlist an address: go to https://keys.openpgp.org/manage and enter the address. You get an email with a link where you can remove any of your addresses from search.
Delete the key data: email the support address given on the privacy page. Anyone who has your public key can upload it again; if you object, ask them to block it.
Revoked user IDs: if you revoke a user ID, the server stops listing that identity. It does not hand out the revocation itself, because that would reveal the address.

The privacy policy says requests are logged for 30 days with IP addresses anonymized, and that address data is never given out as a bulk dump.

WKD for your own domain

If you own a mail domain, you can let keys.openpgp.org serve your Web Key Directory. Add a DNS record so that openpgpkey.example.org is a CNAME for wkd.keys.openpgp.org. Confirmed addresses at that domain then become available by WKD. Test with:

curl 'https://wkd.keys.openpgp.org/status/?domain=openpgpkey.example.org'
gpg --locate-keys --auto-key-locate clear,nodefault,wkd alice@example.org

The Web Key Directory page explains other ways to publish.

Common mistakes

Uploading with --send-keys and waiting. No confirmation email ever comes that way. Use the upload page or the curl -T command.
Expecting signatures from a key-signing party to show. They are stripped unless you attest them. GnuPG 2.4's manual documents no command to attest certifications.
Old dirmngr.conf lines. Remove hkp-cacert … sks-keyservers.netCA.pem; it breaks the normal certificate check.
Trusting a search result blindly. A confirmed address proves that someone could read mail at that address. It does not prove who they are. Compare fingerprints.