自建企业邮箱用VPS怎么选：送达率与IP信誉

一、自建邮箱的成败不在配置，而在IP信誉

自建邮箱VPS 的配置门槛其实很低，两核两 G 内存跑 Postfix 加 Dovecot 绰绰有余，真正卡住你的从来不是机器算力，而是这批公网 IP 在收件方眼里被归到了哪一类。Gmail 判定一封邮件进不进垃圾箱，权重最高的三项依次是发信 IP 的历史行为、认证信息是否齐全一致、以及 PTR 反向解析与 HELO 声明能否对上。所谓送达率，指的是发出的一万封信里有多少进了收件箱而不是垃圾箱，这个数字从百分之九十几掉到百分之五十，通常只需要一次集中的群发行为。

延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。

IP 信誉是历史积累出来的，所以它有明显的冷启动阶段。新购的 IP 在头两三个月里往往是最干净也最不被信任的——干净的含义是还没有发过一封垃圾邮件，不被信任是因为收件方的信誉库对它没有任何正面记录。新 IP 冷启动最稳妥的做法是从最普通的双向沟通邮件开始，把量压在每天几十封，连续跑上几周，再逐步加上事务性通知类邮件。反过来，任何一台新机器上线当天就推送几千封营销邮件，几乎必然把 IP 直接推进黑名单。

决定信誉权重的除了有没有发过垃圾邮件，还有行为特征。收件方会统计这个 IP 的退信率、投诉率、发信速度和收信人的打开互动情况。退信率是最容易被忽略的一项，因为退信是收件方服务器的直接反馈，退信率超过百分之三就会触发对方的速率限制，超过百分之十基本会被判定为无效发信源。所以在系统里一定要接一个退信处理器，把硬退信和软退信区分开，硬退信立刻把地址拉黑不再发，软退信则重试几次后移出。

投诉率的影响比退信率更致命，因为投诉是收件人主动点的举报，一次真实的用户投诉造成的信誉扣分，通常要靠上百封正常邮件的正面反馈才能抵消。这也是为什么面向个人用户的促销邮件最容易出事，收到促销邮件的收件人随手点一下举报，比退信带来的伤害大得多。

真正安全的发信模式是让收件人主动订阅。用户在网站或应用里主动填写邮箱并勾选接收通知，这类地址的投诉率天然接近零，因为收件人自己期待这封信。营销邮件最稳妥的做法是只发给明确订阅过的人，而不是买名单。

退信处理这件事必须落到脚本里，靠人肉查日志迟早会漏。硬退信对应 5.x.x 状态码，表示地址根本不存在；软退信对应 4.x.x，表示临时问题，重试几次可能成功：

# 从 Postfix 日志里提取退信地址，做成待处理名单
grep -oP '(?<=<)[^>]+(?=>:.*[45]\d\d)' /var/log/mail.log | sort -u > /tmp/bounced.txt

# 统计硬退信和软退信各占多少，硬退信占比高说明名单质量差
grep -c 'status=5' /var/log/mail.log; grep -c 'status=4' /var/log/mail.log

# 把硬退信地址写进 Postfix 的停用列表，之后不再尝试投递
postmap /etc/postfix/virtual_bounce && postconf -e 'bounce_service = virtual_bounce'

一个务实的做法是定期跑一次这段统计，把硬退信地址从订阅库里剔除并记入黑名单，软退信地址保持重试但设置上限。整个流程跑顺之后，一个新 IP 的冷启动期能在两周内把退信率压到百分之一以内。

二、PTR反向解析：收件方的第一道关卡

PTR 也就是 IP 反向解析记录，它把 IP 地址还原成主机名，是收件方做合法性校验的第一个动作。正常流程是这样的：你的服务器以 mail.example.com 为主机名发送邮件，收件方服务器拿到来源 IP 后反查一次 PTR，必须得到 mail.example.com，然后再拿这个结果去正向解析一次 DNS，确认它确实指回同一个 IP。两个方向都对得上，才叫正反向解析一致。

延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。

这一步失败，后面的 SPF 和 DKIM 再完美也没用，因为 SPF 校验的前提是收件方能拿到合法的 MAIL FROM 域名并解析它的 A 记录，而很多 MTA 在这一步发现 PTR 缺失就直接记为失败。实际排查时可以用 dig 反查：

# 反查你的发信 IP，看 PTR 记录指向什么主机名
dig -x 你的服务器IP +short

# 再把上面得到的主机名正向解析，确认指回同一个 IP
dig +short mail.example.com A

# 检查是否有多余的 PTR 记录，很多机房一个 IP 会返回多个结果
dig -x 你的服务器IP +short | wc -l

