自建邮局这些年，我对电子邮件的思考与拆解

我一直在开发的自建邮箱 - hostid

为什么我一直在做 hostid

电子邮件是互联网身份的源头

大学时我就开始琢磨自建邮局，起因是一个很朴素的发现：在互联网上，你是谁，很大程度上由你的邮箱决定。

想注册任何一个账号，几乎都绕不开两样东西：邮箱或手机号。这已经不是技术选择，而是一条默认的社会规则。找回密码靠邮箱，接收验证码靠邮箱，重要的通知和账单也发到邮箱。可以说，邮箱是一个人在互联网上大多数身份的“根”。

既然这么重要，我就想把这个根握在自己手里。

我不喜欢基础设施被垄断

我是个去中心化爱好者。邮件本来就是一个天然去中心化的协议，任何人都可以用自己的域名收发邮件。但现实是，绝大多数人的邮箱都托管在少数几家大型互联网公司手里。

一旦账号被封、服务调整、或者公司决定扫描你的邮件内容，你几乎没有反抗的余地。我认为能自己掌控通信基础设施，是一种个人隐私和权利。对我这种有专业背景的人来说，运维几台服务器和几个应用并不难，那为什么不自己来呢？

我想要一个干净、好看的邮箱

大厂的邮件服务确实免费，但说实话不好看。界面上堆满了按钮、会议、日历、网盘、AI 助手，还有广告。

我想要的很简单：一个优雅的界面，没有广告，没有我用不上的附加服务。邮箱就该只是邮箱。

电子邮件从哪里来

电子邮件比万维网还要老。

1971 年，Ray Tomlinson 在 ARPANET 上发出了第一封跨主机的电子邮件，并选择了 @ 符号来分隔用户名和主机名，user@host 这个格式一直用到今天。

早期的邮件很原始：主机之间直接投递，地址里写的就是具体的机器名。随着网络规模扩大，协议逐渐成形：

SMTP（简单邮件传输协议）：1982 年在 RFC 821 中定义，负责“把邮件送出去”，服务器与服务器之间、客户端与服务器之间都用它投递邮件。
POP3（邮局协议第 3 版）：负责“把邮件取回来”。它的思路是把邮件下载到本地，然后通常从服务器上删除，适合那个只有一台电脑、网络按时计费的年代。
IMAP（互联网消息访问协议）：同样负责收信，但邮件保留在服务器上，客户端只是同步视图。多设备时代来临后，IMAP 基本取代了 POP3。

那么问题来了，上述的协议在 IP 时期很有用，但是域名广泛应用以后，IP 被域名“匿名化”了，我们该怎么找到真实的邮件服务器呢？同理，和网站域名一样，也要借助 DNS 服务。DNS 为此引入了 MX 记录（Mail Exchanger），专门声明“这个域名的邮件由哪些服务器接收”，还可以设置优先级做主备。

从那以后，邮件的投递原理就基本定型了：查 MX，连服务器，用 SMTP 投递。后来的变化，主要都是在这个骨架上叠加安全和信任机制，后面会细说。

用现代互联网思维拆解电子邮件

如果抛开几十年的历史包袱，用今天做后端服务的眼光去看，电子邮件本质上就是一个服务，只有两个功能：

收件箱 + 发邮件。

看起来很简单，对吧？

先说发邮件。理论上，它简单到不可思议：

查询收件人域名的 MX 记录，比如 dig MX gmail.com；
连上 MX 指向的服务器的 25 端口；
用 SMTP 说几句话：HELO、MAIL FROM、RCPT TO、DATA；
邮件就送出去了。

没有注册，没有 API Key，没有鉴权。

那问题来了：

既然 25 端口就能发信，为什么还需要 465、587 这些端口？
都 2026 年了，为什么邮件协议不升级成 HTTP 和 RESTful 接口？ 每个域名提供一个标准化的 POST /mail 不就完了吗？

再说收件箱。收件箱其实更简单：监听 25 端口，收下别人投递来的邮件，存起来，再通过 IMAP 或者一个 Web 界面给自己看。这就是一个“接收 + 存储 + 展示”的应用，任何写过后端的人都能做出来。

甚至 IMAP 协议都不需要。如果只在自己的 Web 界面里看邮件，直接从数据库里读出来渲染就够了，IMAP 只是为了兼容第三方邮件客户端。

既然收和发都这么简单，为什么自建邮局还被公认为一件麻烦事？我对此发出过疑问，并很快得到了解答：垃圾邮件，以及随之而来的发件人声誉。

真正的难点从来不在收，而在发。 准确地说，难的不是“把邮件发出去”，而是“让对方愿意收下”。

答案：信誉

先回答端口的问题。

25 端口是服务器与服务器之间投递用的，它不要求鉴权，因为任何人都可能给你发信。但正因为不鉴权，它也成了垃圾邮件的重灾区。所以后来做了分工：

