A PGP private key is the only thing that can decrypt mail encrypted to its public half, and nobody else can recreate it. A mail provider cannot recover it, and a provider's encryption at rest does not give you access to PGP-encrypted messages either, because that protection is server-side and not tied to your key. If the private key is lost, the messages encrypted to it stay unreadable. Planning ahead is the only realistic defense, and it has three parts: a revocation certificate, an encrypted backup, and a restore test.
What is lost and what is not
Losing a private key affects three things: decryption of past and future messages sent to that key, the ability to sign new messages with it, and the ability to prove that a signature was made by it. The public key can usually be recovered from a key server, a Web Key Directory or a correspondent, so the public half is rarely the problem. The private half, and its passphrase, is the one that must be protected.
Create a revocation certificate at key creation
A revocation certificate is a signed statement that tells others a key should no longer be used. Create it when you generate the key, not when you need it. With GnuPG, the command is:
gpg --output revoke-KEYID.asc --gen-revoke KEYIDReplace KEYID with your key's fingerprint or identifier. GnuPG asks for a reason. Choose "key compromised", "key superseded" or "key no longer used" honestly, because the reason is recorded in the certificate. Store the certificate offline, away from the key backup, for example on a separate encrypted drive or on paper in a secure place. Anyone who gets a copy can revoke the key, so it should not be left in a shared folder.
Back up the private key
Export the private key and its subkeys to an armored file, and encrypt the backup with a strong passphrase or keep it inside an encrypted container. The commands are:
gpg --export-secret-keys --armor KEYID > private-KEYID.asc
gpg --export --armor KEYID > public-KEYID.asc
gpg --export-ownertrust > ownertrust.txtThe private export contains the secret key material, so treat it as sensitive. Keep the key's passphrase in a password manager or in sealed paper, separate from the backup itself. A backup without its passphrase is only useful if the passphrase survives too. Keep at least two copies in different physical locations.
Test the restore before you need it
A backup that has never been restored is a hope, not a plan. Once a year, or after any key change, restore the backup onto a clean machine or a virtual machine and check it works:
gpg --import private-KEYID.asc
gpg --import ownertrust.txt
gpg --list-secret-keys
Then decrypt a test message that was encrypted to the key. If you cannot decrypt it, you have found a problem while it is still cheap to fix. Remove the test material from the machine afterwards.
Using the revocation certificate
If the key is lost, the private half is gone and no revocation is needed for secrecy, but correspondents should still stop encrypting to it. If the key may be compromised, revoke it promptly:
gpg --import revoke-KEYID.ascImporting the certificate marks the key as revoked in your local keyring. Others only learn about the revocation when they obtain the updated key, so you must publish it where your correspondents look. On ITProMail, PGP keys and Web Key Directory publication are managed under Account > Encryption, and the PGP guide describes that setup. Where the publication method does not carry revocations, tell your correspondents directly that the old key should no longer be used.
Plan a replacement key
A lost or revoked key means a new one. Generate the replacement before the old one is needed, so that you can exchange the new public key with the people who matter. Keep the old public key available, because you may still need it to verify old signatures, even though you no longer use it to encrypt. Subkeys with an expiry date are a useful tool here. They allow day-to-day encryption subkeys to be rotated while the primary key stays constant, which limits how much a single compromise can expose.
Write a key inventory
Keep a short document that lists each key's fingerprint, creation date, expiry date, where the backup and revocation certificate are stored, where the passphrase is recorded, and who should be told if the key changes. The inventory should live somewhere other than the key backup. Review it when you rotate keys, and when someone who knows the arrangements leaves.
Where to go next
Key recovery is part of a broader PGP practice, which includes verification, publication and daily use. The practical overview is in PGP in practice. The way encrypted subjects behave with keys in place is covered in protected headers and encrypted subjects. A small team's wider checklist, including key and recovery items, is in a mail security checklist for small teams.