Most email still travels between servers in plaintext, and most people never set up OpenPGP because the key exchange is the hard part. Autocrypt is a specification that tries to remove that step. Each participating mail client attaches its public key to outgoing messages, and recipients store the keys they receive. Once a key is known, the client can encrypt replies automatically, without the user doing anything.
How the header works
An Autocrypt-enabled message carries a header along these lines:
Autocrypt: addr=alice@example.com; prefer-encrypt=mutual; keydata=mDMEZ...
The addr field names the address the key belongs to. keydata is the base64-encoded OpenPGP public key, normally a minimal form containing the certificate and its user ID. prefer-encrypt=mutual signals that the sender wants encryption whenever both sides have keys. Without that attribute the sender has no preference. The receiving client parses the header, checks that addr matches the From address, and stores the key against that contact. A later message from the same sender updates the stored key if the header changes.
What opportunistic encryption means
Opportunistic encryption means encrypting whenever the recipient's key is known and falling back to plaintext otherwise. It is a sensible default for mail that would otherwise travel unprotected. It protects the body and attachments from anyone who can read the mail store, or who intercepts the message in transit, without the key. It does nothing about metadata. Sender, recipient, subject, timing and size remain visible unless the client uses protected headers, and protected headers are not universally implemented.
The tradeoffs
No verification on first contact
In practice Autocrypt behaves like trust-on-first-use. The first key received from an address is accepted without any check that it belongs to the person behind that address. Someone who controls the path, or who can send mail from the address, can substitute their own key. Clients that warn when a key changes help, but a user who dismisses the warning is exposed. Real assurance requires comparing fingerprints out of band, which is exactly the work Autocrypt was designed to avoid. The PGP documentation covers how keys are checked.
Key changes are ambiguous
A changed key can mean a legitimate reinstall, a new device, or an impersonation attempt, and the client cannot tell which. The spec's rules for accepting a replacement key take timestamps and the sender's previous encryption preference into account. That narrows the window for downgrade attacks but does not remove the ambiguity.
Size and repetition
Each message carries the sender's key. Keys with several subkeys and signatures can run to several kilobytes, which adds to every message and to the mailbox. Clients that already hold the key still see it repeated.
Partial client support
Autocrypt is implemented by several clients, including Thunderbird through its built-in OpenPGP support and Delta Chat, but not by every client. Encryption only happens when both sides run compatible software. The practical result is a mix of encrypted and plaintext messages that the user may not notice.
Setup messages
Autocrypt also defines an Autocrypt-Setup-Message, which carries the private key protected by a passphrase the user types in. It moves a key to a new device without copying key files by hand. The passphrase is the only thing protecting the key in transit, so a weak passphrase turns the setup message into a weak point. Use a strong passphrase, and delete the setup message from mail stores once the transfer is complete.
Practical guidance
- Treat Autocrypt encryption as protection against passive interception and mail-store exposure, not as proof of who sent a message.
- Verify fingerprints for contacts whose identity matters, and record that you did.
- Read key-change warnings instead of dismissing them.
- Use a strong passphrase for setup messages and remove them afterwards.
- Assume the subject line and participant list are visible, even in encrypted mail.
Autocrypt is a reasonable step up from plaintext for everyday correspondence. It is not a substitute for verified keys when a message matters. Think of it as a convenience layer with its own trust model, and decide per contact how much that model is worth to you.