Cryptography

Email transport is a fundamentally insecure system; messages can be easily intercepted, altered, forged and snooped without much evidence that this has happened. One way of preventing interception and eavesdropping is to encrypt the network connection.

That part is now solved and mutt does the right thing without being asked. Use imaps , pops and smtps rather than their unencrypted equivalents, as described in the mail accounts section; mutt’s ssl_force_tls setting, on by default, means it will refuse to talk to a remote server in the clear even if you get the URL wrong.

RFC 8314 is the standard that made this the default expectation. If a provider still wants you to connect in the clear, find another provider.

If you keep your mail on a machine you can reach by ssh, OpenSSH lets you run mutt on that machine from anywhere, which sidesteps the question entirely.

End-to-end encryption and signing

The problem with network approaches to security is that you have no control over mail once it passes outside your own connection - it sits in plain text on every server it touches. To gain some end-to-end control you need to encrypt and/or sign the body of the email in your mail user agent - mutt.

This guide isn’t going to discuss why you might want to use cryptography. A good place to start reading on the subject is Phil Zimmermann’s text “Why I Wrote PGP”.

There are two systems you can use with mutt for this job.

OpenPGP

GnuPG is the implementation everybody uses. The original commercial PGP is history; OpenPGP is the open standard it became, most recently specified in RFC 9580 which supersedes RFC 4880.

Mutt has supported this for as long as it has existed. Modern builds talk to GnuPG through the GPGME library rather than driving the command-line tool, which is both more reliable and less work to configure:

set crypt_use_gpgme = yes

There is a ready-made configuration in contrib/gpg.rc , usually installed by your distribution. Source it from your muttrc rather than copying it:

source /usr/share/doc/mutt/gpg.rc

S/MIME

S/MIME is an alternative and incompatible system, differing mainly in that it depends on a public key infrastructure of certificate authorities rather than the OpenPGP concept of a web of trust. Mutt has supported it for many years, and it is the system you are most likely to meet inside a large organisation, because certificates can be issued centrally and it is supported out of the box by Outlook and by Apple Mail. There is a sample configuration to source in the same place:

source /usr/share/doc/mutt/smime.rc

Mutt ships an smime_keys utility for importing certificates into the keystore it expects.

Making it less painful

Two settings are worth knowing about before you start signing everything.

Opportunistic encryption turns encryption on automatically whenever mutt has a usable key for every recipient, and off again when it doesn’t:

set crypt_opportunistic_encrypt = yes

Autocrypt goes further and handles key exchange for you: mutt advertises your key in a header on outgoing mail, remembers the keys it sees in incoming mail, and encrypts when both sides have advertised. It needs no keyservers, no fingerprint checking and no explanation to the person you are writing to. It is a deliberate trade of strong authentication for mail that is routinely encrypted rather than exceptionally so. Mutt has supported it since version 1.13, but it has to be enabled at build time with --enable-autocrypt and plenty of distributions don’t bother. There is no flag for it in mutt -v ; ask for the variable instead:

mutt -Q autocrypt

A build that has it prints a value. A build that doesn’t prints autocrypt: unknown variable , in which case try neomutt, which is more often compiled with it. Once you have a build that supports it, set autocrypt = yes and mutt will walk you through the rest on next start. The details are in the autocrypt section of the manual.

Finding people’s keys

The old habit of pulling keys from a public keyserver largely stopped working when the SKS keyserver network collapsed in 2019 under the weight of certificate flooding. Two things replaced it:

• keys.openpgp.org , which only publishes an address after the owner has confirmed it.
• Web Key Directory , which serves a key over https from the address’s own domain. GnuPG will find these automatically, which makes it the closest thing to a working answer.

Guides

The official PGP notes are terse but authoritative, and the encryption and signing chapter of the manual covers both systems. There is a longer step-by-step mutt gpg guide if you want one, though it predates GPGME.

Problems with other people’s mailers

Mutt creates PGP/MIME signed and encrypted messages, the format specified by RFC 3156. This is the right format and it is now widely supported, but you will still meet mailers that show your message body as an unopenable attachment. You need to decide whether the advantages of signing everything outweigh the cost of explaining it. Many people sign selectively and encrypt only when it matters.

Be aware also of Efail, a family of attacks published in 2018 that used HTML mail to exfiltrate decrypted plaintext by tricking the mail client into fetching a remote URL. Mutt was much less exposed than graphical mailers because it does not render HTML or fetch remote content by default. Keep it that way: do not configure an auto_view rule that hands encrypted mail to a browser.

Last updated 31 August 2026.