VPS 自建邮件服务器教程：25 端口、反向解析（PTR），为何邮件总进垃圾箱

接收方到底先检查什么？判断顺序才是关键

接收邮件的服务器要做一连串判断，而且绝大多数判断，是在它读到你邮件正文的第一个字节之前就已经做完的。这个顺序才是关键：连接阶段出的问题，靠写得再好的邮件内容也救不回来；而一封认证做得完美无缺、却来自毫无历史记录地址的邮件，照样会被丢进垃圾箱。按顺序把这条链路捋一遍，你就知道该把精力花在哪里——而这几乎从来不是大多数人真正花精力的地方。

第一个判断发生在 TCP 连接阶段：这是谁，我到底要不要跟它说话？此时接收方掌握的只有你的 IP 地址、它的反向 DNS，以及它自己或它所用黑名单服务商给这个地址打的信誉分。第二个判断发生在 SMTP 信封阶段——HELO 和 MAIL FROM——这里会针对连接 IP 校验 SPF。第三个判断随邮件正文一起到达，这时会验证 DKIM 签名，并由 DMARC 判断这两项认证结果中是否有一项能对齐可见 From: 头中的域名。只有在这一切都完成之后，才会开始类似内容过滤的环节，而到那时，结果基本已经定了。

由此能得出两点。最容易拿下的胜利在这条链路的最上端：一条正确的 PTR 记录，只需要在控制面板里填对一个字段，就能整整消除一大类拒收。而这条链路的最下端——大家最担心的部分，也就是邮件措辞——恰恰是你能掌控最少的部分，而且只有当上面这些环节都干净了，它才会真正开始起作用。

25 端口：整个问题里最省事的一环

几乎所有大型云平台，默认都会封锁出站 25 端口，想解封就得提交申请。AWS、Google Cloud、Azure、Oracle Cloud，以及大多数知名 VPS 品牌，出厂就把 25 端口的出站流量过滤掉了，而解封申请是一张挂在账号下的表单——这个账号早就绑定了你的身份信息、银行卡和手机号。自建邮件服务器的计划，往往就是在这一步悄悄夭折的，这也是为什么把大多数人带到这类文章的搜索词，通常是某个版本的哪家 VPS 的 25 端口是开放的。

把这三个端口分清楚很有必要，因为它们经常被混为一谈。25 端口是服务器对服务器的：一台 MX 服务器就是靠它把邮件转交给另一台，全程不做身份验证，也是唯一一个关系到能否把邮件投递给“不是你自己用户”的端口。587 端口是提交端口——你自己的客户端在服务器帮它转发邮件之前，先在这里完成身份验证。465 端口做的是同一件事，只是从第一个字节起就用 TLS 加密；它在九十年代被废弃过，后来被 RFC 8314 正式恢复，如今已是理智的默认选择。失去出站 25，你没法往外发信；失去入站 25，全世界都没法给你发信；这两者完全可能只丢了一个而不丢另一个，让你花一下午时间冤枉 DNS。

在 BitVPS 上，出站 25 端口在所有套餐、所有机房都默认开放。没有表单，也没有申请流程，因为根本没什么需要解封的。入站的 25、465 和 587 端口，走的是懂邮件协议的清洗，而不是笼统的三层过滤——这个区别在遭到攻击时才真正重要：一套能理解 SMTP 的过滤系统，可以把攻击流量挡掉，同时不会连带挡掉背后正常的 MX 通信。具体细节见 邮件服务器专页，而清洗到底意味着什么、不意味着什么，可以参考 DDoS 防护说明。

25 端口开放只是必要条件，离充分条件还差得远——这正是本文接下来还要再写三千字的全部原因。

分配给你的 IP，比你的配置更能决定结果

你的配置，无非是几条 DNS 记录加一天的工作量。而 IP 地址背负的历史，却不是你写下的。一个在 2019 年成天发药品垃圾邮件的 /24 网段，会被一直记住；一个从上个月被封号的客户那里回收来的地址，一到手就已经背着案底；一个“邻居”很吵的网段，在按 /24 打分的接收方那里，会被连坐判罚。这些从服务器内部完全看不到，也不会因为你把 main.cf 写得再漂亮而有任何改变。

