Stometa
返回文章

工程实践

Transactional Email 和 Email Campaign 为什么必须分开

从 Mandrill/Mailchimp 的产品边界出发，拆解 Campaign 被封、open tracking、sender reputation 与 Transactional/Marketing 发送隔离的工程方法。

2026年8月15日7 分钟阅读StometaStometa

零、为什么写这篇

2026-08-15，我重新梳理了一次企业邮件发送链路。Gmail 把接近 5,000 封/天的发件方划进 bulk sender；官方建议把 spam rate 保持在 0.1% 以下，同时避免碰到 0.3%。三个数字放在一起，已经足够杀掉一个常见误区：邮件发送的核心工作并非挑一个 SMTP API，然后把模板发出去。

真正的工作从分类开始。Password reset、收据、预约确认属于 Transactional Email；Newsletter、促销、召回、产品发布属于 Email Campaign。两类邮件共用 SMTP、DKIM、SPF 这些底层协议，但 recipient intent、发送节奏、合规义务、成功指标和故障预算全部不同。

Mailchimp 对这条边界写得很硬。Mandrill 现在的产品名是 Mailchimp Transactional Email，现行条款把它定义为 one-on-one informational email，并明确排除 bulk、promotional 和 marketing email。用 Transactional 产品跑 Campaign，风险先发生在平台条款层，之后才轮到 Gmail 的垃圾邮件过滤器。

Core Idea

Transactional Email 完成用户刚发起的事务，Campaign 发起下一次商业互动；两条流必须分开管理 consent、发送节奏、信誉边界和故障预算。

一、同样是 Email，生理结构完全不同

Transactional Email 是产品系统的一部分。用户点击「忘记密码」、完成付款、预约服务，系统发送一封与当前动作直接相关的邮件。收件人知道它为什么到来，往往还在等它。

Campaign 属于用户运营系统。企业选择一个 audience，按 segment、频率和商业目标主动触达。收件人过去可能同意过，但此刻没有等待这封邮件。这个差异决定了投诉、退订和 inactive recipient 必然更常见。

维度 Transactional Email Email Campaign
触发源 用户动作或系统事件 运营计划、segment 或 journey
关系 一对一、事件驱动 一对多、批量触达
用户预期 正在等待或可合理预期 需要持续证明 relevance
发送形态 分散、连续、低延迟 定时、突发、需要 throttling
核心指标 delivery、latency、bounce、failure complaint、unsubscribe、click、conversion
用户控制 notification preference consent、topic、frequency、one-click unsubscribe
典型故障 验证码或收据延迟 整批进 spam、provider rate limit、账户风控

这张表也解释了产品为什么分开。Transactional 系统优化单封邮件的低延迟和可靠性；Campaign 系统需要管理 audience lifecycle、segmentation、A/B test、发送窗口、退订和 suppression。把一个 Transactional API 循环调用 50,000 次，只完成了 SMTP send，剩下的风险一个都没处理。

二、「被封」至少有四层含义

团队说「邮件被封了」时，先把现象拆开。四层故障的 owner、证据和修法都不同。

现象 发生位置 要看的证据
Provider rejected ESP 在发送前拒绝 suppression、domain verification、content review、account policy
SMTP 4xx / 5xx 收件服务器延迟或拒绝 原始 SMTP response、enhanced status code、recipient ISP
delivered 但用户没看到 收件服务器接收后分流 Gmail Postmaster、seed mailbox、用户反馈
Account suspended / quota lowered ESP 自身风控 account reputation、complaint、bounce、compliance notice

250 OK 只证明对方邮件服务器接收了消息。Inbox placement 发生在这一步之后。反过来，ESP 标记 rejected 时，邮件可能从未离开发送平台。没有 raw SMTP response 和完整 headers，所有「被封原因」都只到猜测级别。

因此一次可复现的诊断至少要拿到五项数据：provider message state、SMTP response、完整 headers、发送 domain/IP/stream、收件 ISP。关键词扫描可以排在后面。

三、关键词有影响，但名单和反馈更重

Mandrill 会检查 denylisted URL、shortened URL 和常见 spam phrase。Gmail 也要求 subject、display name、headers 和链接准确，不得伪装 reply、forward 或 verified identity。这些规则都值得遵守。

