一、邮件的天然处境：它更像一张明信片

要理解邮件安全为什么这么碎，先看它一路上要经过多少个环节：

这张表里最重要的一个词是"机会性"——它表示"能加密就加密，对方不支持就直接明文发过去，而且不会告诉你"。这跟 HTTPS 完全不同：HTTPS 谈不拢就直接断线，绝不降级；SMTP 谈不拢就退回明文，照样把信送到。原因是历史包袱：邮件系统先有明文协议、后有加密扩展，如果强制加密，全世界的邮件会在一天内互相发不出去。

最后一行也值得单独强调：加密保护【正文】，通常不保护【主题、谁发给谁、什么时候发的】。 也就是说，即使你用了最强的端到端加密，攻击者仍然能看到"谁在什么时候给谁发了多大的一封信"——这份元数据本身就有情报价值（对照 2-10，监视和分析的往往不是内容本身）。

二、必须分清三种完全不同的【层】

这一节的核心是一张表，因为它能纠正 90% 的误解：

三者互不替代：开了传输加密，邮件在服务器上仍是明文可读；做了发件人认证，也只是防冒充，内容照样没加密。

把这三层的差别用一句话说清：

• 传输加密管的是"路上"——从你的电脑到你的服务器、从你的服务器到对方的服务器，每一段都可以各自加密。但每一段都是"链路上的两点之间"，中间经过的服务器读得到内容。
• 端到端加密管的是"从头到尾"——发信人在自己电脑上就把内容加好，只有收信人能解开，路上所有服务器看到的都是密文。这是唯一能防住"服务器上有权看邮件的人"的做法。
• 发件人认证管的是"这封信真的是你发的吗"——它完全不保护内容，只证明来源。它要解决的问题是"别人冒充你的域名给客户发指令"（这正是 3-5 里商务邮件欺诈的作案方式）。

为什么这三层必须都做？因为它们防的是三种不同的对手：传输加密防链路上的窃听者，端到端加密防服务器上的窥视者，发件人认证防冒充你身份的人。

三、PGP 与 S/MIME：端到端加密的两条路

端到端加密只有两条现实路线，它们的分岔点在一句话上：钥匙从哪儿来。

PGP 的思路是"没有中心"：你生成自己的钥匙对，把公钥发布出去（或者直接给朋友）；别人凭什么相信那个公钥真是你的？靠见面对指纹，或者靠朋友签名背书（这就是"信任网"）。优点是没人能吊销你、也不花钱；缺点是"我该信哪个公钥"这个问题要靠人际解决，规模化不了。

S/MIME 的思路正好相反：它直接套用 5-4 学过的证书体系——由 CA 签发证书，信任靠证书链。优点是 Outlook 和 Apple Mail 都内置支持、企业能集中管理、还能被合规审计；缺点是每个地址每年要花 20~60 美元。

看起来 S/MIME 更省事，那为什么两条路都没普及？ 因为它们都有一个共同的、非技术的障碍：用起来太麻烦。 收件人没装对应软件、没有你的公钥、不知道指纹对不对——任何一环卡住，加密就谈不成。而这封信还不能"降级发送"，否则等于白加密。结果是：真正用端到端加密发邮件的人，到今天仍是很小的一群人。

四、动手 Demo：一封信要过几道关

下面这段输出把上面的三层结构和端口都摊开了——特别是最后两张表，一张是"哪些号码对应哪种加密"，一张是 2026 年的真实采用率。

一、邮件的天然处境：它更像一张明信片，不是密封信封
  环节                              默认状况
  从你到你的邮件服务器              可能明文（取决于是否开了加密）
  服务器到服务器之间                机会性加密，对方不支持就退回明文
  在服务器上存放                    多数服务商默认明文存，可被检索
  主题行与收发件人                  几乎所有方案都不加密（元数据）
  → 加密保护【正文】，通常不保护【主题、谁发给谁、什么时候发的】。

二、要分清三种完全不同的【层】
  层              保护什么                      代表技术
  传输加密        两台中继之间那一段线          SMTP over SSL / STARTTLS / MTA-STS
  端到端加密      内容对中继也保密              PGP（OpenPGP）/ S/MIME
  发件人认证      防止别人冒用你的域名          SPF / DKIM / DMARC
  → 三者互不替代：开了传输加密，邮件在服务器上仍是明文可读；
     做了发件人认证，也只是防冒充，内容照样没加密。

