给别人家的邮件服务器加一个域名
这件事看起来像个 DNS 活
有个域名要收信。邮件服务器是我自己那台跑 mailcow 的 VPS，所以这就是「加域名、加记录、建信箱」——二十分钟的活，而且我做过好几次。
这次花了更久，原因是我关于邮件服务器的两个假设并不成立，另外还因为互联网有一条任何服务器配置都改不了的性质。
收信：四条记录，加一次真测试
收信恰好只需要四样东西，而且都住在域名自己的 DNS 里（这里是 Cloudflare）：
MX ninelore.com → mail.hoelee.com （优先级 10）
TXT @ → v=spf1 mx -all
TXT dkim._domainkey → （MTA 发布的那个选择器）
TXT _dmarc → （策略 + 报告地址）配好之后，只用一种算数的方式测：从这套环境外面（走第三方中继）寄进新地址，然后去读服务器自己的日志行——rspamd 在收下这封信时记下 RCPT_MAILCOW_DOMAIN(ninelore.com)。收信一次就通。收信确实是容易的那一半，而它之所以容易，正因为它只依赖你自己能控制的记录。
出信才是地面移动的地方
两堵独立的墙，各有各的错误，而且都不是改一改区域文件就能修的配置失误。
第一堵墙：那条反垃圾策略，本质上是缺一条 PTR。 一次直投尝试被对方退回：
554 5.7.1 Mail rejected due to antispam policy在怪远端之前，我先排掉常见原因：四个主流黑名单全干净，域名自己的 SPF/DKIM/DMARC 也都正确。剩下的解释就是那条不在我控制里的记录——发信 IP 没有反向 DNS。一台收信服务器如果无法把连进来的 IP 映射回一个名字，就会把它当成一个它无法背书的来源；再正确的 SPF 也压不过这一点。
第二堵墙：用中继绕过去也不行。 下一个显然的动作是让所有信走那条已经能用的出信中继。结果是：
550-From header sender domain not verified (gmail.com)这行错误要仔细读，因为它一次打死了一整类设计。中继的「已验证寄件人」策略，检查的是 From 头里的域名——而转发出去的信保留的是原寄件人的 From。所以从你转发第一封来自外部寄件人的信开始，你就是在要求中继以 gmail.com 的身份发信，而它永远不会允许。mailcow 在这里还有个值得先知道的坑：它按寄件人域名选中继，所以一封 From 是外部域的信，根本不会走到你配的那条中继上。
那个并不存在的「信箱转发」功能
原计划是建好信箱，再转发一份到我的主邮箱。结果连着两个意外：
- mailcow 没有「信箱转发」这个设置。把信箱地址写进别名的
goto列表会被拒（is_alias_or_mailbox），因为每个信箱自带一条 self-alias 记录，代码在算目标时会跳过这个地址。 - 想「保留信箱并且转发」只能走 Sieve 过滤器——那是另一套机制、另一种失败形态——而它最后仍然落在第一堵墙和第二堵墙上，因为这封信终究得离开这台机。
所以我什么都没启用。一条出信路径送不出去的转发，不会安静地失败：它会把退信发回给无辜的原始寄件人（backscatter），而每一封这样的退信都在花一个本来就没有余量的 IP 的信誉。对「这个新信箱要送到我的收件箱」这件事，稳定的答案是收件侧的 POP 拉取：我的邮件客户端从 mail.hoelee.com:995 拉信，VPS 什么都不用发。
PTR 是一个 IP 一条，不是一个域一条
这是我一直需要解释、包括对我自己解释的部分：
- 反向记录是IP 地址的属性。不存在「每个域一条 PTR」，下次再加域也没有任何 PTR 要动。
- 它正确的值就是邮件服务器自己对外报的名字——这里是
mail.hoelee.com，也就是 postfix 用作 HELO/myhostname 的那个。正向记录（mail.hoelee.com → 41.216.187.102）已经存在，这一对才是收信方要验证的东西：forward-confirmed rDNS。缺任何一半都一文不值。 - 那个 IP 上所有域名都用同一条反向记录来评判。一百个域名，一条 PTR。
- 谁来设：跑反向区的人。这里
216.41.in-addr.arpa与187.216.41.in-addr.arpa两级的 SOA 都是 VPS 商自己的名字服务器，所以它是服务商侧的改动——先去 VM / 网络面板里找有没有 rDNS/PTR 输入框，没有就提工单，把上面那个确切的值给他们。
我没有假设，而是去查了当前状态：正向解析正常（mail.hoelee.com → 41.216.187.102），那个 IP 的反向解析依旧什么都不返回。所以直投仍然会被拒，唯一能用的出信路径是中继——而它那条「已验证寄件人」的要求，新域名一样得满足。
三件要提前知道的事，免得以后被吓到
- PTR 不是信誉。 它拆掉的是一次硬拒；它不会让你被信任。新 IP 通常需要几周的日常通信，大厂才会停止把它塞进垃圾箱——而从全新 IP 起步，就是把这口钟从零开始拨。
- PTR 修的是你自己的出信，对转发毫无帮助。 转发信带的是别人的 From；如果那个域发布了
p=reject（银行和大厂都会），那么不管你这边多干净，它在远端都会被挡。 - 中继有一个按域的前置条件。 一个域要走中继，就必须先在中继那边注册并验证它为寄件人。这是每个域永远多出来的一步，且与你自己的 DNS 里的一切无关。
如果重来一次
- 在建域之前先定：要信箱还是要转发。 转发是「必须成立的条件」最长的那条路；收件侧 POP 拉取几乎没有条件。
- 在向任何人承诺邮件之前，先查发信 IP 的反向记录。 一次反向查询就能告诉我接下来会撞上哪堵墙。
- 把「收件侧拉取」当一等设计，而不是权宜之计。 「这封信根本不用离开我的服务器」一次消掉三大类故障。
- 把那四条收信记录当成一张清单。 那一半很无聊、可验证，而且是唯一一次就通的部分。