判断标准很明确：反查结果只有一条、正向解析唯一指回该 IP、且这个主机名就是你 HELO 里声明的那个，三者一致才算合格。要注意的是主机名不要用 IP 字符串形式，不要用默认的 mail.example.net 之类模板名，更不要用和任何托管品牌无关的杂乱前缀，因为 PTR 里的主机名会进入收件方的信誉打分，命名规范本身就是一种信号。

# 在 Postfix 里显式声明本机的主机名和发信域名，别让它用系统默认
postconf -e 'myhostname = mail.example.com'
postconf -e 'mydomain = example.com'
postconf -e 'myorigin = $mydomain'
postconf -e 'smtpd_banner = $myhostname ESMTP'

改完重启 Postfix 再发一封测试信，收件方服务器端的日志里如果能看到反向解析成功的记录，这一步才算真正落地。

除了主机名本身，rDNS 记录的 TTL 值也有讲究。默认的 PTR 记录 TTL 往往是一万八千四百秒，也就是四十八小时，这个值太长。原因是历史上很多管理员在迁移服务器时忘了同步修改 rDNS，结果邮件以旧主机名发出，在收件方看来就是一次身份不一致。所以正确做法是把 TTL 设成 3600 秒甚至更低，这样你后续改主机名时，记录能在两小时内生效，不至于出现新旧主机名长期并存的状态。

# 把 rDNS 记录的 TTL 设成 3600 秒，改主机名后一小时内生效
# 这条命令需要在商家提供的 rDNS 面板或自助 API 上执行
# 命令行的等价效果是提交一条 PTR 变更，并指定 TTL
echo "提交 rDNS 变更：主机名 mail.example.com -> 203.0.113.10，TTL 3600"

# 确认改完之后新解析已经生效，注意要等 TTL 过期
dig -x 203.0.113.10 +short @1.1.1.1
dig -x 203.0.113.10 +short @8.8.8.8

两个不同的公共 DNS 都返回同一个主机名，才说明记录在各条解析链路上都同步了。如果 1.1.1.1 返回新值而 8.8.8.8 还是旧值，说明变更还在传播途中，这时候发信会导致一部分收件方看到旧主机名。

还要注意 HELO 声明与 PTR 必须一致。如果你的 Postfix 配置里的 myhostname 是 mail.example.com，但收件方反查 PTR 得到的是 mail-01.provider.net，虽然正向解析也指向同一台机器，收件方仍然会记为不一致并降低评分。所以 myhostname 这个值必须和 rDNS 里填的一模一样，不能一个写 FQDN 一个写短名。

# 确认 Postfix 实际对外声明的主机名
postconf myhostname
# 发一封测试信，从日志里看它用的是哪个 HELO 名
grep "Hello" /var/log/mail.log | tail -5

日志里出现的 Hello 一行应当和 dig 反查的结果一字不差。如果不一致，改 postconf 里的 myhostname 后重启服务，再重新测试。

三、SPF、DKIM、DMARC三条认证链怎么落地

自建邮箱VPS 的认证体系由三层组成，缺一层不会致命，但少一层会明显掉分。SPF 是域名级的白名单声明，告诉收件方哪些服务器 IP 有权代表你的域名发信；DKIM 是邮件级的数字签名，每封邮件在发出去前用私钥对头部和正文签名，收件方用 DNS 里公布的公钥验证；DMARC 是把前两者的失败结果回报给你的机制，同时告诉收件方遇到验证失败的邮件该怎么处理。

延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。

这三者的关系是逐层收紧。SPF 通过但 DKIM 失败，收件方会看 DMARC 策略是 p=none 还是 p=quarantine。p=none 只是把报告发给你，邮件照发但可能进垃圾箱；p=quarantine 会要求收件方把它当可疑处理；p=reject 则直接拒收。刚开始建议用 p=none 跑一两周收集报告，确认 SPF 和 DKIM 都能百分之百通过后再收紧。

SPF 有个硬限制，一条 SPF 记录里 DNS 查询次数不能超过十次，所以不要写超过十十个 include 机制。同时 SPF 要覆盖你所有发信路径，包括第三方营销平台和工单系统，用一条 spf 记录把它们全部列进去：

# 生成 SPF 记录：授权你自己的邮件服务器，同时带上第三方发信平台
# 注意 include 总数控制在 10 次查询以内，超了会导致 permerror 直接判定失败
v=spf1 ip4:203.0.113.10 include:_spf.yourmarketing.example -all

# 检查记录是否生效，并统计 include 次数
dig +short example.com TXT | grep spf1
dig +short example.com TXT | grep -o 'include:' | wc -l

DKIM 的配置关键在于密钥长度用 2048 位，并且私钥只留在服务器上、公钥只放 DNS。用 Postfix 的 opendkim 走一遍：

