发信子域名配置：隔离声誉，保护事务邮件

大多数团队把所有类型的邮件都从一个域名发出，直到某天出事。一次营销活动被过滤，紧接着密码重置邮件也开始收不到——因为两者都以 yourdomain.com 发出，共享同一份声誉。

发信子域名通过给每类邮件独立身份来解决这个问题：独立的 SPF 记录、独立的 DKIM 密钥，以及在每家邮箱服务商那里独立的声誉。本文讲清楚为什么这很重要、声誉到底挂在哪一个名字上、每个子域名需要哪些 DNS 记录，以及那些会悄悄破坏隔离效果的常见错误。

为什么所有邮件共用一个域名是风险

声誉是过往行为的记录。收件服务器按发信 IP、按域名、按子域名分别保存，并在决定接收、过滤还是拒收时加权。这个加权并不对称：坏历史扩散得比好历史快，最近产生过投诉的域名，下一封邮件会被更严格地审视，不管内容是什么。

当事务邮件和营销邮件共用一个域名，它们也共用这份审视。发给陈旧购买名单的一次活动产生投诉，下一封密码重置——收件人明确要求过的邮件——就继承了这份伤害。这是把单点故障放在了你控制力最弱的那部分流量下面。

拆开之后有三点好处：

• 影响范围可控。 营销活动的失误只影响营销子域名，账号安全邮件照常送达。
• 独立控制。 可以单独暂停、限流或重新预热其中一个子域名，不影响另一个。
• 诊断更清晰。 送达率下降时，你知道是哪个流造成的，因为两条流不共用一个名字。

还有第四个不那么直观的好处：收件方在执行 DMARC 和评估信任度时，越来越多地按子域名分别判断。一个有长期干净事务邮件历史的域名，不会自动为一个全新的营销子域名背书——而这正是你想要的隔离。

声誉挂在哪一个名字上

一封邮件里会出现三个名字，它们承载声誉的方式并不相同：

字段	内容	声誉作用
From: 头	收件人看到的地址	多数服务商的首要声誉信号
DKIM d= 标签	签名域名	声誉和 DMARC 对齐都依赖它
Return-Path / MAIL FROM	用于 SPF 和退信的信封发件人	退信声誉与 SPF 对齐

DMARC 判断对齐时看的是组织域（可注册域名），所以 mail.example.com 在宽松对齐下与 example.com 对齐。这意味着不需要为隔离单独注册一个域名；一个子域名就够，而且整个组织只需一条 DMARC 记录和一套策略。

实用规则：每类邮件在 From: 头里用自己的子域名，用绑定该子域名的 DKIM 密钥签名，由组织域上的 DMARC 统一覆盖。

选择命名方案

名字要描述用途，并且一次定好。以后再改名意味着从零重新预热。

子域名	用途
mail.example.com	事务邮件：密码重置、收据、安全提醒
news.example.com	营销和电子报
bounce.example.com	退信用的 Return-Path（常由服务商配置）
t.example.com	短事务别名，服务商要求时使用
em.example.com	要求独立发信域的第三方 ESP

不要用绑定某个厂商或某次活动的名字，也不要用 mkt1、mkt2 这类编号。如果以后某个子域名不够用，你要的是扩容，而不是换一个新身份、从头攒声誉。

每个子域名需要哪些 DNS 记录

子域名不会自动继承父域的记录。SPF 不向下继承，DKIM 密钥按选择器和域名分开，DMARC 只在组织域发布一次。mail.example.com 的完整记录如下：

; 子域名的 SPF —— 授权发信基础设施
mail.example.com.            IN TXT  "v=spf1 include:mail.rovela.dev -all"

; DKIM —— 选择器发布在 <selector>._domainkey.<subdomain>
rovela._domainkey.mail.example.com.  IN TXT  "v=DKIM1; k=rsa; p=<公钥>"

; Return-Path / 退信域
bounce.mail.example.com.     IN MX   10 feedback-smtp.rovela.dev
bounce.mail.example.com.     IN TXT  "v=spf1 include:mail.rovela.dev -all"

; DMARC —— 组织域上的一条记录覆盖所有子域名
_dmarc.example.com.          IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

这段记录里有四处容易出错。

