主域名和子域名发信，客户看到的地址不一样
客户看到的是 @ 后面那个域，不是后台的账号名。子域名在 DNS 上是独立对象，主域名的 MX、SPF、DKIM 一样都不继承：SPF 查不到就判 none，不是 pass。只有 DMARC 会往下传，靠组织域记录里的 sp 值定子域策略。拆不拆看群发占比和回复对象，一天发不到几百封的公司没必要拆。
「你们发的邮件，地址怎么是 marketing@edm.abc.com，不是 @abc.com？」客户这么问的时候，多数不是配置出错，是两个域都在发信。
这篇只处理一件事：什么时候该用主域名发，什么时候该把群发挪到子域名去。多个域名怎么在同一个后台管，看 企业邮箱多域名那篇；子域名的 MX 记录怎么填，看 MX 记录怎么设置。两篇讲过的这里不重复。
客户看到的地址，由发件域决定
邮件地址是「本地部分@域」两段。zhang@abc.com 里，zhang 是账号名，abc.com 是发件域。收件人在收件箱里只看得到这两段拼出来的字符串。
所以同一个后台绑了两个域，员工用哪个域登录，或者写信时从「发件人」下拉里选了哪个，客户就看到哪个。改显示名改不了这个——显示名写「张三」，地址照样是 zhang@edm.abc.com。想让地址变，只能换发件域。
还有一层客户看不见：信封域，也就是 Return-Path 里那个域。退信退到它，SPF 校验的也是它。企业邮箱默认拿发件域当信封域，但如果群发平台把 Return-Path 换成了自己的 bounce 域，SPF 校验的对象就变成了平台，你主域名 SPF 配得再全也帮不上忙。查退信原因先看这一行，方向才不会跑偏。
主域名和子域名，在 DNS 上是两个独立对象
这里最容易想错。edm.abc.com 看起来像是 abc.com 的一部分，但在 DNS 里它是一套独立的记录，主域名上配过的东西，它一样都不继承。
| 记录 | 主域名 | 子域名 | 子域漏配会怎样 |
|---|---|---|---|
| MX（收信） | 必配，通常一主一备 | 只在子域要收信时配 | 别人往子域发信，系统退回查 A 记录，多数情况投不出去 |
| SPF（TXT） | 列全部发信源 | 要单独写一条 | 查不到记录，结果判 none，不是 pass |
DKIM（selector._domainkey） | 按服务商给的值填 | 签名域换成子域时才要 | 签名域和 From 域对不上，DMARC 对齐过不去 |
DMARC（_dmarc） | 必配 | 可以不配，靠 sp 承接 | 不配也能继承，但策略跟着主域走，没法单独定级 |
| 验证类 TXT | 按平台要求 | 按平台要求 | 平台验证不过，功能开不了 |
表里只有 DMARC 那一行是例外。edm.abc.com 自己没有 _dmarc 记录时，收件方会往上找到组织域 abc.com 的那条记录，按里面的 sp 值处理子域。组织域怎么认，看公共后缀表——abc.com 的组织域是它自己，abc.com.cn 的组织域也是它自己，不会被切成 com.cn。所以「子域名一条 DMARC 都不用配」这句话在多数情况下成立，前提是主域名那条记录里写了 sp。
MX 这一行要特别注意。子域名没有 MX 记录时，投递方不会去找主域名的 MX，而是回头查这个子域名自己的 A 记录。如果 edm.abc.com 有一条指向网站服务器的 A 记录，那封邮件就会被投到一台不跑邮件服务的机器上，超时后退信。这就是「子域名发信看着正常，但客户回复过来全丢」的常见原因。
拆子域名，隔开的是信誉，不是服务器
把群发拆出去的理由只有一个：退信率、投诉率、被判垃圾的次数，都是记在域名上的账。发票通知、EDM、系统告警和一个销售的报价邮件共用一个域，等于共用一个账本。群发那边被投诉几次，主域名的一对一邮件也跟着变慢，而销售并不知道原因。
拆开之后账本分两本。子域记群发的账，主域留给报价、合同、对账这类要紧的信。
但得说清它不解决什么，否则容易高估效果：
- 不隔离 IP。同一个服务商、同一批出口 IP，严重的滥发仍然会连带。域名信誉只是其中一层，不是护城河。
- 不解决内容问题。标题夸张、整封都是图片、没有退订入口，拆到哪个域都进垃圾箱。
- 不送现成信誉。新子域从零起步，头两周投递偏慢是正常的，别指望第一天就和主域名一样快。
代价也要算进去：多一套记录要维护，多一处退信率要盯，还要跟老客户解释地址为什么变了。有些行业的客户对发件地址特别敏感，这一条解释成本往往比技术成本高。
子域名发信，要单独配三条记录
顺序是先配记录、再切发信。反过来做，第一批群发就是在没有身份的情况下发出去的，投递结果没有任何参考价值。
SPF。在 edm.abc.com 下加一条 TXT，写 v=spf1 include:发信平台域名 -all。子域名的 SPF 可以比主域名干净得多：只写群发平台那一个 include，不像主域名要兼顾 CRM、ERP、客服工单七八个来源。查表次数上限 10 次是条硬线，子域单独一条反而离上限更远。怎么数查表次数、超了怎么压，SPF 记录配置错误那篇有完整算法。
DKIM。签名域 d= 用哪个域，公钥就得放在哪个域的 selector._domainkey 下面。签子域、公钥留在主域，验签直接失败。反过来的情况更常见：服务商只允许主域名签名，子域发出去的信 d= 还是主域。这在宽松对齐（adkim=r，也是默认值）下照样算通过，改成严格对齐（adkim=s）就不算。对齐这条线怎么走，DKIM 验证失败那篇拆过，这里不展开。
DMARC。子域不建自己的 _dmarc，就按组织域记录里的 sp 执行；sp 没写，退回用 p 的值。想让子域先宽后紧，在主域那条记录里写 sp=none 或 sp=quarantine，比给子域单独建一条更好管——改一个地方，子域全跟着走。策略怎么分档、什么时候收紧，看 DMARC 策略怎么定。
这四种情况，别拆
- 一天发不到几百封。量小的时候拆出去没有收益，只多一套要维护的记录和一处要看的报表。风险还没大到需要隔开。
- 客户靠地址认你。B2B 询盘、投标、法务函件，对方看到
@edm.开头，第一反应是「这家是不是外包发的」。这类邮件就该走主域名。 - 子域发出去的信，客户要直接回复。设
Reply-To能把回复引回主域，但客户点「回复」时看到的地址和来信地址不一样，一部分人干脆就不回了。 - 公司里没人能改 DNS。记录漏一条就要排查半天，出事时找不到人动后台，比不拆更悬。
判断标准就三条：群发占总发信量的比例、近三个月的退信率、有没有因为群发被投诉过。三条都不突出，说明现在这套还能用，别为了「规范」去动它。
要拆的话，按这个顺序落地
- 定域。用带业务含义的名字，
edm.abc.com、notice.abc.com都比mail.abc.com好。mail.常被拿来当网页邮箱的主机名，很容易和 A 记录混在一起，排错时先乱。 - 先确认后台收不收这个子域。各家产品对子域名、别名域名的支持范围不一样，有的按「附加域名」收，有的只认完整的注册域名。开通前问清楚，别自己配完 DNS 才发现加不进去。
- 配记录。要收信就加 MX；SPF 和 DKIM 按上一节配；DMARC 在主域记录里补
sp。 - 先验证再发。每条记录用
dig查一遍，再往 Gmail、QQ、Outlook 各发一封测试信，打开邮件原文看Authentication-Results那几行是不是都pass。 - 小批量跑两周。先发内部通知和低价值群发，盯退信率，稳了再切营销邮件。
成本顺带说清：子域名不用另外注册，不产生域名年费——域名那笔 30—80 元一年是给主域名的。账号还是按人算，旗舰版 200 元/人/年起、尊享版 260 元/人/年起，5 个账号起购，多绑一个子域不改变账号数。后台对附加域名是否单独收费，各家政策不一样，以合同约定为准。
相关问题
子域名需要单独买吗？
不需要。子域名挂在已经注册的主域名下面，不产生额外的域名年费，也不用重新实名。账号仍然按使用人数计费，跟绑几个域没有直接关系。后台对附加域名是否单独收费，各家政策不同，签合同前问一句。
子域名能收信吗？
默认不能。子域名没有 MX 记录时，投递方会退回查这个子域名的 A 记录，多数情况投到不跑邮件的机器上，超时后退信。要让子域收信，必须给它单独加 MX，主域名的 MX 不会被它继承。
用子域名发出去的信，客户回复会到哪个邮箱？
到 From 里那个地址所在的域，回复走的是发件人地址，不是 Return-Path。想让回复进主域的个人邮箱，在发信时设 Reply-To 指向主域地址。不过客户看到的回信地址和来信地址不一致，一部分人会犹豫，重要邮件还是直接用主域发。
主域名的 SPF 加了 include，子域名是不是自动生效？
不是。SPF 按域逐条查，子域名自己那条 TXT 不存在，结果就是 none，不会去看主域名。所以子域名要发信，就得在它下面单独写一条 SPF，把实际发信平台 include 进去。
子域名发信被退得多，会不会影响主域名？
域名信誉是分开记的，主域名不会直接背上子域名的退信记录，这正是拆开的目的。但两者如果共用同一批出口 IP，严重的滥发仍可能连带，隔离只在域名这一层生效，不是全隔离。