# 安装并生成 2048 位密钥对
sudo apt install opendkim opendkim-tools
sudo opendkim-genkey -D /etc/opendkim -d example.com -s selector1

# 把生成的公钥内容写成 DNS TXT 记录（内容是 p=... 开头那一段）
cat /etc/opendkim/selector1.txt

# 配置 Postfix 通过 milter 调 opendkim 签名
postconf -e 'milter_mail_macros = {i} {d } {s } {srs}'
postconf -e 'milter_protocol = 6'
postconf -e 'milter_default_action = accept'
postconf -e 'smtpd_milters = inet:127.0.0.1:8891'
postconf -e 'non_smtpd_milters = inet:127.0.0.1:8891'

# 改完重启两个服务，然后检查签名头是否真的加上了
sudo systemctl restart opendkim postfix
echo "test" | sendmail -f no-reply@example.com someone@gmail.com

验证方式最直接的是把发出去的信拖回本地看原始头，DKIM-Signature 头应该在，并且 d 和 s 两个字段对应你 DNS 里的选择器与域名。如果头里没有这个字段，说明 milter 没有接上，常见原因是 inet:127.0.0.1:8891 这行写成了 inet:localhost:8891 导致解析差异，或者 opendkim 的 User 权限读不到密钥文件。

DKIM 还有一个常被忽略的细节是邮件正文在签名后不能再被修改。主题里的表情符号、邮件客户端自动加的免责声明、某些企业网关追加的免责声明，都会导致签名失效。判断方式是检查 DKIM-Signature 里的 bh 参数，它是对正文的哈希值，如果正文被动过，这个值就对不上了。规避办法是在 Postfix 里做签名，把签名动作放在所有内容改写之后：

# 让 milter 在队列阶段完成签名，确保最终发出去的正文和签名一致
postconf -e 'milter_default_action = tempfail'

# 检查当前 DKIM 签名器的选择器与密钥路径，确认和 DNS 里的公钥对应
grep -E '^\s*(KeyTable|SigningTable|Canonicalization)' /etc/opendkim.conf

# 用 opendkim 自带的测试工具验证一封已签名邮件能否验签通过
opendkim-testmsg -d example.com -k /etc/opendkim/selector1.private -s selector1

DMARC 记录本身很简单，核心是 p 值和 rua 报表地址：

# p=none 先观察，rua 接收聚合报表
# 收紧时改成 p=quarantine 或 p=reject
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com; fo=1; pct=100"

# 查看收到的报表文件，统计主要失败原因
ls -lt /var/mail/dmarc-reports/ | head
grep -h 'type' /var/mail/dmarc-reports/*.xml | sed -E 's/.*type="([^"]+)".*/\1/' | sort | uniq -c

报表里如果 type 是 spf 或 dkim 占比高，说明认证链某一环还没通；如果 alignment 对齐失败，说明发信域名和 From 头里的域名不一致，需要检查 From 域名的写法。

四、25端口被封之后，邮件还怎么发出去

自建邮箱VPS 最现实的一道门槛是出站 25 端口。绝大多数云服务商出于反垃圾的考虑，默认封禁 25 端口，且大多数不提供免费解封。这不是配置问题，是政策问题，买再好的机器也一样。所以选型第一步就要确认商家是否放行 25 端口、是否允许申请解封。

延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。

判断方法很简单，在拿到机器后直接测：

# 测试出站 25 端口是否连通，超时或拒绝都说明被封
timeout 8 bash -c 'cat < /dev/null > /dev/tcp/你的服务器IP/25' && echo "25端口开放" || echo "25端口被封"

# 再测 587 提交端口，多数商家这个端口是放行的
timeout 8 bash -c 'cat < /dev/null > /dev/tcp/你的服务器IP/587' && echo "587可用" || echo "587不可用"

# 用 telnet 看看服务端的问候语长什么样
echo quit | timeout 8 telnet 你的服务器IP 25

端口被封之后有三条路可走。第一条是换商家，找明确写着支持邮件服务器、开放 25 端口的商家，这是最省事也最长期正确的做法。第二条是走中继发信，本机只负责收信和撰写，实际外发交给 SMTP 中继服务商，这条路的送达率取决于中继服务商的 IP 池质量，本机 IP 的信誉就不那么重要了。第三条是走 587 端口提交给中继，这是现在最通用的做法，Postfix 里配置一个中继账户作为 smarthost 即可。

# 配置中继提交：把外发交给中继服务商，本机只做队列和本地投递
postconf -e 'relayhost = [smtp.你的中继服务商.com]:587'
postconf -e 'smtp_sasl_auth_enable = yes'
postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
postconf -e 'smtp_sasl_security_options = noanonymous'
postconf -e 'smtp_tls_security_level = encrypt'
postconf -e 'smtp_use_tls = yes'