所以要在下决定之前查，而不是之后才查。公开黑名单能告诉你一部分真相：真正影响投递的是 Spamhaus——它的 SBL 和 CSS 收录被实际观察到发送垃圾邮件的地址，PBL 收录运营商自己声明“不应直接发信”的网段，DBL 收录的则是域名而不是地址。Barracuda 和 SpamCop 也值得查一下，一旦问题解决，清除得也很快。但真正决定你大部分结果的两个信誉分是私有的：Google 和 Microsoft 各自维护着按 IP 和按域名打的分数，你完全无法主动查询，唯一的窗口是 Postmaster Tools 和 SNDS，而且只有当你的发信量大到足以让它们形成看法之后才看得到。

关于网上流传的检查清单，有两点要提醒。其中一半仍然让你去查 SORBS：但 SORBS 已经在 2024 年 6 月 5 日被所有者关停，它的区域现在什么都不返回，所以查它得到的不是“体检合格”，而是一次死查询。另外，对 UCEPROTECT 的二级和三级名单要保持怀疑——它们靠“连坐”把邻居乃至整个自治系统一并列入名单，然后邀请你付费加急移除，这也是为什么大多数正经的接收方根本不理会它们。追着三级名单跑，是一个能让你白白耗掉一个周末的办法。真正值得认真对待的，是 Spamhaus 自己的信誉查询平台。

这也是主机商到底有没有帮上忙的分水岭。BitVPS 在开通时就会用主要名单核对每一个地址，如果命中就会在你登录之前先换掉；分配给邮件客户的 /29 网段，十二个月内不会是从其他邮件客户那里刚回收来的；而且可以在同一机房内把 /29 网段迁移到别的物理机，而不需要给你重新分配 IP——一旦某个地址的信誉是你花了六个月才建立起来的，这一点就格外重要。这些做法都不能把一个地址变“好”，只能让它变“中性”——而这也是任何主机商能诚实给出的最高承诺。

PTR 反向解析、HELO 和 A 记录：三者必须对得上

这是一台安装得完全正确的邮件服务器最常被拒收的单一原因，也是本文里最容易改对的一件事。三个名字必须互相印证：服务器在 HELO 里声明一个主机名；这个主机名的 A 记录要指向发信时用的那个地址；而这个地址的 PTR 记录，要反过来指回这个主机名。正向解析得到地址，反向解析得到名字，这个来回被称为“正反解一致”（forward-confirmed reverse DNS）。自 2024 年 2 月起，在 Gmail 那里，有效的 PTR 记录已经不是加分项，而是对每一个发信人的明文要求，不管你是不是大批量发信。

出错的方式主要有四种，按出现频率从高到低排列。第一种，根本没有 PTR，因为主机商压根不提供这个字段。第二种，有 PTR，但是服务商的通用记录——以主机商自己的域名结尾，等于向每一个接收方宣告“这是一个租来的地址，而这个网段基本不发邮件”。第三种，HELO 名称写错了：安装程序给的默认值、一个不完整的短主机名，或者 localhost，这些统统解析不出来。还有一种连细心的人都会栽的：机器有 IPv6，接收方发布了 AAAA 记录时 MTA 会优先走 IPv6，而 v6 地址却没设 PTR——于是发到 Gmail 的邮件走 IPv4 一切正常，同一封邮件走 IPv6 却被拒收。要么把 v6 的 PTR 设置好，要么在设好之前先用 smtp_address_preference = ipv4 把传输方式钉死。

在 BitVPS 上，每一个 IPv4 和 IPv6 地址的 PTR 字段都可以在面板里自助设置，可以填任意你想要的 FQDN，不会被强加服务商后缀，全球范围内五分钟内生效，而且一次最多可以批量修改十个地址。详细说明见 网络页面；之所以要在意这件事，原因就在这一节里说的：一个连设置反向解析都要你开工单的主机商，日后你每重装一次系统，都得再开一次工单。

SPF、DKIM、DMARC 到底各自证明什么？“对齐”又是什么意思

