为什么您应该使用子域名发送电子邮件

June 1, 2026 by 邮件随行

担心发送子域意味着您的邮件看起来来自不同域名？其实不然——收件人仍然看到您的根域名，而且可交付性会改善。以下是原因以及如何设置 mtg.yourdomain.com 的方法。

从子域名（如 mtg.yourdomain.com）发送事务性电子邮件——而不是从根域名，也不是从已经是 CNAME 的任何主机名。这是一个很小的 DNS 更改，却能显著改善可递送性。

在 MailerToGo 上？ 你不必手动发布这些记录。我们预先添加 mtg.yourdomain.com，并可以通过单个委派 NS 记录为你管理其 SPF、DKIM 和 DMARC——见为什么 MailerToGo 从 mtg 子域名发送。如果你想自己管理这些记录，以下是高级路径的手动设置。

“但这样我的电子邮件看起来不是来自不同的域名吗？”

这是首先让人担心的事，所以我们先解决它：不会。 使用子域名来发送不会改变收件人看到的任何内容。他们收件箱中的发件人:地址仍然是 you@yourdomain.com——你的根域名、你的品牌，完全和今天一样。

子域名在后台工作，在收件箱提供商（而不是人类）检查的身份验证层。实际改变的是你的邮件开始干净地通过 SPF、DKIM 和 DMARC，所以更多邮件到达收件箱而不是垃圾文件夹。所以交易很简单：对你的客户没有任何可见的变化，你的更多邮件实际上会到达他们。

简言之——你的收件人仍然看到你的根域名，你的递送效果变好。这就是全部；本文的其余部分只是解释原因和方法。

（技术版本：子域名是你的信封发件人 / Return-Path，即 SPF 检查的域。发件人:标题是你的收件人看到的，由你的应用程序设置并保持为根域名。下面有更多内容。）

理解问题

如果我的根域名是 CNAME，为什么我不能用它？

许多托管提供商（Heroku、Build.io、Cloudflare、Netlify 和其他）要求你用 CNAME 记录指向他们的域名，这样他们可以终止 SSL 并路由流量。这对你的网站很有效。但这为电子邮件造成了严重冲突。

DNS 有一条规则，定义在 RFC 1034 §3.6.2：如果一个名称有 CNAME 记录，它就不能有其他任何类型的其他记录。CNAME 意味着”这个名称只是那个名称的别名——去那里查找所有内容。” 没有空间留给保存你的 SPF 策略的 TXT 记录，或该同一名称下的 MX 记录。

所以如果 yourdomain.com 是指向你的主机的 CNAME，你从字面上无法向它添加 SPF。DNS 不会允许。

什么是 CNAME 冲突，为什么 DNS 这样工作？

CNAME 是 DNS 层的重定向。当解析程序查找 yourdomain.com 并找到 CNAME 时，它放弃原始名称并追踪目标。允许 CNAME 旁边有其他记录会造成歧义——哪个答案胜出？规范通过完全禁止这个组合来解决歧义。这不是提供商限制；这是 DNS 的定义方式。

我的网站在我的域名上工作得很好——为什么电子邮件会不同？

网络流量只需要 CNAME：浏览器问”yourdomain.com 在哪里？”，跟随别名，然后连接。电子邮件需要在域名上添加的记录——SPF（TXT 记录）和经常 DKIM 及 DMARC 策略——所以接收服务器可以验证邮件是否被授权。使你的网站工作的 CNAME 正好是阻止这些记录的。同一个名称，不同的需求。

如果我不使用 SPF 发送会真正破坏什么？

SPF 是收件箱提供商用来决定你就是你所说的人的主要信号之一。没有 SPF 记录：

邮箱提供商（Gmail、Outlook、Yahoo）更有可能将你的邮件发送到垃圾邮件——或拒绝它。
你不能通过 DMARC，这越来越多地限制收件箱。
你的邮件看起来像垃圾邮件发送者发送的未认证邮件。

邮件可能仍然发送，但有意义的部分不会到达。

子域名解决方案

我应该使用什么子域名？名称是否重要？

我们推荐 mtg.yourdomain.com。确切的标签不影响可递送性——email. 或 notifications. 也会工作——但 mtg.yourdomain.com 清晰、容易记住，并保持你的 MailerToGo 发送整洁有序。重要的是它是你直接控制的名称（不本身是指向第三方的 CNAME），所以你可以添加它需要的 SPF、DKIM 和发送记录。

如果我从 `mtg.example.com` 发送，收件人会看到那个而不是 `example.com` 吗？

不会——这是我们在顶部回答的担忧，现在有了机制。每封电子邮件上有两个不同的”发件人”地址：

信封发件人（也叫 MAIL FROM 或 Return-Path）：发送基础设施使用的地址。这是 SPF 检查的域，也是你的子域名所在的地方。
标题发件人:收件人实际在他们收件箱中看到的地址。这由你的应用程序独立设置，独立于发送域。

所以你通过 mtg.example.com（信封发件人）发送，同时你的收件人在发件人:行中看到 hello@example.com 或 Acme Support <support@example.com>。子域名进行身份验证；你的品牌地址保持显示。

回复会去子域名还是我的真实地址？

回复遵循发件人:标题（或你设置的显式 Reply-To:）——而不是信封发件人。将发件人或回复至设置为你真实的、受监控的邮箱（例如 support@example.com），回复如预期到达那里。子域名永远不需要接收邮件。

