S/MIME и PGP: два подхода к шифрованию email

SPF, DKIM и DMARC подтверждают, что письмо отправил тот, кто указан в поле From. Но они не скрывают содержимое. Любой сервер на маршруте может прочитать тело письма, если захочет. Шифрование решает другую задачу: сделать текст нечитаемым для всех, кроме отправителя и получателя. Для этого существуют два стандарта - S/MIME и PGP. Оба живут с 90-х, оба работают, но устроены по-разному.

What email encryption actually protects

SMTP was designed in 1982. The protocol sends messages in plain text. TLS between mail servers (opportunistic STARTTLS or MTA-STS) encrypts the connection, but not the message itself. Once the message lands on the receiving server, it sits there unencrypted. The server admin, a court order, or a breach can expose every word.

End-to-end encryption changes the model. The message is encrypted on the sender’s device and decrypted only on the recipient’s device. The mail server stores ciphertext. Even if somebody intercepts the message in transit or dumps the mailbox database, they get unreadable bytes.

Two standards have survived since the 1990s: S/MIME (Secure / Multipurpose Internet Mail Extensions) and PGP (Pretty Good Privacy), which is now most commonly used through its open specification OpenPGP. They solve the same problem - encrypting and signing email - but differ in how they handle trust and key distribution.

S/MIME: certificates from a central authority

S/MIME relies on X.509 certificates, the same PKI infrastructure used for HTTPS. A Certificate Authority (CA) verifies your identity and issues a certificate that binds your email address to a public key. The private key stays on your device.

The flow for sending an encrypted message:

1. You obtain the recipient’s S/MIME certificate (usually received automatically when they send you a signed message).
2. Your mail client encrypts the body and attachments using the recipient’s public key.
3. Only the recipient’s private key can decrypt the message.

For signing (proving that the message was not altered and really came from you), the direction reverses: you sign with your private key, anyone with your certificate can verify.

Where to get an S/MIME certificate

As of 2026, free S/MIME certificates have largely disappeared. Actalis still offers free ones for personal use (email validation only, 1-year validity). For organizations, DigiCert, Sectigo, and GlobalSign sell S/MIME certificates starting around $20-40/year per address. Enterprise plans with centralized management cost more but simplify deployment across hundreds of mailboxes.

Client support

This is the main strength of S/MIME. Outlook (desktop and web), Apple Mail, iOS Mail, and Thunderbird support it natively. No plugins needed. Gmail supports S/MIME too, but only for Google Workspace accounts on Business Plus, Enterprise, or Education plans - it does not work with free Gmail. Once the certificate is installed, signing and encrypting happen through the standard compose window, usually with a lock icon or a ribbon badge.

Limitations

• Certificate cost. For a team of 50 people, $30/year per person adds up. Budget is not enormous, but it is not zero either.
• Key escrow risk. Some CAs or enterprise deployments archive private keys. If the archive is compromised, past messages can be decrypted. Forward secrecy is not part of the S/MIME standard.
• Certificate expiration. Certificates expire (usually after 1-3 years). When they do, old messages signed with them may show warnings, and encrypting to an expired certificate fails. Renewal is a manual process unless you have an MDM or certificate lifecycle tool.
• Centralized trust. If a CA is compromised or issues a fraudulent certificate, the whole chain breaks. This has happened before with HTTPS CAs, and the S/MIME ecosystem is smaller and less audited.

PGP / OpenPGP: decentralized trust

Phil Zimmermann released PGP in 1991. The core idea: no central authority. You generate a key pair yourself. You publish the public key (on a keyserver, your website, or directly to contacts). Trust is established through a “web of trust” - other people sign your key to vouch for its authenticity - or through direct verification (comparing fingerprints over a phone call, for example).

The modern open specification is called OpenPGP (RFC 9580, updated in 2024). GnuPG (GPG) is the most common free implementation. Other implementations include Sequoia PGP and the OpenPGP.js library used by Proton Mail.

How encryption works

Mechanically, PGP encryption is similar to S/MIME: a symmetric session key encrypts the message body, and the session key itself is encrypted with the recipient’s public key. Signing uses the sender’s private key. The difference is not in the cryptography but in key management.

Key distribution: the hard part

S/MIME piggybacks on the CA infrastructure that already exists for the web. PGP has no such luxury. Getting someone’s public key reliably is the central challenge. The classic SKS keyserver network had problems: no identity verification, certificate flooding attacks, and GDPR conflicts. Modern alternatives are better: keys.openpgp.org requires email verification before publishing, and WKD (Web Key Directory) lets domains serve keys over HTTPS at a well-known path.