这三样东西都是以 DNS 记录形式发布的，设置起来一小时就够，可惜几乎所有地方都把它们讲错了——常被当成三个可以互相替代的“防垃圾邮件符咒”，而不是三个各自独立的断言。SPF（RFC 7208）声明的是哪些地址可以发送带有某个信封发件人的邮件。DKIM（RFC 6376）则是在邮件头和正文上附加一个加密签名，让邮件能证明是哪个域名对它负责。这两者，都完全没有对收件人实际看到的地址做出任何声明。

而这正是 DMARC（RFC 7489）要做的事，这也是为什么对齐才是真正关键的词。DMARC 通过的条件是：SPF 或 DKIM 通过，并且通过验证的域名要和可见的 From: 头里的域名一致。经典的失败场景就出在这里：你的邮件 SPF 能通过，是因为退信地址用的是发信主机能控制的域名，但这个域名并不是 From: 里的那个，于是不算对齐；再加上没有 DKIM 签名可以兜底，一封在日志里看起来认证得完美无缺的邮件，DMARC 照样会判失败。另一个经典失误，是第一天就发布 p=reject，一份报告都还没读过，结果一个月后才发现，开票系统的邮件其实一直被悄悄拒收。正确做法是先从 p=none 加一个 rua 地址开始，看看收到什么报告，之后再逐步收紧。

还有两条操作上的提醒，价值比看起来要大。把 SPF 记录的 DNS 查询数控制在十次以内——每一个 include: 都要算一次，嵌套三个 SaaS 服务商就很容易超限，而且超限之后是永久性错误，不是软性失败。另外，DKIM 选择器要偶尔轮换，而不是从来不换：新增一个选择器成本很低，提前发布好第二个选择器，就是“五分钟完成密钥轮换”和“服务中断”之间的差别。

2024 年和 2025 年，门槛悄悄提高了两次

二十年来，发信的及格线大致就是“有 PTR，别上 Spamhaus”。这个局面在 2024 年 2 月被打破：Google 和 Yahoo 发布了几乎一模一样的发件人要求，并开始真正执行。现在，每一个发件人——包括一天只发四封邮件的你——都需要有效的正反解一致 PTR 记录、连接上的 TLS，以及 SPF 或 DKIM 中至少一项。而对单个接收方每天发信量超过大约五千封的发件人，则需要同时具备 SPF 和 DKIM 和 DMARC 记录，一个符合 RFC 8058 的可用一键退订头，并把垃圾邮件投诉率控制在 0.3% 以下。

Microsoft 在 2025 年 5 月 5 日跟进了同一套规则，适用于 Outlook.com、Hotmail 和 Live：每天向这些消费者邮箱发信超过五千封的域名，必须具备 SPF、DKIM 和 DMARC，不合规的邮件会先被投进垃圾箱，之后则会被直接拒收。在你开始发信之前，Microsoft 的发件人支持文档和 Yahoo 的最佳实践，都值得花十分钟读一下。

对个人或小团队服务器来说，实际的后果不是踩到这些门槛——你不会踩到——而是“完全不做认证”这件事本身，如今已经真的显得反常了。以前，一个没有历史记录的地址发出没有 DMARC 记录的邮件，是再正常不过的事。到了 2026 年，这看起来就像是过滤系统当初被设计来拦截的那类画像。哪怕你不是批量发件人，也要按批量发件人的标准去配置，因为代价只是一个下午，而不这么做，你就会被拿去和一个你根本不属于的群体一起打分。

全新地址怎么预热：从无人知晓到被信任

一个全新的地址，与其说是“中性”，不如说是“未知”，而“未知”招来的怀疑程度，跟你的发信量成正比。管用的预热方式说起来很枯燥：先只给真正会打开、会回复的人发送真实的往来邮件，保持每天发信量大致稳定，让它缓慢增长而不是阶梯式跳升，并且永远不要拿买来的或者从别处导出的名单去砸一个全新的地址。“互动”才是把“未知”变成“可信”的信号，而这一点没有任何捷径可走。