但敏感词清单解决不了主要风险。现代过滤系统会持续观察：

  1. 收件人是否真正 opt-in，发送方能否证明 consent；
  2. complaint、hard bounce、unsubscribe 与 inactive recipient；
  3. 是否突然放量，或者停发几个月后一次性唤醒旧名单；
  4. From、DKIM、SPF/Return-Path、sending IP 和 tracking domain 的历史；
  5. 邮件内容是否符合用户当初授权的用途；
  6. shared IP pool 里其他发件人的行为。

Google 给出的 operational target 很具体：Postmaster Tools 中的 spam rate 保持在 0.1% 以下，避免达到 0.3%。Yahoo 对 bulk sender 同样要求 complaint rate 低于 0.3%。这类指标由真实用户反馈产生，改掉 subject 里的 FREE 无法抵消一批未经授权的旧名单。

内容卫生是门槛，permission 和 recipient feedback 才是长期信誉。

四、Open Rate 能看，但不能当裁判

Mandrill 的 open tracking 会在 HTML 邮件底部加入 1×1 pixel。客户端加载图片，系统记录一次 open。Click tracking 则改写链接，点击先经过 tracking endpoint，再跳到原始目标。

Resend 的机制相同，但它默认关闭 open/click tracking。官方建议主要对 Broadcasts 开启 open tracking，避免 inbox provider 把 Transactional Email 识别成 marketing；开启后可以使用自有 tracking subdomain，例如 links.updates.example.com。

Cloudflare Email Service 截至 2026-08-15 仍把 outbound sending 标为 Beta，产品定位集中在 transactional email。公开事件覆盖 delivered、deferred、bounced、rejected、failed 和 complained；当前官方 sending event 文档没有列出 opened/clicked。若自行实现 tracking，需要承担 pixel、redirect、隐私披露、bot filtering 和链接长期可用性。

我此前在《用 Cloudflare + Resend 打造无限邮箱》里写的是小规模身份与收发闭环。Campaign 再往前一步，问题已经从「能不能发」切换成「谁允许你发、收到后如何反馈、坏信号怎样停止扩散」。

Open Rate 本身还有三个系统误差：

  • image proxy 和预加载会制造假打开；
  • 用户关闭图片会制造漏报；
  • 安全扫描器会自动访问 tracking pixel 和链接。

Google 明确表示它不跟踪 open rate，也无法验证第三方 open 数据。指标优先级应该调整成：

complaint / bounce / deferral
    → click
    → product conversion
    → open

Open 适合看同一发送流中的趋势和实验方向，不适合证明 Inbox placement，更不适合成为唯一的 Campaign KPI。

五、Sender Reputation 没有固定权重公式

外部工具经常给域名一个分数，但 Gmail、Yahoo、Microsoft 没有公开「根域 60%、子域 40%」这种比例。真实模型至少包含这些身份：

From domain
DKIM d= domain
SPF / Return-Path domain
Organizational domain
Sending IP / IP pool
Tracking and landing-page domains
Message stream
Recipient complaints and engagement

子域可以建立可操作的隔离边界，但隔离并不绝对。Gmail 计算 5,000/day bulk-sender 门槛时，会把同一个 primary domain 下的子域流量合并；一旦进入 bulk sender 分类，状态不会自动过期。与此同时，Google Postmaster Tools 支持把子域单独加入 dashboard，Yahoo 也建议用不同 IP 或 DKIM domain 分隔 marketing 与 transactional 流量。

域名年龄也只是一条弱信号。老域名可能从未稳定发过邮件，新子域也可以继承一部分品牌识别与 organizational-domain 上下文。真正有用的检查来自四组数据：

  • Gmail Postmaster：spam rate、domain/IP reputation、authentication、delivery error；
  • Yahoo Complaint Feedback Loop：真实 spam complaint；
  • Microsoft SNDS/JMRP：主要面向拥有或控制 sending IP 的发件方；
  • DMARC aggregate report：谁在代表域名发送、SPF/DKIM alignment 是否通过。

公开 blocklist spot-check 只能证明「检查时没有出现在这几个公开名单里」。它无法证明 Gmail Inbox placement 良好。

六、推荐架构：两条发送身份，两套控制面

一套稳健的初始结构可以长这样：

Transactional stream
  From / DKIM: notifications.example.com
  Return-Path: bounce.notifications.example.com
  Tracking: open/click 默认关闭
  Workload: password reset、receipt、reservation、security alert

Marketing stream
  From / DKIM: updates.example.com
  Return-Path: bounce.updates.example.com
  Tracking: links.updates.example.com
  Workload: newsletter、promotion、win-back、product announcement