SPF 记录必须放在子域名本身。 example.com 上的 v=spf1 记录对 mail.example.com 没有任何约束，每个发信子域名都需要自己的记录。

DKIM 密钥必须发布在你签名所用的子域名下。 如果 d= 是 mail.example.com，密钥会去 rovela._domainkey.mail.example.com 查。只发布在根域名下的密钥验证不通过。

退信域需要 MX 记录，如果你要收退信而不只是依赖 Webhook 事件。有些服务商代管这部分；如果是，把 MX 指向他们的主机即可。

DMARC 留在根上。 只在 _dmarc.example.com 发布一条。如果之后又给某个子域名单独发布 _dmarc 记录，它会覆盖该子域名的组织级策略——偶尔有用，但也经常是「策略和你以为的不一样」的原因。

记录语法本身参见 SPF 记录配置 和 DMARC 配置指南。三种机制如何配合，从 邮件认证原理 开始读。

根区记录与子域委托

管理子域名 DNS 有两种方式：在父区里直接发布记录，或者用 NS 记录把子域名委托给另一组域名服务器。

在根区发布记录更简单，也是多数团队该选的。在 example.com 现有记录旁边，为 mail.example.com 添加 TXT 和 MX 记录，全部在一个地方管理：一个控制台，一条审计链。

委托适用于子域名由另一个团队或厂商管理，或者服务商要求你把 NS 指向他们的域名服务器。代价是：谁控制那组域名服务器，谁就能改这个子域名的 SPF 和 DKIM，而你的根区工具里看不到。委托也是把控制权交给厂商而不交出整个区的唯一办法。

不要委托组织域本身，也不要给一个已经在根区发布记录的子域名再做委托——委托会生效，根区那些记录则悄悄变成死配置。

不要这样做

不要把发信子域名 CNAME 到服务商的主机。 mail.example.com 上的 CNAME 会让它解析到服务商的服务器，但不会把你的 SPF 和 DKIM 记录带过去，还会让这个名字对其他查询行为变得不可预期。老老实实发布记录。

不要在每个子域名上 include 所有服务商。 每个子域名只应授权真正会用它发信的基础设施。一个营销子域名里列着事务邮件服务商，等于授权了一个永远不会用它的发信方。

不要用通配符 SPF。 * IN TXT "v=spf1 ..." 不是合法 SPF，也不会产生大家期待的效果；收件方查询的是精确名字。

不要忽略 DMARC 对齐模式。 宽松对齐（默认）下 mail.example.com 与 example.com 对齐，不需要单独策略。严格对齐（adkim=s、aspf=s）要求域名完全一致，每个子域名都得有自己的 DMARC 记录。多数团队选宽松对齐，正是为了让子域名共用一套策略。

不要忘了把子域名算进 SPF 查询预算。 每个子域名上的 include 计入它自己的十次上限，而不是全局的——但如果根域名那条记录已经接近上限，照抄过来同样会接近上限。

发信前先测

新子域名发出第一封真实邮件之前：

1. 查询记录：dig TXT mail.example.com +short、dig TXT rovela._domainkey.mail.example.com +short、dig TXT _dmarc.example.com +short。
2. 发一封测试邮件到 check-auth2@verifier.port25.com，确认 SPF、DKIM、DMARC 全部通过，并确认 DKIM 域名就是预期的子域名。
3. 检查收到的那封邮件的 From: 头，而不是只看发信代码。显示名可以掩盖真实地址。
4. 分别发到 Gmail 和 Outlook 地址，在邮件源码里查看认证结果。

如果 DMARC 报告显示子域名对齐失败而 SPF 与 DKIM 都通过，常见原因是 From: 域名和 DKIM d= 域名是两个不同的子域名。修正签名域名，而不是放宽策略。

子域名就是一个新发信方

隔离只有在把新子域名当成新发信方时才成立。它没有历史，需要和全新域名一样的照顾：从活跃收件人开始，逐步放量，盯住投诉和延迟。预热指南 里有完整节奏；一句话版本是：第一天就全量发的子域名，和被过滤的新域名没有任何区别。

这份配置的回报是值得的。当每条流都有自己的名字和历史，一次糟糕的活动损失的是营销名单，而不是登录邮件——这就是「麻烦」和「故障」的区别。