# 写入中继账号密码并生成映射表，权限必须设为 600
echo '[smtp.你的中继服务商.com]:587 mail@example.com:你的中继密码' > /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo systemctl restart postfix

第三条路的代价是每封邮件多付几分钱到一毛钱的中继费，具体以服务商官网当日报价为准，而且本机的 IP 信誉从此不再影响送达率，只影响中继侧对它的信任权重。

还有一件事必须在换机器之前问清楚：商家是否对 25 端口做了流量级限制。有些商家虽然名义上开放 25 端口，但会限制每小时的发信数量，比如每小时不超过两百封，超过就直接丢弃连接而不是拒绝。这种限制在正常使用时看不出来，一旦要做批量导入就立刻暴露。问的时候要明确问每小时上限和每日上限，不要只问开没开。

# 连续发信测试，观察中途有没有被掐断，用 30 封连发能测出速率限制
for i in $(seq 1 30); do
  echo "rate test $i $(date +%T)" | mail -s "rate $i" -r no-reply@example.com test@你自己的收信地址
done

# 统计这批邮件里有多少成功进入队列并被对方接受
grep -c "status=sent" /var/log/mail.log | tail -1

如果三十封只成功了二十来封，剩下的停在队列里并且日志里出现 connection timed out，那就是撞上了速率限制。

另外一个现实问题是 STARTTLS 的兼容性。有些老旧的中继或收件服务器不支持 STARTTLS，Postfix 默认在加密失败时会降级为明文继续发送，这会造成凭据裸奔。生产环境应该直接禁止降级：

# 禁止明文回退，TLS 握手失败就报错而不是继续明文投递
postconf -e 'smtp_tls_security_level = dane'
postconf -e 'smtp_tls_loglevel = 1'
postconf -e 'smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1'

# 接收端同样要求 TLS，禁用明文 AUTH
postconf -e 'smtpd_tls_security_level = may'
postconf -e 'smtpd_tls_auth_only = yes'
postconf -e 'smtpd_sasl_auth_enable = yes'

五、共享IP的连带惩罚：为什么一个人作恶你会一起挨打

自建邮箱VPS 最容易踩的坑是买了共享 IP 的套餐。同一台服务器上可能有几十上百个用户共用同一个公网 IP，机房出口 IP 更是被上万个客户共享。收件方的信誉库是按 IP 记录的，一旦其中一个用户群发垃圾邮件，这个 IP 就进了黑名单，所有共用它的用户跟着一起进垃圾箱，且没有任何申诉渠道。

延伸对照：justg 的公开机型与线路说明，可结合本节的判断标准自行核对。

判断一台机器是不是共享 IP，看三处。第一是问商家要这个 IP 之前的使用记录，多数正规商家会说明是否曾被拉黑。第二是查这个 IP 段在常见黑名单里的记录，注意要用自己的 IP 去查自己的段，不要查到别人的隐私。第三是观察实际表现，如果同一个 IP 上有多个域名在发信且收件方抱怨多，那基本可以确认是共享。

更隐蔽的共享是同一机房多个虚拟机的出口 NAT 共用一个 IP 段。这种情况下，即使你买的是独享 IPv4，只要机房整体信誉差，你的邮件依然受影响。规避办法是优先选支持自定义 PTR 的大商家，因为能改 PTR 通常意味着这是给你分配的独立地址而不是从一个大池子里随机捞一个。

# 检查本机出口 IP，确认是不是你以为的那个
curl -s https://api.ipify.org; echo

