为什么你的 transactional email 可能在悄悄失败

你花了无数个小时优化 HubSpot 工作流。熬了几周设计的欢迎序列。购物车挽回邮件。真正会被人打开的密码重置邮件。

但有个让人不舒服的事实：当用户收到密码重置邮件时，他们的邮件客户端可能显示这样的警告——"Gmail 无法验证 yahoo.com 确实发送了此邮件。"

这对品牌形象可不是什么好事。

HubSpot 的 transactional email 系统本身没问题——问题在于 authentication headers。默认情况下，HubSpot 用他们自己的 DKIM 密钥签名，不是你的。于是 Google 的认证检查一出问题：From 地址写着 you@yourcompany.com，但 DKIM 签名显示 header.d=hubspot.com。

这就是 DMARC alignment 失败。对于 transactional email 来说，这很致命——因为这类邮件用户真的会去操作。

Marketing Email 和 Transactional Email 的区别

动手修复之前，先搞清楚这两者的不同。

HubSpot 的 marketing email 走的是他们专门的发送基础设施。有一整个 deliverability 团队在管 IP 信誉、预热、发件人评分。发批量活动邮件的话，这样没问题。

但 transactional email 不一样。这是一对一的通信，由用户行为触发：密码重置、订单确认、表单提交、发票收据。用户期望这些邮件直接来自你的公司。邮件客户端对待它们的方式也不同——认证更严格，因为 transactional email 是钓鱼攻击的高价值目标。

让 HubSpot 用他们的基础设施和签名来发送这些邮件，你是在借用他们的信誉，而不是建立自己的。

介绍 MailKite：属于你域名的邮件身份

MailKite 是一个 SMTP relay 服务，架在你的应用和收件人邮件服务器之间。核心功能：用你的 DKIM 密钥签名，不是他们的。

这样一来：

• DMARC alignment 通过。 你的 From 域名和 DKIM 签名对得上。
• 你的域名信誉慢慢积累。 每一封通过你域名发出的邮件都在为你的发送历史添砖加瓦。
• 完整的日志和数据分析。 清楚看到每封邮件去了哪里，状态如何。
• 重试和故障转移。 收件人服务器临时不可用？MailKite 自动处理重试逻辑。

配置过程也相当简单。

一步步来：让 HubSpot 通过你的域名发送

第一步：在 MailKite 注册你的域名

注册 MailKite，添加你的发件域名。你需要进入 DNS 设置（如果 DNS 在别处管着，5 分钟搞定；如果你用 NameOcean 的 DNS 管理，在仪表盘里操作更快）。

MailKite 会给你三条 DNS 记录需要发布：

• 一条 MX 记录用于接收邮件路由
• 一条 TXT 记录用于 SPF
• 一条 DKIM 记录用于邮件签名

这些记录生效后（通常 5-30 分钟），你的域名就验证通过了。

第二步：获取 SMTP 凭证

在 MailKite 仪表盘里创建一个 SMTP 用户。复制服务器地址、端口和 API key。这些要填到 HubSpot 里。

大概长这样：

服务器: smtp.mailkite.dev
端口: 587
用户名: 你的 MailKite 用户名
密码: 你的 API key（以 mk_live_ 开头）
安全: 需要 STARTTLS

第三步：在 HubSpot 配置 SMTP Relay

在 HubSpot 里进入 Settings → Transactional Email。在你的发件域名设置下找到 SMTP 配置。

把 MailKite 的凭证粘进去。HubSpot 会发一封测试邮件——确认你能收到。

第四步：测试你的 Authentication Headers

这步别跳。通过你的 HubSpot 工作流发一封测试 transactional email。然后在 Gmail 里打开，检查 headers。

找这个：

Authentication-Results: mx.google.com;
    dkim=pass header.d=yourcompany.com;
    spf=pass;
    dmarc=pass

三个都应该显示 pass。如果 dkim 显示 header.d=hubspot.com，说明配置有问题。检查一下 HubSpot 里的发件域名和 MailKite 验证的域名是否完全一致。

SMTP 还是 API：该用哪个？

HubSpot 提供了两种发送 transactional email 的方式。说白了：

用 SMTP 的情况：

• 想要简单配置，自动搞定所有 HubSpot 邮件
• 从外部系统发送（Laravel 应用、WordPress 插件、自定义 CRM）
• 想要 MailKite 的日志和重试逻辑覆盖每封邮件
• 不依赖 HubSpot 的 open/click 追踪来统计 transactional 邮件

用 API 的情况：

• 需要 HubSpot 原生的 open/click 数据分析
• 想要每封邮件自动出现在 HubSpot 时间线里
• 在构建自定义集成，邮件事件要触发其他工作流

说实话？SMTP 更容易维护。配好之后，HubSpot 的每封 transactional email 都自动走 MailKite，不需要改任何代码。API 的话，你得去改每个发送调用的地方。

彩蛋：把回复路由到 HubSpot

这个功能很强大。当客户回复你的 transactional email 时，这些回复需要有个去处。用 MailKite 的 inbound routing，你可以把收到的回复 POST 到一个 webhook。

想让这些回复自动关联到 HubSpot 里对应的联系人？下面是一个 Cloudflare Worker 来处理这件事：

export default {
  async fetch(request, env) {
    if (request.method !== "POST") return new Response("OK");
    
    const { from, subject, text } = await request.json();
    
    // 在 HubSpot 里找对应的联系人
    const searchRes = await fetch(
      "https://api.hubapi.com/crm/v3/objects/contacts/search",
      {
        method: "POST",
        headers: {
          Authorization: "Bearer " + env.HUBSPOT_API_KEY,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          filterGroups: [{
            filters: [{
              propertyName: "email",
              operator: "EQ",
              value: from,
            }]
          }],
          properties: ["email", "firstname", "lastname"],
        }),
      }
    );
    
    const { results } = await searchRes.json();
    if (!results.length) return new Response('{"ok":true}', { status: 200 });
    
    const contactId = results[0].id;
    
    // 把回复作为一条备注附加上去
    await fetch(
      "https://api.hubapi.com/crm/v3/objects/notes",
      {
        method: "POST",
        headers: {
          Authorization: "Bearer " + env.HUBSPOT_API_KEY,
          "Content-Type": "application/json",
        },
        body: JSON.stringify({
          properties: {
            hs_note_body: `回复: ${subject}\n\n${text}`,
            hs_timestamp: Date.now(),
          },
          associations: [{
            to: { id: contactId },
            types: [{
              associationCategory: "HUBSPOT_DEFINED",
              associationTypeId: 202,
            }],
          }],
        }),
      }
    );
    
    return new Response('{"ok":true}', { status: 200 });
  },
};

现在每个客户回复都会变成他们 HubSpot 联系人记录里的一条备注——还带着原始邮件标题。

更宏观的视角：Email 是你域名策略的一部分

这不仅仅是邮件送达率的问题。你的域名就是你的数字身份。每封邮件、每次 DNS 查询、每次认证检查，都在为这个身份建立或损害信任。

当你通过自己的 DKIM 签名域名发送 transactional email：

• Gmail 和 Outlook 更信任你的邮件
• 你的发件人信誉不受任何平台影响，独立增长
• 客户看到的是你的品牌，不是某个供应商
• 你的域名作为资产越来越值钱

在 NameOcean，我们见过两种客户：一种把域名当一次性消耗品，另一种把域名当作基础设施来经营。Email 认证——DMARC、DKIM、SPF——和你的网站正常运行一样基础。

你的 transactional email 通常是你发出的最重要的沟通。它们值得和你的 landing page、产品本身一样被认真对待。