WKD lookup example for alice@example.com:

GET https://openpgpkey.example.com/.well-known/openpgpkey/example.com/hu/<hash>
# or direct method:
GET https://example.com/.well-known/openpgpkey/hu/<hash>

If your organization controls its DNS and web server, setting up WKD takes about an hour. After that, any OpenPGP-compatible client can fetch your team’s keys automatically, without manual import.

Client support

This is PGP’s weakness. Outlook does not support OpenPGP natively. Apple Mail does not either. Thunderbird is the major desktop client with built-in OpenPGP support (since version 78). For other clients, you need plugins: Gpg4win with GpgOL for Outlook on Windows, GPGMail for Apple Mail (paid, from GPGTools). On mobile, options are limited: OpenKeychain on Android works with K-9 Mail / Thunderbird for Android; on iOS, PGP support is sparse.

Web-based solutions like Proton Mail and Mailvelope (a browser extension for Gmail and others) hide the complexity behind a simpler interface. Proton Mail, in particular, makes PGP transparent: users encrypt and decrypt without ever touching a key management dialog. But this only works between Proton users or when the external recipient has published an OpenPGP key.

S/MIME vs. PGP: direct comparison

Neither protocol is strictly better. S/MIME wins on ease of deployment in corporate environments where Outlook or Apple Mail is standard. PGP wins on cost, decentralization, and flexibility for technical users who distrust centralized CAs.

Когда шифрование действительно нужно

Большинству маркетинговых рассылок шифрование не нужно. Вы не отправляете секретные данные в промо-письме о скидке 15%. Шифрование необходимо, когда содержимое письма имеет ценность для третьих лиц или когда утечка может нанести ущерб.

Конкретные сценарии, где шифрование оправдано:

• Персональные данные по ФЗ-152 / GDPR. Если вы передаёте сотруднику или партнёру файл с паспортными данными, медицинской информацией или финансовыми записями, закон требует принять меры защиты. Шифрование email - одна из них.
• Юридическая переписка. Адвокатская тайна не защищена, если письмо может прочитать администратор почтового сервера. Многие юридические фирмы в США и Европе перешли на S/MIME для корпоративной почты.
• Финансовые отчёты. Квартальные результаты до публичного объявления, M&A-документы, внутренние прогнозы - всё, что влияет на биржевую стоимость.
• Журналистика и активизм. Защита источников. Whistleblower-каналы многих СМИ используют PGP: The Guardian, The New York Times, ProPublica публикуют свои PGP-ключи для защищённой связи.
• Внутренние коммуникации в оборонке и госсекторе. Здесь шифрование часто регулируется отраслевыми стандартами, а не выбором конкретного сотрудника.

Когда шифрование избыточно

Маркетинговая рассылка - открытое сообщение. Вы хотите, чтобы его прочитали. Шифрование только мешает: получатель без соответствующего ключа увидит нечитаемый blob вместо письма. Массовая отправка зашифрованных email технически возможна (шифровать каждое письмо отдельным ключом каждого получателя), но ни один ESP этого не поддерживает, и смысла в этом нет.

Транзакционные письма - чеки, подтверждения регистрации, сброс пароля - тоже обычно не шифруют. TLS между серверами обеспечивает защиту в транзите. MTA-STS делает TLS принудительным, а не опциональным. Для большинства транзакционных сценариев этого достаточно. Если вы хотите убедиться, что TLS используется, настройте MTA-STS для своего домена и мониторьте отчёты TLS-RPT.

Практическая настройка: S/MIME в Outlook

Для организации, где основной клиент - Outlook, S/MIME - наименее болезненный путь. Вот что нужно сделать:

1. Купить S/MIME сертификаты у CA (Sectigo, DigiCert). Для организации - Organization Validated (OV) сертификат. Он показывает имя компании в подписи.
2. Экспортировать сертификат в формате .pfx (PKCS#12). Файл содержит и публичный сертификат, и приватный ключ, защищённый паролем.
3. Импортировать .pfx в Windows Certificate Store или развернуть через Active Directory / Intune для централизованного управления.
4. В Outlook: File → Options → Trust Center → Email Security → выбрать сертификат для подписи и шифрования.
5. Отправить подписанное письмо коллеге. Коллега автоматически получит ваш публичный сертификат. Теперь он может шифровать письма вам.

В Microsoft 365 Admin Center можно включить S/MIME для всей организации, загрузить корневые и промежуточные сертификаты CA, и задать политику: подписывать все исходящие по умолчанию, шифровать при наличии сертификата получателя.

Практическая настройка: PGP в Thunderbird

Thunderbird - единственный крупный клиент с встроенной поддержкой OpenPGP без плагинов. Настройка:

1. Account Settings → End-To-End Encryption → Add Key. Можно сгенерировать новый или импортировать существующий.
2. Рекомендуемые параметры: Ed25519 для подписи, Curve25519 для шифрования. Если нужна совместимость со старыми системами - RSA 4096.
3. Опубликовать публичный ключ: экспортировать как .asc файл и загрузить на keys.openpgp.org. Или настроить WKD на своём домене.
4. Для отправки зашифрованного письма: импортировать публичный ключ получателя. Thunderbird умеет автоматически искать ключи через WKD и keys.openpgp.org.

# Генерация ключа через GPG CLI (альтернатива)
gpg --quick-gen-key "Ivan Petrov <ivan@example.com>" ed25519 sign 2y
gpg --quick-add-key <fingerprint> cv25519 encrypt 2y

# Экспорт публичного ключа
gpg --armor --export ivan@example.com > ivan-public.asc

# Настройка WKD (прямой метод)
# Положить файл в:
# https://example.com/.well-known/openpgpkey/hu/<sha1-hash-of-localpart>

Типичные ошибки при внедрении

• Нет бэкапа приватного ключа. Сотрудник переустановил ОС - ключ потерян. Все зашифрованные письма, которые он получил, больше не читаются. Никогда. Для S/MIME: экспортируйте .pfx и храните в защищённом месте. Для PGP: экспортируйте приватный ключ (gpg --export-secret-keys) и положите на зашифрованный носитель.
• Шифрование без подписи. Шифрование скрывает содержимое, но не подтверждает отправителя. Без подписи получатель не может быть уверен, что зашифрованное письмо пришло именно от вас. Включайте подпись всегда.
• Хранение ключей на почтовом сервере. Некоторые решения предлагают серверное шифрование: ключ хранится на сервере, а шифрование/дешифрование происходит там же. Это не end-to-end. Компрометация сервера раскрывает всё. Ключи должны быть на устройстве пользователя.
• Забыли про тему письма. Ни S/MIME, ни PGP не шифруют Subject. Тема письма передаётся открытым текстом. Если в теме написано «Конфиденциально: сделка по поглощению X», шифрование тела не поможет. Держите тему нейтральной.
• Не проверили, что получатель может расшифровать. Отправили зашифрованное письмо человеку, у которого нет настроенного ключа. Он видит вложение smime.p7m и не понимает, что с ним делать. Перед внедрением убедитесь, что обе стороны готовы.

Шифрование и аутентификация - разные задачи

Путаница между ними - частое явление. SPF, DKIM и DMARC - это аутентификация: они подтверждают, что письмо пришло от легитимного отправителя, и что оно не было подменено на маршруте. Но они не скрывают содержимое. S/MIME и PGP - это шифрование и подпись на уровне сообщения: содержимое закрыто от посторонних, а подпись подтверждает авторство конкретного человека (не домена, а именно владельца ключа).

Для массовых рассылок вам нужна аутентификация: SPF, DKIM, DMARC, возможно BIMI. Для конфиденциальной переписки один на один - шифрование. Это не взаимоисключающие вещи: зашифрованное PGP-письмо тоже проходит SPF/DKIM-проверки (они работают на уровне заголовков и конверта, а не тела).

Альтернативы: когда email - не лучший канал

Если настройка S/MIME или PGP кажется слишком тяжёлой для вашей задачи, есть более простые варианты. Защищённый портал (отправляете ссылку на документ за авторизацией), мессенджеры с E2EE (Signal), защищённые файлообменники. Для разовой передачи конфиденциального документа портальный подход проще, чем развёртывание PKI.

Но если конфиденциальная переписка - регулярная часть вашей работы (юриспруденция, медицина, финансы), вложение в S/MIME или PGP окупается. Один раз настроить - и каждое письмо защищено автоматически. Никаких ссылок, никаких порталов, никаких дополнительных действий при каждой отправке.

Итог

S/MIME - для организаций, где Outlook или Apple Mail являются стандартом, есть бюджет на сертификаты и централизованное управление через AD/MDM. PGP - для технически грамотных пользователей, журналистов, разработчиков, и организаций, которые принципиально не хотят зависеть от центрального удостоверяющего центра. Оба стандарта решают задачу шифрования. Ни один не решает задачу доставляемости.

Зашифрованное письмо, отправленное на несуществующий адрес, вернётся точно так же, как незашифрованное. Шифрование защищает содержимое. Аутентификация защищает репутацию. А чистая база адресов обеспечивает доставку. Три слоя, каждый отвечает за своё.