DNS-Iemail 多供应商配置指南

最终推荐

本手册用于 TS 在客户沟通中快速判断方案、给出对应记录、确认话术边界，并识别哪些场景必须升级给技术同事。

TS 先问客户的 8 个问题

在给任何 DNS 记录前，先收集下面 8 个信息。缺少这些信息时，不要直接承诺“以后切换供应商不用改 DNS”。

• 谁负责客户域名 DNS 管理？客户 IT、安全团队、代理商，还是客户自己？
• 客户是否接受新增专用发送子域，例如 tx.example.com、mkt.example.com 或 news.example.com？
• 客户是否接受把专用子域做 NS 委托给我们维护？
• 如果不接受 NS 委托，客户是否允许配置 CNAME？
• 客户当前是否已有 SPF 记录？如果有，原始记录值是什么？
• 客户当前是否已有 DMARC？策略是 p=none、quarantine 还是 reject？
• 客户是否要求品牌化点击追踪、打开追踪、退信域名和回复域名？
• 后续是否预计同时使用多个通道或供应商，例如 iemail 事务邮件 + 营销邮件供应商并存？

一屏判断流程

flowchart TD
  Start[客户需要配置发信 DNS] --> Q1{是否接受专用子域 NS 委托?}
  Q1 -->|接受| A[方案 A：NS 子域委托]
  Q1 -->|不接受| Q2{是否允许配置 CNAME?}
  Q2 -->|允许| B[方案 B：CNAME 中间层]
  Q2 -->|不允许| Q3{是否接受后续切换仍可能改 DNS?}
  Q3 -->|接受| C[方案 C：TXT / MX / A 兜底]
  Q3 -->|不接受| Esc[升级技术评审]
  A --> PromiseA[客户改一次，后续切换通常由我们维护]
  B --> PromiseB[多数场景可减少客户后续改动]
  C --> PromiseC[只做基础兼容，不承诺免改]
        

三档客户接受度方案

方案 A：NS 子域委托

适合长期使用、多通道、多供应商切换、对交付率和维护成本要求高的客户。推荐按通道委托子域，而不是所有邮件都混在一个 em.example.com 下面。

方案 B：CNAME 中间层

适合大多数客户。客户把 Tracking、DKIM、部分 Bounce 域名 CNAME 到我们的中间域名；我们再把中间域名指向 SendGrid、Spotler 或其他供应商。

方案 C：TXT / MX / A 兜底

只在客户明确拒绝 NS 委托和 CNAME 时使用。它不是推荐方案，而是兼容兜底方案。TS 必须提前说明：后续新增或切换供应商时，很可能需要客户再次添加或修改 DNS。

多通道命名规则

为了后续多通道切换，不要所有邮件都使用同一组 click.example.com、bounce.example.com、s1._domainkey.example.com。建议按通道拆分命名。

flowchart LR
  Root[example.com] --> TX[tx.example.com
事务 / iemail]
  Root --> MKT[mkt.example.com
营销邮件]
  TX --> TXDNS[tx 中间 DNS]
  MKT --> MKTDNS[mkt 中间 DNS]
  TXDNS --> ProviderA[供应商 A]
  MKTDNS --> ProviderB[供应商 B]
  MKTDNS -.营销通道切换.-> ProviderC[供应商 C]
        

DNS 记录模板

下面记录是 TS 给客户沟通时的模板。正式生成时必须由技术或系统把 example.com、customer123、yourcompany.com、供应商目标值替换为真实值。

方案 A 记录模板：客户只做 NS 委托

_spf.tx.example.com TXT "v=spf1 include:_spf.yourcompany.com -all"
_dmarc.tx.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
tx-sg1._domainkey.tx.example.com CNAME tx-sg1.dkim.customer123.mta.yourcompany.com
tx-sg2._domainkey.tx.example.com CNAME tx-sg2.dkim.customer123.mta.yourcompany.com
click.tx.example.com CNAME click.tx.customer123.mta.yourcompany.com
open.tx.example.com CNAME open.tx.customer123.mta.yourcompany.com
b.tx.example.com CNAME b.tx.customer123.mta.yourcompany.com

方案 B 记录模板：客户配置 CNAME + 必要 TXT

方案 C 记录模板：无 CNAME，仅做兼容

后续切换供应商流程

必须升级处理的情况

客户沟通话术

推荐方案 A 时

为了保证邮件认证、点击追踪、退信处理以及后续多供应商切换能力，我们建议为邮件发送单独委托子域，例如 tx.example.com 和 mkt.example.com。客户侧只需完成一次 NS 委托，后续 DKIM、Tracking、Bounce 或底层供应商调整通常由我们维护，减少后续反复改 DNS 的成本。

推荐方案 B 时

如果贵司不方便做 NS 子域委托，可以配置我们提供的 CNAME 和必要 TXT 记录。这样大多数 Tracking、DKIM、Bounce 场景可以通过我们的中间域名维护，后续切换底层邮件服务商时通常不需要您重复修改同一批记录。但少数供应商可能要求精确校验值，如遇到这种情况我们会提前说明。

只能使用方案 C 时

如果贵司策略不允许 NS 委托和 CNAME，我们可以尽量通过 TXT、MX、A/AAAA 等记录完成基础发信配置。但这种模式下供应商抽象能力有限，未来新增或切换邮件服务商时，DKIM、Tracking、Bounce 或供应商验证记录很可能需要再次由贵司添加或修改。

技术原理速查

最终结论