How to Encrypt an Email with PGP, Start to Finish

Published 10 October 2026 · 6 min read

Most guides to encrypted email stop at "click the encrypt button." That is the easy half. The parts that decide whether the encryption is worth anything are the ones nobody photographs: which key you encrypt to, what the subject line reveals, and what your own copy of the message tells an attacker who later owns your laptop. This is the full sequence, including the parts people skip.

Step 1: Get the right public key

Encryption in OpenPGP is not "password protects message." You encrypt to a specific key. That key has a fingerprint, a long hexadecimal string that looks like 4F2A 83B1 9C05 22D6 EE7F 01B3 6A29 F4C8 92D1 55AA. The encryption software will happily encrypt to any key you hand it, including a key an attacker substituted for your correspondent's real one. The software cannot tell the difference. Only the fingerprint, compared over a different channel, can.

So step one is not "download the key." It is: obtain the key, then verify the fingerprint with the person, by phone call, video call, or any channel other than the one that delivered the key. If the key came from a keyserver or an email footer, the same channel that delivered it can deliver a fake. We cover the substitution problem in detail in what a PGP signature actually proves.

Step 2: Import and check the key

On a desktop client this looks like opening the .asc file your correspondent sent. On the command line it is:

gpg --import contact.asc
gpg --fingerprint contact@example.com

Read the fingerprint back to the person character by character. People do skip letters. Once it matches, set the owner trust or at least sign the key locally, so your client marks it as verified and will not silently fall back to a different key later.

Step 3: Compose, and mind the metadata

Here is the part most tutorials never mention. PGP encrypts the body of a message. It does not encrypt the subject line. It does not encrypt your address, the recipient's address, the timestamp, the receiving mail servers in the headers, or the attachment filenames. Anyone on the wire, and anyone running the mail server, sees:

Who sent mail to whom, and when
The subject line, word for word
How large the message is
Every server hop the message took

A subject line like "Q3 numbers, see attached" leaks the topic while the body sits there uselessly encrypted. Write subjects that carry no information: "Message 14" works. So does "Hello." If the subject matters, say so in the encrypted body.

Step 4: Encrypt

In a client with PGP support, compose the message, attach the files, and hit encrypt. There is one setting worth checking first: you want PGP/MIME rather than inline PGP where the choice exists. Inline PGP, the old style that pastes a text block into the message body, cannot encrypt attachments at all, mangles non-English text, and breaks on anything but plain messages. PGP/MIME treats the whole message, attachments included, as one encrypted unit.

On the command line the equivalent operation is:

gpg --encrypt --recipient contact@example.com --armor draft.txt

The --armor flag produces the text block you can paste into any mail client. Without it you get a binary file, which some webmail interfaces handle badly.

One decision most people get wrong: encrypt to yourself as well. Add --recipient you@example.com, or tick "encrypt to my own key" in the client settings. If you do not, the copy in your own sent folder is plaintext. Your correspondent's reply chain is protected, and your entire side of the conversation is sitting in your mailbox readable by anyone who compromises the account or the machine. Encrypting to your own key costs nothing and closes that hole.

Step 5: Sign before you send

Encrypting protects the content. Signing proves the content came from your key and arrived unmodified. Both halves take one click each, and there is no good reason to do one without the other in a mail context. Sign, then encrypt (the client does the ordering for you), then send.

Step 6: Handle the reply

When the reply arrives, your client decrypts it using your private key. Nothing arrives that asks your correspondent to "type in the shared password," and if a reply asks you to install a plugin or visit a link to "read an encrypted message," that is not PGP. That is either a legacy enterprise gateway or a phish. Real PGP mail decrypts inside the client with no web visit at all.

What this does not protect

Be honest about the boundary. Encrypted mail protects message content in transit and at rest on the mail server. It does nothing about a compromised endpoint. If the machine holding your private key is infected, the attacker reads your mail by keylogging the composition window, not by breaking the cryptography. That is why key material belongs on a hardware token where the private key cannot be copied off the machine, a move we describe in moving your PGP key to a hardware token.

It also does not hide the fact that you and your correspondent are exchanging encrypted mail. A pattern of encrypted traffic between two named parties is itself information. For hiding relationships rather than content, encrypted mail is the wrong tool, and a messaging protocol with metadata protection is the right one.

Key hygiene on both ends

The private key that does the decryption is a single file with no redundancy. Lose it and every message encrypted to you is gone forever, including old mail you still want to read. The fix is boring and mandatory: export an encrypted backup of the secret key, store it somewhere that is not the laptop, and test that the backup restores. The full procedure, including what a paper backup does and does not protect against, is in our guide on backing up your PGP key.

That is the whole sequence: verify the fingerprint out of band, mind the subject line, encrypt to your own key too, sign, and keep the key material where a stolen laptop cannot export it. None of it is hard. All of it is skippable, which is exactly how people end up with encrypted mail that protects nothing.