25 端口：MTA 之间互相投递（服务器到服务器）；
587 端口：邮件提交（Submission），客户端提交给自己的邮件服务器，要求登录鉴权，通常配合 STARTTLS 加密；
465 端口：一开始就是 TLS 加密的 SMTP 提交（SMTPS），一度被废弃，后来又在 RFC 8314 中被重新推荐。

也就是说，你的邮件客户端走 465 或 587 把邮件交给你的服务器，再由服务器走 25 投递给对方。这也是为什么很多云服务商和家庭宽带会直接封掉出站 25 端口：不封的话，任何一台肉鸡都能直接群发垃圾邮件。

再回答 HTTP 的问题。换成 HTTP 解决不了任何根本问题。协议只是传输方式，真正的问题是：收件方凭什么相信这封信真的来自它声称的发件人，而且不是垃圾？ 这个问题在 HTTP 上一样存在。再加上全世界海量的邮件服务器和客户端都基于 SMTP，迁移成本根本无法想象。邮件的生命力，恰恰来自它几十年不变的兼容性。

于是引出了邮件世界里最核心的概念：信誉（Reputation）。

SMTP 本身是一个“相信你说的话”的协议，MAIL FROM 里你想写谁就写谁。为了防止伪造，邮件生态在 DNS 上逐步叠加了几层证明：

SPF（Sender Policy Framework）：一条 TXT 记录，声明“哪些 IP 可以代表我的域名发信”。收件方拿发件 IP 来比对，不在名单里就可疑。
DKIM（DomainKeys Identified Mail）：发件服务器用私钥给邮件签名，公钥放在 DNS 里。收件方验签，就能确认邮件确实出自这个域名，而且内容没被篡改。
DMARC（Domain-based Message Authentication, Reporting and Conformance）：在 SPF 和 DKIM 之上加一条策略，要求它们与你看到的 From 域名对齐，并告诉收件方验证失败时怎么办（none、quarantine 或 reject），还能让对方把报告发回给你。
PTR（反向解析）：你的发信 IP 反查回来的域名，要和你声称的主机名一致。没有正确的 PTR，很多服务器会直接拒收。

这些都过了，只是“及格”。之后还有 IP 信誉、域名年龄、历史发信量、退信率、用户投诉率……大厂会综合这些数据决定你的邮件是进收件箱、进垃圾箱，还是直接被拒。

这就是为什么自建发信难。 不是技术难，而是信任难。一个全新的 IP 和域名，在别人眼里就是陌生人。

为什么整套邮件都建立在 DNS 上？

到这里会发现，MX、SPF、DKIM、DMARC，全都是 DNS 记录。为什么？

我的理解是：因为 DNS 是互联网上唯一一个全球通用、又能证明“我拥有这个域名”的公共系统。

邮件是去中心化的，没有一个中心机构来给大家发证书、做认证。那么谁有资格代表 example.com 说话？答案只能是：能修改 example.com 的 DNS 记录的人。

DNS 在这里扮演的角色，其实就是一个去中心化的公钥和策略发布平台：

MX 回答“去哪里投递”；
SPF 回答“谁可以替我发”；
DKIM 回答“怎么验证是我发的”；
DMARC 回答“验证不过怎么处理”。

想明白这一点后，我对电子邮件整个技术栈的理解一下子就清晰了：

SMTP 负责传输，IMAP 负责读取，DNS 负责身份和信任，信誉系统负责最终的裁决。

而这也意味着一件事：拥有一个域名，就等于拥有了一个可以自证的互联网身份。 邮件只是这个身份最古老、也最通用的用法。这就是我坚持自建邮局的底层逻辑：我不想让我的身份依附在别人的域名之下。

现状与未来：回到数字身份

最近几年，主流服务商在邮件领域的动作越来越多，门槛也越来越高：

2024 年起，Gmail 和 Yahoo 对批量发件人提出强制要求：必须配置 SPF、DKIM 和 DMARC，提供一键退订，并控制垃圾邮件投诉率。之后 Outlook 也跟进了类似规则。
越来越多的云服务商默认封禁出站 25 端口，需要申请才能解封。
新 IP、新域名的发信几乎一定要经过一段“预热”期，才能稳定进入收件箱。

这些措施确实有效地压制了垃圾邮件，但另一方面，它们也在悄悄把邮件变成一个事实上的寡头系统。规则由少数几家定，信誉由少数几家评，个人和小型服务器越来越难被平等对待。

与此同时，邮箱作为身份根的地位不但没有动摇，反而更加重要。大量服务支持“用 Google 登录”、“用 Apple 登录”，看似方便，实际上是把你的身份进一步交给了同一批公司。一旦这个账号出问题，你连带失去的可能是几十个网站的访问权。

所以我想说：

电子邮件不只是一个通信工具，它是你的数字身份。

自建邮箱没有想象中那么难。买一个域名，配好 MX、SPF、DKIM、DMARC 和 PTR，跑一套邮件服务，你就拥有了一个真正属于自己的身份。即使哪天你换了服务器、换了服务商，只要域名还在，你的身份就还在。

如果你也有一点技术背景，我很希望你试一试。每多一个自建邮局，这个网络就离它最初去中心化的样子更近一点。