# 用 dig 反查出口 IP 的 PTR，判断是否指向一个随机模板名
dig -x $(curl -s https://api.ipify.org) +short

# 反查网段内其他 IP 的 PTR 数量，模板化程度高说明是共享池
for ip in 203.0.113.{1,2,3,10,50,100}; do echo -n "$ip -> "; dig -x $ip +short; done

一个实用的经验是：如果反查得到的 PTR 在多个 IP 上长得高度相似且是随机字符串，那就是共享池，不要拿它发邮件。

共享 IP 的另一个副作用是退信地址的连带影响。一个共享 IP 上的其他人发信失败，本机收不到任何通知；但反过来，你这边发信失败会被整个 IP 段的信誉拖累，运营商层面的黑名单也是整个段生效。所以共享 IP 环境下，你的送达率本质上取决于一群陌生人的行为，这在概率上是个负和游戏。

更稳妥的替代方案是购买那些明确标注独享 IPv4 的套餐，或者选择提供 rDNS 自助修改的商家。判断标准很简单：在下单页或客服回复里确认这个 IP 是否只分配给你一个客户，并且是否允许你把 PTR 改成自己的域名。如果客服说不清楚，这就是风险信号。

还有一个折中方案是双 IP 策略：主 IP 专门发信且严格控制发信行为，备用 IP 承接发信失败后的重试。这样主 IP 被限速时还能有回旋余地，不过多数商家不会给单台机器配多个 IP，这个方案更适合有一定规模后再考虑。

# 检查这台机器上一共有几个公网 IP，以及各自的网络出口
ip -4 addr show | grep inet

# 查看当前 Postfix 实际在用哪个 IP 出站
postconf -e 'smtp_bind_address = '   # 留空表示自动选择

# 用 telnet 测一下从不同源地址出去时的路由，先看路由表
ip route get 8.8.8.8

六、反垃圾策略：收信端的过滤规则也要自己配

自建邮箱VPS 的送达率只管一半，另一半是别人发给你公司的邮件能不能进到员工信箱。这部分由收信端的反垃圾策略决定，而现在默认策略普遍偏激进，一套十年前的默认规则足以让正常的商务邮件消失。

延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。

收信端的过滤是分层的。第一层是连接层，看对方 IP 是否在黑名单、是否发信频率异常、是否命中灰名单，比如 Spamhaus 的 XBL 列表，命中就直接拒收。第二层是内容层，看主题和正文里的关键词密度、链接数量、图片比例、HTML 结构。第三层是行为层，看这个发信方过去发过来的邮件有多少被用户标记为垃圾，这个反馈量是权重最高的一项。

对自建场景来说，最值得调整的是第三层的阈值和第二层对 HTML 邮件的宽容度。默认的垃圾分界线通常定在 5 分，也就是五票里有一票被标记就拦截，这在个人邮箱里合理，但在企业场景里一封被误判的报价单可能比多收几封垃圾邮件的代价大得多。

# 用 spamassassin 给一封信打分，看看是哪些规则命中的
sudo apt install spamassassin spamc
spamassassin -t < 收到的邮件.eml

# 只看触发的规则名和加分明细，Score 超过 5 就进垃圾箱
spamassassin -t < 收到的邮件.eml | grep -E 'pts|score rule'

# 查看当前生效的垃圾分界线和白名单
grep -r "^required_score\|^rewrite_subject" /etc/spamassassin/

实操建议是先把 required_score 从默认的 5 调到 7，再把公司核心往来域名、主流邮件服务商域名加进白名单，同时对 HTML 邮件关掉一部分过于激进的内容规则。

# 收紧分界线，误判优先于漏判时可考虑 8 到 10
sudo sed -i 's/^required_score = 5/required_score = 7/' /etc/spamassassin/local.cf

# 在本地配置里加白名单域名，可信来源不再加分也不再触发
cat >> /etc/spamassassin/local.cf <<'EOF'
whitelist_from = *@example.com
whitelist_from = *@partner-domain.com
EOF

# 重启服务后用测试邮件验证打分是否符合预期
sudo systemctl restart spamassassin

注意白名单不要写得太宽，写成白名单域的通配符等于让该域的所有邮件免检，遇到伪造该域的钓鱼邮件就防不住了，更稳妥的是写具体发信人或具体主机名。

收信端还有一道常被忽略的关卡是灰名单机制，也叫 greylisting。对方服务器第一次收到你的邮件时，因为没见过你，会把这个 IP 放进临时灰名单，等一到四小时后再试一次。这不是故障，而是反垃圾的正常流程，你的服务器在这段时间内必须保持在线并且接受重投。如果你的服务器在这一小时内重启、换 IP 或者队列被清空，那封邮件就彻底丢了。这个机制也解释了为什么有些邮件要等几个小时才到。

自己配置邮件服务器时，往往要给主要合作方的服务器加上白名单，把它们从灰名单流程里排除，避免重要邮件延迟：

# 在 Postfix 里为可信对端配置灰名单例外
postconf -e 'postscreen_recipient_delimiter = +'
postconf -e 'postscreen_discard_ehlo_keywords = silent_quote, nowrap'

# 对已知合作方 IP 段设置 permit 规则，跳过灰名单检查
# 编辑 /etc/postfix/main.cf 加入下面这段
# permit_sender_networks = 203.0.113.0/24

# 确认 greylisting 是否启用
postconf | grep -i greylist

# 检查当前灰名单数据库里有多少 IP，以及最长被拦了多久
postsuper -d list:postgrey

另外，DKIM 验证能通过但 SPF 验证失败的邮件，有些收件方会直接拒收而不是放行，所以 SPF 记录里必须包含你实际发信的所有来源，漏掉一个就足以让整批邮件被拒。

七、送达率怎么量化：必须做一次真实的投递测试

自建邮箱VPS 好不好，看配置文件是看不出来的，必须做一次真实的投递测试，而且测试方法要接近真实使用场景。方法很简单：准备五到十个主流邮箱作为收件方，包括 Gmail、Outlook、QQ 邮箱、网易邮箱和公司自建的 Exchange，然后从你的服务器发一批内容各异的测试邮件，每封主题和正文都不一样，逐一记录进了收件箱还是垃圾箱。

延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

这里的关键是邮件内容要有区分度。十个测试信如果全是同一句 hello world，收件方的重复内容过滤器会在几封之后就触发，后面全被判为重复垃圾。正确做法是每封信正文里包含独一无二的句子，主题带上时间戳，内容长度和结构接近真实业务邮件。

# 生成带唯一标识的测试邮件内容，每封都不一样
for i in $(seq 1 10); do
  echo "这是一封投递测试邮件，唯一编号 TS-$(date +%s)-$i，内容随机串 $RANDOM$RANDOM。" | \
  mail -s "Delivery Test $(date +%s)-$i" -r no-reply@example.com \
  gmaltest+1@gmail.com gmaltest+2@outlook.com qqtest@qq.com
  sleep 20
done

# 抓取本地队列，确认邮件都成功交出去了
postqueue -p
mailq | tail -5

发送之后不要急着下结论，因为 Gmail 的垃圾判定有延迟，几分钟前的邮件可能还在学习阶段。标准做法是发完等六到二十四小时再统计，用百分之九十以上的送达率作为合格线。

除了收件箱位置，还要看延迟。正常商务邮件从发出到送达在几秒到几分钟内，超过三十分钟就要查队列。Postfix 的延迟日志可以这样看：

# 从日志里统计每封邮件的延迟分布
grep "status=sent" /var/log/mail.log | \
  sed -E 's/.*delay=([0-9.]+),.*/\1/' | sort -n | \
  awk '{a[NR]=$1} END {print "P50:", a[int(NR*0.5)], "P95:", a[int(NR*0.95)], "max:", a[NR]}'

如果 P95 延迟超过一分钟，通常是本机队列在排队，说明磁盘 IO 或者并发队列有问题，而不是收件方的问题。

投递测试最好做成常态化机制，而不是上线前做一次就完。建议每周固定一天发一批小规模测试信，把送达率记进一张表，这样一旦某周掉下来能立刻发现是哪个环节出的问题。测试用的收件地址要分散在不同的服务商和不同的地区节点上，只测一个 Gmail 邮箱得到的结论没有代表性。

评估送达率时还要看分位数而不是平均值。一批邮件里如果九十九封都秒到，只有一封被延后四小时，平均值看起来很好，但对那一个收件人来说就是故障。实际业务里更该盯的是 P95 和 P99。

# 统计最近 24 小时各收件域名的退回与延迟情况，按域名分组
grep "status=sent\|status=bounced" /var/log/mail.log | \
  grep -oP 'to=<[^>]+' | sed 's/to=<//' | sort | uniq -c | sort -rn | head -20

# 找出被拒收最频繁的域名，这是最需要修的地方
grep "status=bounced\|status=deferred" /var/log/mail.log | \
  grep -oP 'command=.*\((.*?)\)' | sort | uniq -c | sort -rn | head -10

把这些数据接到一个简单的定时任务里，每周生成一次送达率报告，就能把送达率从一个模糊的印象变成一个可跟踪的指标。

八、成本怎么算：机器费用只是其中一小块

自建邮箱VPS 的真实成本由四部分构成，只看第一部分会算错。机器月租是第一块，但一台两核两 G 的 VPS 通常已经够用，月租在各大商家的入门套餐区间内，具体以官网当日报价为准。真正容易被忽略的是第二块人工成本：一次完整的邮件服务器搭建包含系统加固、证书配置、反垃圾调优、DNS 记录维护和持续监控，投入的工时往往比服务器本身贵得多。

延伸对照：zenlayer 的公开机型与线路说明，可结合本节的判断标准自行核对。

第三块是 IP 相关的隐性成本。要用独立 IP 且支持自定义 PTR，通常需要额外付费或者至少要买更高一档的套餐；如果商家不提供 PTR 解析修改权限，你还得额外购买 rDNS 服务。第四块是失败成本，IP 被拉黑后的业务影响远比月租高，一个订单确认邮件没送达，可能就是几万块的交易损失。

下面这张表按规模列出了三档典型配置的需求侧参数，硬件配置是按估算给的，实际以所选商家官网当日报价为准：

场景	团队规模	内存估算	CPU 估算	日均邮件量	关键约束
小团队起步	5 到 15 人	2 GB 起	2 核	500 封以内	独立 IP 加 PTR，25 端口放行
中型公司	15 到 80 人	4 GB 起	2 到 4 核	500 到 3000 封	反垃圾策略需独立调优，队列要持久化
大批量事务邮件	80 人以上	8 GB 起	4 核以上	3000 封以上	建议外发走中继，本机只做收信

内存估算的依据是每个活跃连接大概占几 MB，加上反垃圾扫描的临时开销和页面缓存，二十个并发连接配两 GB 内存是合理起点。磁盘方面要留出邮件队列的空间，按每人每天 50 MB 留存三十天算，一百人的团队就要准备一百五十 GB 左右。

还有一个容易被忽略的成本项是备份。邮件服务器上的数据量不大，但配置和密钥丢了很致命，DKIM 私钥丢失意味着所有在途邮件的签名失效，PTR 和 DNS 配置丢失则要重新走一遍工单。配置文件的备份成本几乎为零，但不能省。

# 把 Postfix、DKIM、SpamAssassin 的配置打包备份，加密后放到对象存储
sudo tar czf /tmp/mailcfg.tgz /etc/postfix /etc/opendkim /etc/spamassassin

# 备份后校验文件完整性，确认归档里关键文件都在
tar tzf /tmp/mailcfg.tgz | grep -E 'main.cf|selector1|sasl_passwd'

配置备份必须连带 DNS 记录一起备份。DNS 记录才是真正难重建的部分，SPF 的 include 列表、DKIM 公钥、DMARC 报表地址、rDNS 的主机名，这些写在服务商控制台里，一旦账号密码丢失就得重新走一遍验证流程，有些流程还要等几天。建议把所有 DNS 记录整理成一份带说明的文档，跟着配置一起归档。

# 把本机所有相关的 DNS 记录导出成一份可归档的文本
for d in example.com _dmarc.example.com selector1._domainkey.example.com; do
  echo "=== $d ==="
  dig +short "$d" TXT
  dig +short "$d" A
done > /tmp/dns-records.txt

# 同时导出邮件订阅库和退信黑名单，这两份数据丢了要重新积累信誉
postmap -s /etc/postfix/virtual_bounce > /tmp/bounce-list.txt

另外，DKIM 私钥要做异地备份但不要放进代码仓库。放进版本库是安全事故的常见来源，因为仓库权限通常比生产服务器宽松得多，而且历史提交一旦被推到远端就很难彻底清除。私钥应当用强口令加密后放在密码管理器或者受限的对象存储里。

九、替代方案对比：什么时候不该自己搭

自建邮箱VPS 并非总是最优解。如果你的团队在十人以内、没有强制要求数据留在自己服务器上、也没有合规审计的硬性规定，那么用托管的企业邮箱服务在成本和送达率上通常更划算。托管服务用的是服务商的 IP 池，信誉积累了几十年，共享池里的优质 IP 会自动把你带进收件箱，而自建服务器的 IP 从零开始还要自己养。

延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。

反过来，有四类场景值得自建。第一是企业身份资产要求，发信域名必须由自己控制的服务器发出，因为一旦服务商调整策略或停服，客户通讯录的归属会变得模糊。第二是内部系统需要以自己的域名直接投递，比如自建工单、自建 CRM 的通知邮件，且不希望邮件正文带第三方发信标记。第三是合规要求，数据出境和留存需要完全自主。第四是有技术团队，自建邮箱的维护成本对他们来说近乎边际。

三条路的差异可以这样理解：

方案	月成本量级	送达率起点	25 端口依赖	维护工作量	适合谁
纯自建	低	从零开始，需要养	强依赖	高	有技术团队、要求数据自主
自建加中继	中	取决于中继池	不依赖	中	要发信域名自主，接受外发外包
托管企业邮箱	中到高	普遍较高	不依赖	低	十人以内、快速起步
第三方事务邮件服务	按量计费	通常最高	不依赖	低	只发通知类模板邮件

选型的判断标准可以写成一句话：如果你的核心诉求是省钱，自建不一定省；如果核心诉求是控制权，自建才有意义；如果核心诉求是省心，托管服务一定更划算。

还有一个折中方案是混合模式，这也是目前很多中小团队的实际做法：对外的品牌邮件，比如客户通知、订单确认、密码重置，全部走托管服务或专业事务邮件服务；内部系统产生的运维告警、监控通知这类无争议的机器邮件，走自建服务器。这类邮件数量不大但必须可靠，丢一封可能意味着一次事故被掩盖。

判断混合模式是否值得，标准是看你的邮件里有多少是必须由自有域名发出的。域名标记在邮件头部，From 字段显示的地址、SPF 记录指向的服务器，这些是客户能看见的部分。如果客户根本不看这些，托管服务完全没有问题；如果销售合同里写明了必须从自有域名发出，那就必须自建。

另一个常被问到的点是自建和虚拟主机的关系。很多人的第一台服务器就是虚拟主机，想在它上面加个邮件服务，但虚拟主机的共享 IP 没有 rDNS 修改权限，基本不可能通过收件方的验证。这也是为什么自建邮箱基本必须从 VPS 起步。

# 确认这台机器是不是虚拟主机环境：看是否有完整的 root 权限和独立 IP
whoami; curl -s https://api.ipify.org; echo
# 独立 VPS 上这两条会分别输出 root 和你的独占 IP
# 如果输出了共享 IP 或没有权限，邮件服务器就无从谈起

十、常见问题

自建邮箱VPS 需要什么样的服务器配置？ 两核两 G 内存跑基础收发完全够用，人数少于二十人的团队不需要更高规格。真正吃资源的是反垃圾扫描和并发投递，如果日均发信超过三千封或者有大量 HTML 营销邮件，内存建议加到四 G 以上。

25 端口被封了是不是就完全发不出邮件了？ 不是。可以改用 587 端口提交给 SMTP 中继服务商，本机只负责收信和写队列，只是要额外承担每封几分钱到一毛钱的中继费，具体以服务商官网当日报价为准。

买 VPS 时怎么确认商家支持自建邮件？ 下单前直接问客服三个问题：是否放行出站 25 端口、是否允许申请解封、是否提供可自定义的 PTR 反向解析。这三点都有明确答复的商家才适合邮箱用途。

PTR 反向解析必须和 A 记录完全一致吗？ 主机名要对得上，不要求和域名主标识一致。常见做法是主机名用 mail.你的域名，而 A 记录指向服务器 IP，正向解析 mail.你的域名 也指回同一个 IP 即可。

DKIM 签名做完了但邮件还是进垃圾箱，问题出在哪？ 先看认证是否真的通过。DKIM 通过但 SPF 失败、或者 SPF 通过但 DMARC 策略是 reject，都会导致拒收。把 DMARC 先设成 p=none 收集报告，确认两条都百分之百通过后再收紧策略。

发信量突然变大之后送达率暴跌，怎么排查？ 先暂停群发，检查是不是触发了收件方的速率限制或重复内容过滤。然后看本机队列是否堆积、同一 IP 是否短时间内有大量相似邮件发出，必要时降低并发投递速率并加上退避重试。

公司已经有域名了，还需要单独买 IP 吗？ 域名是域名，IP 是 IP，两回事。要让邮件从你自己的服务器发出，就必须有这台服务器对应的公网 IP，而且这个 IP 的信誉由你独自积累。服务器的 IP 通常随套餐附带，是否额外收费以商家说明为准。

自建邮箱和虚拟主机能共用一台机器吗？ 理论上能，但不建议。虚拟主机的共享 IP 几乎都在垃圾信誉库里，而且通常没有 PTR 修改权限。折中做法是先用便宜机器把域名和 DNS 配好，验证通过后再迁移到正式服务器。

多久能看到明显的送达率提升？ 一般在持续正常发信两到三周后能看到。信誉是双向反馈积累的，收件方的标记会逐渐形成正向记录，这个过程无法通过技术手段加速，只能靠保持低投诉率和稳定的发送节奏。

自建邮箱服务器需要开放哪些入站端口？ 至少要开 25 端口用于接收外部投递，开 587 端口用于本地用户提交邮件，开 993 端口用于 IMAP 加密收信，开 465 端口用于 SMTP 加密提交。这些端口是否需要放行到公网，取决于你是否允许网页端登录邮箱，如果只用 IMAP 客户端则 993 不能关。

邮件进入灰名单要等几个小时才收到，这是故障吗？ 不是，这是收件方的反垃圾机制。第一次收到你 IP 的邮件会被临时拦下一到四小时再重投，属于正常流程。服务器在这段时间保持在线并接受重投即可，如果期间重启或清空了队列，这封邮件才会真正丢失。

企业邮箱系统选 Dovecot 还是 Courier，性能差别大吗？ 对十人以内的小团队几乎没有可感差别，两者都能稳定跑。选择的主要依据是运维熟悉度和文档质量，Dovecot 的配置项更多但社区资料更全，Courier 安装更省事。建议直接用发行版的默认方案加上官方文档，不必在这一点上纠结。

用自建邮箱发信，收件人会不会看到类似代发邮件的提示？ 只要 DKIM 和 SPF 都配置正确并通过验证，收件人看到的就是你域名的正常邮件，没有代发标记。如果看到代发或可疑提示，通常说明 DKIM 签名没生效或者 DMARC 策略已经收紧到 reject 而你的某条发信路径没被 SPF 覆盖。

服务器换 IP 之后，之前积累的邮件信誉会保留吗？ 不会。信誉是绑定在具体 IP 上的，换 IP 等于从零开始。所以换机前要先把 DNS 的 TTL 调低，把旧 IP 的信誉价值榨干之后再切，切换完成后再慢慢把 TTL 调回正常值。