使用子域名会影响我的域名信誉吗？

会的——对你有利。从子域名发送隔离你的事务性/营销邮件的信誉与你的根域名。如果一个活动曾经有过困难时期，它被限制在 mtg.example.com 而不是拖累 example.com（以及你员工的日常电子邮件）。信誉隔离是一个功能，不是副作用。

我可以为事务性和营销电子邮件使用相同的子域名吗？

你可以，但通常最好分开它们——例如 mtg.example.com 用于事务性（收据、密码重置）和 news.example.com 用于营销。事务性邮件是高信任和低投诉；营销邮件自然会引起更多投诉和取消订阅。分开它们可以保持你的关键收据和重置与营销信誉波动绝缘。

设置

我如何配置 MailerToGo 使用子域名？

在 MailerToGo 仪表板中添加子域名（不是根域名）作为你的发送域，然后发布它给你的 DNS 记录。MailerToGo 将显示你子域名的确切记录。

我需要哪些 DNS 记录？

在子域名，你将添加 SPF 和 DKIM（我们推荐在根处的 DMARC 策略）。一个典型的集合看起来像：

; SPF — 授权 MailerToGo 为子域名发送
mtg.yourdomain.com.   TXT   "v=spf1 include:_spf.mailertogo.net ~all"

; MX — 将子域名的退信/返回路径路由到 MailerToGo
mtg.yourdomain.com.   MX    10 smtp.us-west-1.mailertogo.net.

; DKIM + DMARC — 发布你的 MailerToGo 仪表板中显示的确切记录
; (DKIM 是带有每个账户选择器的 CNAME；子域名 DMARC 策略是
;  为你配置的，例如 p=reject)

使用你仪表板中的精确值——DKIM 选择器和 SMTP 区域（smtp.<region>.mailertogo.net）对你的账户是特定的。

我需要更改我的应用程序代码中的任何内容吗？

两个小事情。首先，使用子域名的凭证指向 MailerToGo 的邮件程序。使用 Rails：

# config/environments/production.rb
config.action_mailer.delivery_method = :smtp
config.action_mailer.smtp_settings = {
  address:         ENV["MAILERTOGO_SMTP_HOST"],   # smtp.<region>.mailertogo.net
  port:            ENV.fetch("MAILERTOGO_SMTP_PORT", 587).to_i,
  user_name:       ENV["MAILERTOGO_SMTP_USER"],
  password:        ENV["MAILERTOGO_SMTP_PASSWORD"],
  authentication:  :plain,
  enable_starttls: true   # 在端口 587 上强制 TLS
}

第二——这是使子域名工作的部分——将信封发件人（return_path）设置为子域名，同时将收件人看到和回复的发件人:和回复至:保留在根域名：

class NotifierMailer < ApplicationMailer
  def welcome(user)
    mail(
      to:          user.email,
      from:        "Acme <hello@yourdomain.com>",   # 收件人看到的
      reply_to:    "support@yourdomain.com",        # 回复去哪里
      return_path: "bounces@mtg.yourdomain.com"     # 信封发件人：SPF 检查什么
    )
  end
end

Rails（通过 Mail gem）使用 return_path 作为信封发件人，所以 SPF 针对 mtg.yourdomain.com 进行验证——你的 SPF 记录所在的地方——同时发件人:/回复至:保留在 yourdomain.com。相同的品牌给你的收件人，对齐的 DMARC，更好的可递送性。

我如何验证子域名在工作？

确认记录解析：dig TXT mtg.yourdomain.com（SPF）、dig MX mtg.yourdomain.com 和来自你仪表板的 DKIM CNAME。
发送一个测试消息到 Gmail 账户，打开显示原始内容，并检查 SPF 和 DKIM 都显示通过，DMARC 显示对齐。
观察 MailerToGo 仪表板中的域名状态翻转为已验证。

高级和信任信号

DMARC 对齐在子域名中工作吗？

是的。DMARC 默认支持组织对齐：从 mtg.example.com 发送的邮件与发布在 example.com 的 DMARC 策略对齐，因为它们共享相同的组织域。你在根处发布一次 DMARC，你的子域名继承对齐——无需单独的策略。

DKIM 使用子域名还是根域名签名？

DKIM 使用你发布密钥的任何域名签名——这里是子域名（mtg.yourdomain.com）。这正是你想要的：DKIM 签名、信封发件人和子域名都排成一行，那个组合与你的根 DMARC 策略对齐。

我已经在根处有 SPF 用于 Google Workspace / Microsoft 365——我仍然需要子域名吗？

是的，子域名保持事物整洁。SPF 有一个硬限制10 个 DNS 查询；将每个发件人（Google、Microsoft、你的 ESP、MailerToGo）堆积到一个根 SPF 记录中存在超过它并破坏所有事物SPF 的风险。从具有自己 SPF 记录的子域名发送你的应用邮件绕过限制并保持你的企业邮件（Google/Microsoft）和你的应用邮件独立。

简短版本

使用 mtg.yourdomain.com 之类的子域名发送。你的收件人仍然看到你的根域名地址——对他们来说没有任何可见的变化——你的可递送性上升。这是大型发件人的做法（GitHub、Stripe 和 AWS 都从子域名发送事务性邮件）：它绕过 CNAME 冲突，保持 SPF/DKIM/DMARC 整洁，并保护你的根域名的信誉。