要用接收方提供的工具去衡量，而不是盯着自己的收件箱看。验证域名之后，Google 的 Postmaster Tools 会展示域名和 IP 信誉、垃圾邮件投诉率和认证通过率——不过在你的发信量大到足以让它汇总出数据之前，这里会一直是空的，对个人服务器来说，这可能意味着永远是空的，这也没关系。Microsoft 的 SNDS 对 Outlook.com 做的是同一件事，并且和“垃圾邮件报告计划”（Junk Mail Reporting Program）配套，会把投诉直接转发给你。一次性打分服务，用来在十秒内抓出一条写错的记录很有用，除此之外就没什么用了——它对信誉什么都说明不了，因为它跟你之间同样没有历史记录。

对最难啃的那家接收方，要老实设定预期。新地址在 Outlook.com 那里挣扎的时间通常最长：一台配置正确、认证完美无缺的服务器，在 Gmail 那边从第一封邮件起就被放行，同一台服务器在 Outlook.com 那边却被投进垃圾箱、一投就是好几周，这是常见现象。解决办法是时间、持续稳定的发信，以及有收件人主动把邮件从垃圾箱里捞出来——而不是再加一条 DNS 记录。如果“第一天就要在 Outlook.com 稳定送达”是一项硬性业务需求，而不只是偏好，那就是一个信号，说明你需要的是中转（relay），而不是自建发信服务器——这正是最后一节要讲的内容。

该用哪套软件？需要多大的机器

四种组合基本能覆盖所有人。Postfix 搭配用于 IMAP 的 Dovecot 和用于过滤的 rspamd，是最经典的组合：三个守护进程，纯文本配置，你能遇到的每一条报错，网上早就有人给出答案了。OpenSMTPD 做的是同一件事，配置文件一口气就能读完，这个优点在凌晨三点排障时的分量，比听起来要重得多。Stalwart 是一个单一二进制文件，同时支持 SMTP、IMAP 和 JMAP，内置过滤功能，是目前从零开始搭建时最省心的选择。而 Mailcow 或 Mail-in-a-Box 则把整套东西替你组装好，连 webmail 都包含在内，代价是你用的是一整套自己没有选择、也不容易再拆开的技术栈。

配置怎么选，关键不在邮箱数量，而在你在前端挂了什么。SMTP 和 IMAP 本身很省资源，几十个邮箱在任何一台现代机器上都只是舍入误差。真正吃内存的是过滤环节。rspamd 很克制，加载好各种映射表之后也就几百兆。ClamAV 就不一样了：光是病毒特征库就能占掉超过一 GB 的常驻内存，也是最容易把小型实例拖进交换分区的单一组件——而在邮件服务器上，这意味着队列开始堆积，投递变慢，慢到接收方开始把你的邮件延后处理。有内存就开它，没有就跳过，把担子交给 rspamd。

对应到实际套餐上：一台 8.50 美元的 Starter，配置 2 vCPU、4 GB 内存、60 GB NVMe，只要不装 ClamAV，跑一个人域名的 Postfix、Dovecot、rspamd 完全绰绰有余。13.50 美元的 Growth 套餐，4 vCPU、8 GB、120 GB，是那种“用上之后就不用再操心”的档位——二三十个邮箱、全套过滤功能都跑得动，邮件存储量哪怕连着增长好几年也留有充足空间。真正先见底的其实是存储空间，因为但凡收到过的邮件，几乎都会被永远留着。

按正确的顺序把它跑起来

1. 指向域名，部署实例。先定好服务器要用哪个主机名来标识自己——按惯例是 mail.example.com 这种形式——发布它的 A 记录，只有打算走 IPv6 发信时才需要加 AAAA 记录，再把域名的 MX 记录指向这个主机名。机房位置选离你通信对象最近的那个；在 BitVPS 上，付款确认后大约六十秒实例就能上线，出站 25 端口届时已经是开放的。

2. 设置匹配的反向解析。把 IPv4 地址的 PTR——如果发布了 AAAA，还有 IPv6 地址的 PTR——都设成第一步里那个主机名，一字不差。正向和反向必须双向一致。这只是面板里的一个字段，却是整个流程里含金量最高的一分钟。

3. 双向开放正确的端口。出站 25 用来发信，入站 25 用来收信，587 和 465 给自己的用户提交邮件，993 给 IMAP，其余全部关闭。一个只放行出站 25、不放行入站 25 的防火墙，排查的头一个小时看起来会完全像是 DNS 出了问题，但其实根本不是。