三、PGP 与 S/MIME：端到端加密的两条路
  对比项          PGP / OpenPGP                       S/MIME
  密钥怎么来      自己生成，靠服务器或手动交换        由 CA 签发的证书
  信任靠什么      人际网络 / 指纹核对                 证书链与 CA
  典型成本        免费                                约 20~60 美元/年/地址
  客户端支持      Thunderbird、GnuPG、Mailvelope      Outlook、Apple Mail、Thunderbird 内置
  企业集中管理    弱（密钥在个人手里）                强（可集成企业 PKI）
  什么时候用它    个人敏感通信、开源发布签名          企业内部、合规场景
  → 2026 年的现实：PGP 的新路径是 WKD（用 HTTPS 自动发现公钥），
     OpenPGP v6（RFC 9580）默认用 AEAD 加密、弃用 SHA-1。
     但两者都没能普及——原因始终是【用起来太麻烦】。

四、2026 年的采用率：认证普及了，加密没有
  标准        采用率                      它在干什么
  SPF         84.5%（硬拒绝的约 47.9%）   列出允许以你域名发信的服务器
  DKIM        22.7%（另一口径约 90%）     给外发邮件加密码学签名
  DMARC       30.4%（强制拦截的仅 12.8%） 声明冒充你域名的邮件怎么处理
  MTA-STS     0.3% ~ 4%                   强制对方用加密通道投递
  BIMI        0.4% ~ 9.4%                 收件箱里显示品牌标识（需先做到强制 DMARC）
  → 数据里最值得记住的一条：是【发布 DMARC 的】与【真正执行策略的】
     之间的落差——很多域名只是挂了个 p=none，等于只收报告不设防。

五、SMTP over SSL 与 POP over SSL 是两件不同的事
  用途          协议    端口                          说明
  发信          SMTP    25（明文）/ 465（隐式 TLS）   465 是整条连接一开始就加密
  发信（提交）  SMTP    587（STARTTLS）               先明文打招呼，再升级为加密
  收信          POP3    110（明文）/ 995（POP3S）     把邮件下载到本地
  收信（在线）  IMAP    143（明文）/ 993（IMAPS）     在多设备间同步邮件

六、最后一句必须记住的话
  加密解决的是【路上别被人看见】，不解决【发信的人是不是骗子】。
  一封完全通过加密链路投递的钓鱼邮件，仍然是一封钓鱼邮件。

关于端口那张表，有一个最实用的口诀：带 S 的端口号通常就是加密版——993 是 IMAPS、995 是 POP3S、465 是 SMTP 的隐式 TLS。而 587 这个号要单独记：它是"提交端口"，专门给发信客户端用，走的是先明文打招呼再升级的 STARTTLS——今天配置邮件客户端时，发信应该填 587（推荐）或 465，而不是 25。

五、⚠️ 2026 现状

1. 认证已经普及，加密没有——这是本节最重要的结论。 不同口径的统计差得很大，但方向完全一致：在只覆盖顶级域名的口径里 SPF 约 84.5%、DMARC 约 76.6%；在覆盖 550 万个域名的口径里 SPF 约 56.0%、DMARC 约 30.4%、DKIM 约 22.7%。而 MTA-STS（强制加密投递）只有 0.3%~4%，比签名相关的部署低一两个数量级。翻译成人话：行业已经普遍做到了"证明这封信是我发的"，但远远没有做到"让这封信在路上不能被读"。

2. 更值得警惕的是"发布了却没执行"的落差。 在 550 万域名的口径里，发布 DMARC 的约 30.4%，但真正把策略设成强制拦截的只有 12.8%——换句话说，超过一半的域名只是挂了个 p=none，功能是"只收报告不设防"。这等于买了报警器但没接警局：你知道有人在冒充你，但系统不会拦。Google 与 Yahoo 从 2024-02 起对批量发信者强制要求 DMARC，Gmail 在 2025-11 进一步收紧，这是 2026 年推动采用率上升的主要外力。

3. PGP 在 2026 年有了新路径，但普及率的瓶颈不在技术。 三个进展值得知道：WKD 让"找公钥"变成一件用 HTTPS 自动完成的事，不再需要手动交换；Autocrypt 把公钥信息自动跟着邮件走；OpenPGP v6（RFC 9580）默认改用 AEAD 加密、弃用 SHA-1，并支持椭圆曲线与后量子算法。另外那个著名的邮件公钥服务器池（SKS）因为隐私与滥用问题基本已经废弃。但这些进展都没能改变一个事实：加密邮件的门槛依然在"对方也得配好"。