域名只是第一层。两条流还需要分开 provider account/subaccount 或 message stream、DKIM、Return-Path、tracking domain、rate limit、suppression reason 和 kill switch。

Suppression 也要保留语义。用户退出某个 newsletter topic，Campaign 系统必须停止该 topic；这条记录不应阻止 password reset。Spam complaint 和 hard bounce 的处理更严，它们通常需要在更大范围内阻止继续发送。一个只有 email + suppressed=true 的表，迟早会把业务规则压扁。

可以把发送事件收进统一 control plane：

ESP webhook
  → signature verification + idempotency
  → append-only email_event
  → suppression service
  → ISP × stream × campaign dashboard
  → threshold alert / automatic pause

每条事件至少保留 provider message ID、stream、campaign、template、cohort、From/DKIM/Return-Path domain、recipient provider、SMTP code、classification 和 downstream conversion。Recipient 明文只保留业务真正需要的部分。

七、第一周应该做什么

Day 1：把事实拿全

  1. 导出一封正常邮件和一封失败邮件的完整 headers；
  2. 保存 raw SMTP response，不要只抄 UI 上的 failed；
  3. 按 Gmail、Yahoo、Outlook 等 ISP 拆分 bounce 和 deferral；
  4. 核对 Campaign 有没有误走 Transactional 产品；
  5. 记录当前发送量、complaint、hard bounce 和 unsubscribe baseline。

Day 2–3：建立身份边界

  1. 为 Transactional 和 Marketing 建立不同 sending subdomain；
  2. 配置各自 DKIM 与 custom Return-Path；
  3. 验证 From、DKIM、SPF domain 的 DMARC alignment；
  4. DMARC 从 p=none + rua= 开始观察合法发送源，再决定 enforcement；
  5. 给 Marketing 配置 RFC 8058 one-click unsubscribe 与正文可见退订入口。

Day 4–7：控制放量

  1. 第一批只发最近有明确 engagement 的 cohort；
  2. 保持稳定发送速率，避免 burst；
  3. 设置 complaint、hard bounce 和 deferral pause threshold；
  4. 将 open tracking 限定在确有实验价值的 Campaign；
  5. 接入 Postmaster、FBL、DMARC report 与 provider webhook。

这里有一个必须接受的代价：拆分 sending identity 会增加 DNS、dashboard、suppression 和运营复杂度；新 domain/IP 还需要 warm-up。代价是真实的。继续共用一条管线的成本更隐蔽——一次低质量 Campaign 足以让验证码、收据和预约通知一起付账。

八、它不解决什么

架构隔离不会修复一份未经授权的名单，也不会把失去兴趣的用户重新变成 engaged recipient。SPF、DKIM、DMARC 全绿只能证明身份可信，无法证明内容受欢迎。Dedicated IP 也没有天然优势；发送量不足时，它缺少稳定历史，warm-up 和日常维护都由自己承担。

法律边界同样需要单独判断。CAN-SPAM、GDPR、CASL 以及不同地区的 privacy/marketing 规则并不完全一致。这里给出的是工程与 deliverability control，不构成法律意见。

九、三个反直觉的收获

  1. Provider 选型排在流量分类之后。 Mandrill、Resend、Cloudflare 都能发送邮件，但产品边界决定了哪类流量可以进入哪条管线。
  2. Open Rate 排在 complaint 和 conversion 之后。 Pixel 提供的是有噪声的 engagement proxy，收件方反馈和业务结果更接近真实目标。
  3. 子域隔离有用，但 primary domain 仍然存在。 Gmail 会合并计算 bulk-sender 门槛，品牌下的坏流量无法靠改一个 hostname 完全切断关系。

十、未关闭的循环

这套框架还缺三类现场数据：真实 ISP 分布、现有 DKIM/SPF alignment、各 cohort 的 complaint 与 conversion。没有这些数据，我不会给具体 warm-up 日程，也不会推荐 shared IP 或 dedicated IP。

重访触发条件很明确：任一 stream 的 Gmail spam rate 接近 0.1%、hard bounce 连续上升、4xx deferral 出现 ISP 集中，或者 Transactional 的 p95 delivery latency 被 Campaign 发送窗口拉高。触发后先收缩 cohort 和发送速度，再讨论模板与 provider 迁移。

References

评论

欢迎提出问题、纠正疏漏，或留下有思考的回应。请在下方发表评论；首次评论审核后显示。

不会公开显示。