4. 安装 MTA，给它一个真实身份。Postfix、OpenSMTPD 或 Stalwart 均可；把 HELO 名称设成第一步里那个主机名；给这个名称配上证书，启用 TLS。Let's Encrypt 免费，也是互联网上大多数网站在用的证书。继续下一步之前，先给自己发一封测试邮件，看看邮件头——后面每一步都建立在这一步成功的前提上。

5. 发布 SPF、DKIM 和 DMARC。SPF 记录列出发信地址，测试阶段先以 ~all 结尾。生成一个 2048 位的 DKIM 密钥，发布好选择器，并开启签名。DMARC 记录设为 p=none，配上一个 rua 地址，好让报告开始送达。三条 DNS 记录，不花一分钱，最多一小时搞定。

6. 看认证结果，不要只看收件箱。分别发给 Gmail、Outlook.com 和一个企业邮箱，然后逐一打开 Authentication-Results 头。你要看到的是 spf=pass、dkim=pass、dmarc=pass，而且对齐的域名要是可见的 From: 里那个。三项全过却仍进垃圾箱，是信誉问题；有一项失败才进垃圾箱，是配置问题。这两者的解法完全不同，把它们搞混，会白白浪费好几周。

7. 报告干净之后再收紧策略。在一两周内的 DMARC 报告里，如果没有任何合法来源被判失败，就把策略调到 p=quarantine，之后再调到 p=reject，同时把 SPF 从 ~all 改成 -all。没读报告就提前收紧，正是很多人在自己都没察觉的情况下，把自家发票邮件拦了一整个月的原因。

8. 补上大家都会忘记的部分。发布 MTA-STS 和 TLS-RPT，让其他发件人知道要坚持对你用 TLS；如果你的区域做了签名，再加上 DANE；把 rspamd 挡在收件箱前面；把邮件存储备份到这台机器之外的地方，并且静态加密——全盘加密指南讲清楚了这能保护什么、不能保护什么。然后盯着出站队列：一个在悄悄变长的队列，是信誉出问题的最早征兆，往往比你注意到“回复变少了”提前好几天出现。

什么时候不该自建邮件服务器

有些情况下，自建发信服务器就是一笔亏本买卖，把这些情况说清楚，比再写一段鼓励的话更有用。最明显的是“冷启动式批量营销”：一个毫无历史记录的全新地址，一上来就发几千封邮件，这正是过滤系统天生就是用来抓的那种画像，任何配置都救不了它。至于丢一封邮件就要花钱的事务性邮件——密码重置、订单确认、双因素验证码——应该放在已经建立起信誉的基础设施上，因为新地址证明自己的那两周，就是两周的支持工单。而任何一个没人愿意在周日盯着邮件队列的团队，都会在某个周一发现，自己的出站邮件从上周五起就一直被延后处理。

还有一个匿名性方面的取舍，大多数文章都会略过不谈。邮件服务器，是你能运行的东西里匿名程度最低的一种。它要公开一个域名、一个固定地址、一条指向该域名的 PTR 记录、一条把它们绑在一起的 MX 记录，还会把描述完整传递路径的邮件头，一份不落地交给每一个收件人。匿名性和公开的 MX 记录是两个相反的方向；如果你来看这篇文章是出于隐私考虑，而不是为了掌控权，那在动手之前，请先读一读加密货币托管到底有多可追踪。自建确实能把第三方从你存储的邮件及其元数据里排除出去，这是一个真实且值得追求的好处——但它并不能让邮件内容本身变得匿名，也不可能做到，因为每一次对话总有一半，存在别人的邮箱里。

对大多数人来说，真正管用的安排是“两边分开”。必须送达的邮件，留在一个已有信誉的服务商那里；想脱离第三方基础设施的往来邮件，则用第二个域名自建。让每一边都做自己擅长的事。代价只是多一个 DNS 区域，好处是两套系统都不用去做自己不擅长的活，而这也正是在 BitVPS 上跑邮件服务器的相当一部分用户实际的做法。不管发什么，都只面向明确同意接收的人——购买来的名单不在我们的可接受使用政策范围之内，而且是把一个交到你手上时还是干净的地址烧掉的最快方式。