VPSCrypto
邮件从你的服务器发出，日志显示 250 2.0.0 Ok，结果还是进了垃圾邮件文件夹。没有任何环节报错。也不会有任何东西告诉你到底哪里出了问题，因为接收网关没有义务自证清白，而且它有充分的动机保持沉默 — 解释过滤规则，等于是在教人怎么绕过它。正是这种沉默，让自建邮件显得无从下手，也是为什么大多数人撑不过两周就放弃，转而花钱让别人代替自己去获得信任。
问题的修复，几乎从来都不在邮件服务器本身。它在于四条 DNS 记录 — 其中一条你在自己的注册商那里根本没法设置 — 也在于你拿到手的这个 IPv4 地址的历史，一段不是你写下的、通常你也看不到的历史。所以这份指南把记录放在前面讲，软件放在后面：每一条记录到底向网关证明了什么、那条会不动声色地拖垮看起来完全正确的配置的对齐规则、如何拿到一条双向都能对上的 PTR，以及如何给一个还没人为它担保过的地址做预热。然后是教程通常会漏掉的部分 — 自建邮件真正能带给你什么，以及它带不来什么。
为什么自建邮件会进垃圾箱，而这几乎从来都不是软件的问题
Postfix 不是问题所在。它从 1998 年起就一直称职地投递邮件，你怎么配置，它就会精确地照做。真正的问题在于，SMTP 默认不赋予任何人天然的信任地位，所以接收网关必须自己判断要不要相信一台陌生的服务器 — 而它是按一个固定的顺序做这个判断的，其中大部分环节，都发生在你的邮件内容被检查之前：
- 连接方的 IP，第一关，也是最难过的一关。在你的服务器说出
EHLO之外的任何内容之前，网关就已经拿这个地址去查过公开黑名单（Spamhaus 的SBL、XBL、PBL和CSS，还有 Barracuda、SpamCop），也查过它自己的私有声誉库，这个库还会一并追踪周边的/24网段和 ASN。一个上了名单的地址，会在连接阶段就被拒绝，如果没人在看日志，你可能永远都不会看到这次拒绝。 - 那个地址自称的名字。缺少
PTR记录，会被好几家大型服务商直接拒绝连接。一个ip-203-0-113-10.example-host.net这种服务商默认分配的通用PTR，比看起来还要糟糕 — 这正是消费者线路和无人看管的主机的典型特征，而那正是僵尸网络生存的地方。 - 身份认证。依次是 SPF、DKIM，然后是 DMARC，并按下一节讲到的对齐规则组合判定。看起来纸面上完全正确的配置，通常就是在这一关栽跟头。
- 只有到了这一步，才轮到邮件内容本身。内容启发式规则、邮件列表的卫生状况、你产生的投诉率，以及接下来几周收件人的行为表现。
这四关里有三关，在你内容里的哪怕一个字节被打分之前就已经见分晓，这让整件事的性质变了：你不是在写更好的邮件，你是在搭建一份凭证。两家最大的收件方已经把最低门槛白纸黑字写了下来，所以这条底线不需要猜。每一个发件人都需要 SPF 或 DKIM、有效的正向与反向 DNS、连接上的 TLS，以及低于 0.3% 的垃圾邮件投诉率；任何批量发送的邮件，还需要 SPF 与 DKIM 与一条经过对齐的 DMARC 记录，外加一键退订。把这当成入场费，而不是终点。
四条记录，以及它们各自到底证明了什么
每一条记录回答的是一个不同的问题，记住它们最管用的方法，是想一想伪造者要控制住什么，才能把它们全部伪造出来。
- PTR — 地址的所有者认同你。一个 IP 的反向区域，委派给持有这段地址分配的那一方，这也是为什么这是唯一一条你没法在自己的注册商那里添加的记录。
PTR指向mail.example.com，再加上一条A记录把mail.example.com指回同一个 IP，两者合起来就是FCrDNS — 正向确认的反向 DNS。它证明地址持有者和域名持有者是同一方，至少也是彼此认识、说得上话的关系。 - SPF — 这台服务器被允许为这个信封发信。一条
TXT记录，列出了被允许为某个域名发信的主机。这里的陷阱在于范围：SPF 认证的是信封发件人（也就是MAIL FROM，它会变成Return-Path）以及HELO名称。它对收件人实际会读到的From:头，完全只字未提，这也是为什么单凭 SPF，从来挡不住任何人冒充你。 - DKIM — 这条消息由某个域名签署，且未被篡改。你的服务器用一个私钥对选定的头部和邮件正文签名；公钥的那一半，放在 DNS 里的
<selector>._domainkey.<domain>位置。和 SPF 不同，它经得住转发，因为这份证明是随邮件本身一起走的，不依赖是哪个 IP 完成了投递。 - DMARC — 而这正是大家最容易弄错的一条。DMARC 要求的不只是 SPF 或 DKIM 通过。它还要求通过的那个机制，必须对齐到邮件里可见的
From:头里的域名。宽松对齐接受匹配到同一个组织域名即可（所以mail.example.com能和example.com对齐）；严格对齐则要求完全一致。
这条对齐规则值得单独拎出来说，因为它制造了自建邮件领域里最让人抓狂的一类支持帖：一封邮件可以通过 SPF、通过 DKIM，却依然在 DMARC 上失败 — 原因是两项通过验证的，是一个并非 From: 头里那个域名。这种情况，会在邮件经由一个改写信封的中继发出时发生，也会在某个套件用它自己的主机名、而不是你的域名去签名时发生。日志里看起来一片绿色，邮件却依然被隔离。要看的是对齐情况，而不是通过与否。
开始之前，你需要准备什么
所需的硬件比你猜想的要少，需要投入的心力却比你希望的要多。
- 一个你打算长期持有的域名。声誉附着在域名上的牢固程度，不亚于附着在地址上，而且要靠好几个月慢慢积累。一个你明年可能就会放弃的域名，不值得为它做预热。
- 一套适中的套餐，按过滤而不是按收发邮件的规模来选。投递邮件本身几乎不耗资源；耗内存的是垃圾邮件过滤和索引。Cub（1 vCPU / 2 GB / 40 GB NVMe，$5.00/mo）运行 Postfix、Dovecot 和 Rspamd，撑起一个域名和为数不多的几个邮箱，毫无压力。Scout（2 vCPU / 4 GB / 70 GB，$9.00/mo）是一套还想装上 ClamAV 和搜索索引的容器化方案能诚实撑住的底线配置。磁盘是会持续增长的部分，所以要按存档的规模来配置，而不是按今天的用量。
- 一个没有历史记录的专属 IPv4，外加一段路由到你的 IPv6 /64。每个套餐都自带这两样。这是一个日后没法靠配置去弥补的部分，也是回收利用的廉价云地址对邮件服务器来说其实并不划算的原因。
- 出站 25 端口。每个套餐都默认开放，无需提交解封工单。可接受使用政策禁止未经请求的批量邮件和开放中继，而这恰恰是让这些地址段对每一个正当发件人都保持可送达的原因。
- 从模板库选择 Debian 13，并刻意挑选司法辖区。邮件对延迟并不敏感，所以选位置时，要考虑这个邮箱在法律上应该落在哪里，而不是那几毫秒的差距。
老老实实地挑一套技术栈
有三种形态，选错一种，就是周末凭空消失的方式。
- 手工搭建。Postfix 作为 MTA，Dovecot 负责 IMAP 和身份验证，Rspamd 负责过滤和 DKIM 签名。总共大概两百行配置，每一行你都能读懂，没有一行是藏起来的。掌控力最强，需要理解的东西也最多，这也是这份指南默认采用的版本。
- 一体化套件。mailcow 功能齐全、基于容器，想要跑得舒服，是真的需要 4 GB 内存。Mail-in-a-Box 主张鲜明，只要你完全接受它的选择，用起来就很省心。Stalwart 是一个单一二进制程序，把 SMTP、IMAP、JMAP 和过滤全部塞进一个进程里，也是三者里遥遥领先的最轻量的一个。它们全都能在一小时内装好；但没有一个会替你把 DNS 也配好。
- 一个你自己不运行的中继。如果需求只是“我的应用需要发密码重置邮件”，而且永远不会有邮箱这种东西，那 MTA 从形态上就完全选错了。配置一个 smarthost，把这个下午留给别的事。
技术栈本身，决定不了你的送达率。它决定的是要花掉你多少个周六。真正决定你的邮件能不能送到的，是 DNS，以及一个地址的声誉 — 这正是下一节要讲的全部内容。
分步操作
- 先定一个主机名，把正向 DNS 先配置对
给服务器选一个统一的规范名称 —
mail.example.com是常见写法，没必要另出心裁。发布它的A记录（如果你会通过 IPv6 发信，也发布AAAA），指向你的 VPS，然后把域名的MX指向这个名称。MX必须指向一个主机名，绝不能是 IP 字面量，也绝不能是CNAME；拒绝后者的网关完全在其权利范围之内，而且确实有几家这么做。dig +short A mail.example.com dig +short AAAA mail.example.com dig +short MX example.com要在申请 PTR 之前做这件事，而不是之后。反向 DNS 是双向验证的，一条指向一个尚未能解析的名字的
PTR，比压根没有PTR还要糟糕。 - 部署、加固，并让系统主机名保持一致
从模板库部署 Debian 13，在任何东西监听公网端口之前，先按惯例花上十分钟做基础加固：只用密钥登录 SSH、禁用 root 密码登录、nftables 默认拒绝、开启无人值守安全更新。然后把主机名设置成你刚刚发布的那个名称，因为你的 MTA 宣告的
HELO，应该和你即将申请的PTR保持一致。hostnamectl set-hostname mail.example.com hostname -f apt update && apt full-upgrade -yhostname -f必须打印出完整名称。如果打印出来的是短名称，就把完全限定名加进/etc/hosts，放在短别名前面。然后只打开邮件真正需要的端口：25入站用于服务器间投递，587和465用于你自己的身份验证提交，993用于基于 TLS 的 IMAP。 - 申请 PTR 记录，然后双向验证这个闭环
反向区域归持有这段地址分配的一方所有，所以这是一次申请，而不是一次 DNS 编辑：在客户区为你的专属 IPv4 申请
PTR，如果你打算用 IPv6 发信，也为你将用来发信的那个具体 /64 地址申请一个。这不花钱，而且一小时内就能生效。然后确认这个闭环真的合上了：dig -x 203.0.113.10 +short dig +short mail.example.com第一条命令必须返回
mail.example.com，第二条必须返回203.0.113.10。这种一致，就是 FCrDNS，也是你其余身份验证被评判时所依据的基线。每个地址只设置一条PTR— 给一个 IP 挂多个名字，是一种会让网关困惑、而不是让它印象深刻的过时做法。如果你没法把 IPv6 的 rDNS 理清楚，就把出站投递只绑定到 IPv4 上；两家大型收件方对 v6 的把关明显更严格，一个没有匹配PTR的地址发出的 v6 邮件会被直接拒绝，而对应的 v4 邮件顶多只是被扣分。 - 发布 SPF，并把查询次数控制在十次以内
在域名顶点放一条
TXT记录，列出允许为它发信的主体。同一个域名上有两条 SPF 记录，结果是永久性错误，而不是自动合并，所以在添加自己的记录之前，先检查是否已经存在一条。example.com. IN TXT "v=spf1 mx -all"mx会授权你的MX解析到的任何主机，也就是你刚搭建的这台服务器。要遵守的约束是：SPF 在求值过程中最多只允许十个会触发 DNS 查询的条目：每一个a、mx、include:和redirect=都算一次，而且每一条include:还会递归地消耗它指向目标所消耗的次数。超过十次，结果就是permerror，大多数收件方会把它当成完全没有 SPF 处理 — 这是因为多接入一个厂商就把身份验证彻底搞垮的典型翻车方式。在你还在摸排哪些系统会代表你发信的阶段，先用
~all（软失败）；等你的 DMARC 报告已经安静了两周之后，再换成-all（失败）。用这个来验证：dig +short TXT example.com - 生成一个 DKIM 密钥，并发布选择器
2048 位 RSA 是稳妥的默认选择。给选择器起名字时，要考虑到以后轮换的可能性 — 一个基于日期的名字，比如
s2026a，现在不费什么事，却能在一年后省下一个尴尬的下午。mkdir -p /var/lib/rspamd/dkim rspamadm dkim_keygen -s s2026a -b 2048 -d example.com \ -k /var/lib/rspamd/dkim/example.com.s2026a.key chown _rspamd:_rspamd /var/lib/rspamd/dkim/example.com.s2026a.key这条命令会把公钥的那一半，打印成一条要发布在
s2026a._domainkey.example.com的TXT记录。一个 2048 位的密钥，放不进单条 255 字符的 DNS 字符串里，所以必须在同一条记录里拆成好几段带引号的字符串。大多数 DNS 管理界面会不动声色地正确处理这件事；少数不会，结果就是一个看起来已经发布、却怎么也验证不过的密钥。确认一下外界实际看到的是什么：dig +short TXT s2026a._domainkey.example.com - 分三个阶段推行 DMARC，不要一步到位
从观察模式开始。这时策略本身还什么都不做；重点全在报告上。
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"把它留在
p=none两到四周，并且真的去读收到的聚合报告 — 它们是 XML 格式，用一个查看器几秒钟就能读懂。你要找的是那些被你遗忘的发信来源：开票系统、CRM、那个用你的域名发信的论坛。在你收紧任何设置之前，每一个这样的来源都需要被授权，或者被迁移掉。然后再往上升级：先
p=quarantine; pct=25，随着报告持续干净逐步扩大百分比，最后才是p=reject。第一天就直接跳到p=reject，是人们付出昂贵代价、当众发现自己的账单平台其实从来没有对齐过的典型方式。取证报告（ruf=）出于隐私原因，基本上被各大收件方忽略，所以不要建一套依赖它们的流程。 - 安装这套技术栈，先关闭中继，再打开端口
安装 Postfix、Dovecot 和 Rspamd — 或者你选定的那套一体化方案 — 然后，在任何东西真正面向公网之前，先解决这一个决定你的地址能不能撑过这一周的问题。
25端口必须只为你托管的域名接收邮件。所有出站邮件都必须走587或465上经过身份验证的提交。在 Postfix 里，这只是一行配置，但顺序很关键：smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination然后从互联网上别的地方去验证它，因为在服务器自己身上测试开放中继，什么都证明不了：
swaks --to postmaster@example.org \ --from probe@example.net \ --server mail.example.com你想看到的结果，是这次尝试被以拒绝中继访问的方式拒绝掉。一个开放中继会在几个小时之内就被扫描器发现，永久性地烧掉这个地址，也正因为如此，可接受使用政策才明令禁止开放中继。
- 像网关那样去测试，然后开始预热
给你在各家大型服务商那里自己掌控的账号，发一封真实邮件，然后去读它到达之后的完整邮件头，而不是去相信一个十分制的评分。
Authentication-Results头，就是收件方在明确告诉你它到底得出了什么结论：Authentication-Results: mx.google.com; dkim=pass header.d=example.com; spf=pass smtp.mailfrom=example.com; dmarc=pass (p=NONE) header.from=example.com三项全部通过是必要条件，但还不够 — 域名也要一并核对。
header.d、smtp.mailfrom和header.from全都指向同一个组织域名，这才是对齐生效时该有的样子。如果dmarc显示fail，而 SPF 和 DKIM 却都显示pass，你找到的就是前面说过的那种不对齐，修复方法就在那个格格不入的域名身上。确认这些都干净之后，如果想要更现代化的完善度，可以再加上 MTA-STS 和 TLS-RPT，然后就可以真正开始发信了 — 小规模、保持稳定，发给那些会回复你的人。
给一个还没人担保过的地址做预热
一个没有声誉的地址，起点并不是中立的。对于一个此前默默无闻、忽然开始发信的数据中心 IP，网关的先验判断更接近于“八成不受欢迎”，因为这类地址里，绝大多数最终确实就是如此。预热，就是用实际证据去替换掉这个先验判断的过程，任何技术手段都没法让它提速。
- 从小规模起步，缓慢爬升。第一周每天几十封，大约每隔几天翻一倍，两到四周后达到正常量级。一个发件方如果一夜之间从零冲到上千封，就和一台被攻陷的主机没法区分，也会被当成那样对待。
- 互动比数量更重要。被真人打开、回复，并从垃圾箱里移出来的邮件，其价值远远超过单纯的吞吐量。优先发给最可能与你互动的收件人 — 你自己、同事，以及已经认识你的联系人。
- 保持稳定。某一天发两百封、接下来三周什么都不发，永远建立不起稳定的画像。细水长流，胜过总量相同却忽高忽低的爆发式发送。
- 把投诉率控制住。官方公布的门槛是 0.3%，一旦超过，你做的其他事情就都没那么重要了。真正该待的区间，是 0.1% 以下。
- 不要把不同的邮件流混在一起。通讯简报和密码重置邮件用同一个地址，意味着营销邮件的投诉率，会把你的账户找回邮件一起拖进垃圾箱。如果把它们分开是值得的，再加一个专属的干净 IPv4 只需要 $2.00/mo，还带独立的 rDNS。
地址才是资产——把它挡在黑名单之外
配置一小时之内就能重新来一遍。声誉却要花上几个月积累，还可能因为一个被攻陷的联系表单，一个晚上就毁掉。把这个地址当成你真正要保护的东西。
- 主动监控，而不是被动应对。按计划定期检查那几家主要名单，而不是等投诉找上门才去看 — 我们那篇如何检查一个 IP 是否已被拉黑的实操讲解，讲清楚了哪些名单真正算数、该怎么解读一条上榜记录，以及移除记录到底是怎么运作的。
- 给自己的出站流量限速。MTA 里的一道上限，是挡在一个被攻陷的脚本和你醒来之前就已经发出一万封邮件之间的唯一屏障。这一项设置，救回的地址比任何过滤器都多。
- 硬退信要立刻停止投递。反复往一个已经失效的地址投递，是垃圾邮件陷阱的信号，而回收利用的垃圾邮件陷阱，正是正当发件人最终被拉黑上榜的典型方式。
- 要看
postmaster@和abuse@。它们是规定必须存在的地址，也是你能抢在黑名单之前先一步发现问题的地方。两家大型收件方都为已验证的域名提供免费的声誉仪表盘；上面会告诉你一些任何公开名单都不会讲的信息。 - 不要去打一场你继承来的仗。如果这个地址原来就带着一条早于你的上榜记录，或者在某个对生意有影响的地方被封了，那就直接去客户区申请更换，而不要为了别人的历史，在移除名单的排队队列里耗上三个星期。
地址一开始为什么是干净的，是这件事的另一半。周转率高的廉价云服务商，会把 IPv4 在数量庞大的短命客户之间循环利用，所以一个“新”地址，在网关真正在意的每一层意义上，往往到手时就已经是别人用过的了。这里的每个套餐配的都是专属的、经过筛查的地址，而不是共享地址池里的一小块 — 干净 IP 到底意味着什么讲清楚了这个定义，以及你在依赖它之前该如何自行核实。
自建邮件给不了你什么
这是一份诚实的说明，因为一份只列优点的指南，就是一份广告。
- 它不会让你的邮件变得私密。SMTP 只是逐跳加密，而且是见机行事式的加密；接收方服务商依然会解密并读取你发给他们用户的一切内容，和以前一模一样。如果目标是内容的保密性，那需要的是端到端加密，而不是一台你自己拥有的服务器。
- 它藏不住元数据。谁发的、发给谁、什么时候发的、发送频率如何，还有邮件主题，这些都会原封不动地穿过网络 — 而现在，你自己的服务器也会把它们记下来，记在一台由你自己负责的机器上。
- 它没法让你摆脱那几家大型收件方。你依然要请求那两家公司接受你的邮件，条款也依然由它们单方面制定。自建邮件服务器挪动的是控制点的位置；它并不会把这个控制点移除。
- 它不会自己运行下去。证书要续期，密钥需要轮换，磁盘会被写满，而一台悄悄停止接收邮件的服务器，会丢掉那些发件方不会永远重试下去的邮件。这是一项带有值守属性的服务，哪怕这份值守分量很小。
- 它不会让这台机器变得匿名。邮件服务器可以说是你能运行的东西里自曝身份色彩最重的一种，因为在 DNS 里公开你的域名、并为它背书，正是这套机制赖以运作的全部原理。无需 KYC 的注册方式限制的是主机商能知道你多少信息，对收件人能看到什么却无能为力。用加密货币付款的 VPS 真的匿名吗这篇里，我们把这中间的区别讲清楚了，值得在你想当然之前花十分钟读一下。
司法辖区、账户，以及不用银行卡付款
记录都配置妥当、地址也预热完成之后，剩下的问题就只关乎这个邮箱到底放在哪里、又有谁知道它是你的。
司法辖区决定的是谁能强制要求信息披露。邮件服务器是一份可被检索的往来通信档案，这让位置的选择在这里比在几乎任何其他服务上都更加举足轻重。我们的服务分布在荷兰、法国、罗马尼亚、保加利亚、瑞典、冰岛、瑞士和马来西亚这八个地点，没有一份美式的下架通知能在这些地方生效。这是明确陈述的运营政策，不是法律豁免 — 有管辖权的当地法院一旦下达具有约束力的命令，依然照样适用，也有一条我们绝不会挪动的滥用底线。离岸托管讲清楚了这中间的区别，不掺任何营销话术。
账户是人们最容易跳过的一环。注册只需要一个用来接收凭据的邮箱地址，仅此而已 — 不需要身份证明、不需要银行卡、不需要通信地址、也不需要电话号码。以后也不会有什么验证文件需要上交，因为从一开始就没有收集过；no-KYC 主机到底意味着什么老实交代了这里的边界。
还有付款方式。银行卡会把一台服务器和一份银行记录、一个真实姓名绑在一个我们谁都控制不了的数据库里。这里的结账在链上完成，Monero 是头等选项，而不是事后才想起来的备选：用 XMR 支付 VPS 费用讲清楚了整个流程，不用信用卡购买讲清楚了从零加密货币开始该怎么做。确认后大约六十秒即可完成部署。
这些事在这里，比在一台用完即弃的服务器上更要紧。邮件服务器是对一个域名、一个地址的长期承诺 — 你即将花上一个月去积累的声誉，是带不走的。把司法辖区、账户和付款方式都定下来，再开始预热，而不是反过来。
常见问题
出站的 25 端口是开放的，还是需要我自己去申请？
每个套餐都默认开放，无需提交解封申请，也没有观察期。换来的条件是可接受使用政策：不许发未经请求的批量邮件，也不许开放中继，这正是让这些地址段对其他所有正当发件人都保持可送达的原因。分配给你的 IP 是专属且经过筛查的，而不是从共享出站池里抽出来的，而这一点，是你日后没法再补办的。
SPF、DKIM 和 DMARC 全都通过了，我的邮件却还是进了垃圾箱，为什么？
因为身份验证证明的是谁发了这封邮件，而不是有没有人想要它。记录都配置对了之后，剩下的就是声誉：这个地址的年龄和历史、域名的年龄、你的投诉率，以及收件人是否会互动。在往最坏处想之前，先检查两件事。第一，对齐情况 — 一个针对错误域名显示绿色的 SPF，依然会让 DMARC 失败，所以要在收到的邮件头里，把 header.from 拿去和 smtp.mailfrom、header.d 做比对。第二，你是不是真的给这个地址做过预热，因为一套正确的配置，在发出它头一百封邮件的时候，依然只是一个未知的发件人。
只是发邮件，真的有必要用专属 IP 吗？
只要是要紧的用途，答案就是有必要。在共享出站上，你会连带继承每一个邻居的投诉率，以及他们招来的每一条上榜记录，而且没有办法把你的流量和他们的分开。这里的每个套餐都包含一个带自定义 rDNS 的专属干净 IPv4，以及一段路由到你的 IPv6 /64；如果你想把事务性邮件和批量邮件分开，第二个地址是 $2.00/mo。唯一的例外，是那种量确实很小、也没有送达率要求的场景，这时用中继确实更省事。
预热一个新地址需要多长时间？
对一个小规模发件方来说，达到正常量级需要两到四周，而爬升的节奏比总量更重要。从每天几十封开始，大约每隔几天翻一倍，优先照顾那些会打开、会回复的收件人，而不是那些只是被动接收的。稳定胜过爆发 — 每天细水长流能建立起稳定的画像，而同样的月总量如果在一个下午之内发完，就建立不起来。
我是不是干脆用中继或者 smarthost 就好了？
很多时候，确实如此，这一点值得老实承认。如果需求只是一个应用程序的出站通知，而且你永远不会需要一个邮箱，那 smarthost 用一小部分的工夫，第一天就能做得更好。想拥有的是邮箱和存档本身，而不只是一个 SMTP 套接字时，才该自建。混合方案同样站得住脚：自己运行服务器负责接收和 IMAP，出站邮件通过一个成熟的发件方中继，等地址预热完成后，再把发信这部分也搬回自己手上。
IPv6 上也需要反向 DNS 吗？
只有在你通过 IPv6 发信时才需要 — 但只要你这么做了，它就不是可选项。大型收件方对 v6 施加的规则明显更严格，一个没有匹配 PTR 的地址发出的 v6 连接会被直接拒绝，而对应的 v4 邮件顶多只是被扣分。你名下路由 /64 上的 PTR，在客户区申请是免费的。如果维护正确的 v6 rDNS 超出了你想投入的精力，那就把出站投递只绑定到 IPv4 上，v6 只留给入站用。
把现有邮件服务器迁移过来，还能保住我的声誉吗？
域名的声誉会跟着你走；IP 的声誉不会，因为它属于你正要留下的那个地址。要按第二次预热来规划，而不是一次性切换：先把新服务器立起来，让 FCrDNS 和身份验证都通过，然后在两周时间里分批把发信量转移过去，同时让旧的发件方继续保持在线。整个迁移期间，把 DMARC 维持在 p=none 或 quarantine，只有等新地址的聚合报告变干净之后，才重新调高。