4. 有些保护是端到端加密给不了的。 元数据（主题行、收发件人、时间、附件大小与名称）在 PGP 和 S/MIME 里都不加密——这是设计上的选择，不是实现遗漏：不加密主题，服务器才能给你做搜索、分类、反垃圾。代价是"加密邮件在多数收件箱里搜不到内容"，这也劝退了大量用户。 而最重要的一条是：

加密解决的是【路上别被人看见】，不解决【发信的人是不是骗子】。 一封完全通过加密链路投递的钓鱼邮件，仍然是一封钓鱼邮件。

这条原则在今天尤其要紧：攻击者完全可以给自己的恶意邮件配齐 SPF、DKIM、DMARC——因为那证明的只是"这封信真的来自那个域名"，而那个域名本来就是攻击者注册的（对照 5-8：挂锁证明的是连接被加密，不证明这个网站是合法的——同一个道理换了个场景）。

30 秒实验

1. 算一次你自己域名的邮件防护分。如果你有自己的域名，在浏览器里搜「MXToolbox DMARC lookup」之类的在线检查工具，输入你的域名，看它有没有 SPF 记录、有没有 DMARC 记录、DMARC 的策略是 p=none 还是 p=reject。没有域名的替代做法：打开任何一封你收到的公司邮件，点「显示原始邮件」（Gmail 是「显示原始邮件」，Outlook 是「邮件属性 → Internet 邮件头」），找 Authentication-Results 这一行——它会把 SPF、DKIM、DMARC 三项的结果都写出来，通常是三行 spf=pass、dkim=pass、dmarc=pass 或 fail。这三行就是这封信的"身份证检查结果"。

2. 认一下你的邮件客户端用的是哪个端口。打开邮件客户端的账户设置，找到「发件服务器（SMTP）」，看端口号：如果是 587，走的是 STARTTLS（推荐）；465 是隐式 TLS，也可用；如果看到 25，那是老式配置，应该改掉。再看「收件服务器（IMAP）」，993 就是加密的——顺手确认旁边那个「使用 SSL/TLS 加密」的勾是勾上的，而不是「无」。

常见误区

1. 错误：我在邮件设置里勾了 SSL，所以我的邮件是端到端加密的。——纠正：你勾的那个 SSL 只保护"你的电脑到你的邮件服务器"这一段链路，这就是【传输加密】。邮件到了服务器上就是明文，服务器管理员、合规系统、被入侵后的攻击者都能读——而且服务器到服务器之间那一段"机会性加密"还可能退回明文。要真正的端到端加密，必须双方都用 PGP 或 S/MIME，两者的区别不是"加密强度"，而是"钥匙从哪儿来"。

2. 错误：做了 SPF、DKIM、DMARC，收到的邮件就是安全的。——纠正：这三项证明的只是"这封信真的来自它声称的域名"，不证明"发信的人是好人"。攻击者只要注册一个形近域名，就能给自己的恶意邮件配齐全套认证——这也是商务邮件欺诈始终有效的原因。另一个坑是"发布了却没执行"：挂个 p=none 只相当于打开报告开关，系统不会拦任何东西，必须在确认没有误伤之后再推进到 p=quarantine、p=reject。

3. 错误：PGP 早就过时了，不用管它。——纠正：PGP 在 2026 年反而有几条明确的新路径：WKD 让公钥发现自动化、Autocrypt 让公钥信息随邮件走、OpenPGP v6（RFC 9580）默认用 AEAD 并支持后量子算法。它今天最活跃的用途也不是邮件，而是软件发布签名——很多开源项目的发行包仍然用 PGP 签名让你校验（这也是 5-13 的话题）。它没有普及的原因是"用起来麻烦"，不是"不安全"。

4. 错误：邮件加密了，那这封信就完全私密了。——纠正：元数据没有加密。主题行、谁发给谁、什么时候发的、附件多大、附件叫什么名字——这些在 PGP 与 S/MIME 里都是明文，而且加密邮件的正文在很多收件箱里搜不到（服务器读不了，自然也索引不了）。所以"私密"要分清是"内容对服务器保密"还是"连你在和谁通信都保密"——后者今天基本做不到。

• ☐ 下一节（5-12 实现安全的远程通信）

相关笔记

• 如果加密变得不安全，世界会怎样 —— 上一节：危殆化与吊销
• 实现安全的远程通信 —— 下一篇：SSH、客户数字证书、VPN 与 IPsec
• 利用电子邮件发起的攻击和欺诈 —— 本节三层防护要对付的具体手法
• Web 网站的安全性可通过加密图标确认 —— 同一个道理：加密不等于可信
• 🛡️ 网络与信息安全 · 索引 —— 全课路线图