deliverability-incident-response

投递能力事件响应

故障总会发生。发生时，你需要的是一套应对方案，而不是惊慌失措。这项技能就是分诊决策树。

五种事件类型

症状	最可能的原因	首要行动	修复时间
回复率骤降	投递能力问题——邮件进入了垃圾邮件文件夹	运行垃圾邮件放置测试	1-14 天
退信率飙升至 >3%	列表质量差，或域名声誉不佳	检查退信类型	1-3 天
域名被列入黑名单	共享 IP 上有不良行为者，或你的域名被标记	检查黑名单，必要时轮换	7-30 天
预热期间收件箱被封锁	预热网络标记了发送模式	暂停、调查，必要时更换	1-7 天
Gmail 将邮件标记为促销内容	内容触发了过滤规则（链接、图片、HTML）	简化内容	1-3 天

决策树：“我的回复率下降了”

第 1 步：量化降幅

Was this week's reply rate < 50% of last 4 weeks' average?
  Yes → real drop, continue triage
  No  → noise, wait another week

如果降幅属实：

第 2 步：这是特定营销活动的问题，还是整个邮件发送群组的问题？

Are ALL campaigns dropping, or just one?
  All → fleet-level issue (infrastructure or copy pattern)
  One → campaign-specific (targeting, copy, list)

第 3 步：如果整个邮件发送群组都出现降幅——按以下顺序检查

1. Smartlead Smart Delivery 垃圾邮件测试（/email-deliverability-audit → run-spam-test.ts）

   • 如果收件箱投递率 <70% → 确实存在投递能力问题，跳至第 4 步
   • 如果收件箱投递率 >85% → 投递能力正常，改为检查邮件文案/定向

2. 检查域名身份验证（/email-deliverability-audit → check-domain-auth.ts）

   • 任何域名缺少 DKIM → 立即修复（重新连接步骤见 /zapmail-domain-setup-public）
   • DMARC 策略为 reject 且存在对齐失败 → 暂时降低到 quarantine

3. 检查预热状态（/smartlead-inbox-manager → list-health.ts）

   • 如果多个收件箱在预热期间被封锁 → 预热网络已标记你
   • 如果许多收件箱的声誉从“良好”降为“一般” → 降低发送量

4. 检查退信率（/email-deliverability-audit → audit-performance.ts）

   • 如果退信率 >3% → 列表质量下降
   • 如果退信率 <1% 但回复率低 → 邮件进入了垃圾邮件文件夹（第 1 步结果）

第 4 步：你遇到了垃圾邮件放置问题——该怎么做

按时间顺序采取行动：

1. 立即（今天）： 暂停发送量最高的营销活动。停止造成损害。
2. 第 1 天： 对 2-3 个发件人子集运行垃圾邮件放置测试（tag=active 与 tag=new）。找出表现最差的群组。
3. 第 1 天： 检查 Smart Delivery 的 spam-filter-details 报告，具体查看触发了哪些过滤器。常见的有：DKIM_INVALID、HTML_MESSAGE、LINK_REDIRECT。每种都有对应的修复方法。
4. 第 2 天： 修复已发现的问题：
   • DKIM_INVALID → 验证所有域名的 DKIM 记录，必要时重新发布
   • HTML_MESSAGE → 简化邮件正文（减少字体，不使用内联 CSS，不使用跟踪像素）
   • LINK_REDIRECT → 移除或减少第 1 封邮件中的链接（理想情况下不含链接）
5. 第 3-14 天： 降低发送量。每个收件箱的每日发送量减少 50%，持续一周。声誉恢复需要时间。
6. 第 14 天： 重新测试垃圾邮件放置情况。如果恢复到 85% 以上 → 恢复正常发送量。

决策树：“退信率飙升了”

第 0 步：退信数量是否足以进行判断？

发送 50 封邮件 后，退信率才有参考意义。低于这个数量时，一个失效地址就会显示为 2%， 两个则会显示为 4%——直接越过 3% 的界线。需要有 30 条归因于该特定发送域名的已分类退信， 退信构成才有参考意义。没有采样到退信的域名，其发件人来源占比从构造上看就是 0%，这看起来 与列表质量糟糕完全一样——因此，一个未经测量的域名才会得到“去重新验证你的列表”这种信心十足的判定。

步骤 1：按 SMTP 代码分类退信，而不是按硬退信／软退信分类

硬退信和软退信的区分过于粗略，无法据此采取行动。退信 DSN 中的增强型 SMTP 状态代码会告诉你问题出在谁身上。从退信线索的消息历史中提取 DSN，并取正文中第一个[45].\d+.\d+ 代码——DSN 模板会重复该代码，而且常在后面“管理员更多信息”的样板内容中引用无关示例。

类别	代码	解读	操作
LIST	5.1.1、5.1.10、5.1.0、5.2.1、5.4.1、5.5.0	邮箱不存在。	重新验证列表。仅保留已验证为有效的地址；catch-all 结果表示未找到，不代表通过。
SENDER（身份验证）	5.7.1、5.7.0、5.7.23、5.7.26、5.7.509、5.7.520	我们因策略或身份验证问题遭到拒绝。	先修复 SPF/DKIM/DMARC，7 天后重新检查。可以修复——不要替换域名。
BURNED	5.7.606-5.7.614，或 DSN 文本提到 blocklist/Spamhaus	收件方明确封禁了此发件方。	将 /inbox-lifecycle-manager 列为取消候选项。修复 DNS 无济于事。
THROTTLE	任意 4.x.x — 4.7.x、4.4.2、4.4.7、4.2.2	暂时性问题。灰名单或速率限制。	将每个收件箱的每日发送量削减 50%，持续一周。绝不要因 4.x 代码取消域名。
NOISE	5.2.2（邮箱已满）、5.3.4（邮件过大）、5.7.133（受限通讯组）	收件方配置问题，不是信誉信号。	将其计入统计，确保分母准确，然后从所有占比计算中排除。

⛔ 5.7.133 纯属噪声。 这表示“此通讯组仅接受来自组织内部的邮件”——是其他人的通讯组设置问题。它往往是实际样本中最常见的代码，将其归为发件方问题会凭空制造出“域名已被封禁”的取消候选项。

然后按发送域名计算（而不是按客户端计算——按客户端拆分无法判断应对哪个域名采取行动）：

sender_share = SENDER / (SENDER + LIST + BURNED)      # noise and throttle excluded
burned_share = BURNED / (SENDER + LIST + BURNED)

burned_share > 20%  (≥30 classified bounces)
  → BURNED, at any bounce rate. Evaluate this FIRST, before the rate gate — a domain
    that is majority-blocklisted at a 2.5% bounce rate is still burned.

bounce_rate > 3% AND sender_share < 25%
  → list quality problem. Revalidate.

bounce_rate > 3% AND sender_share 25-50%
  → both diseases at once. Fix the auth gap FIRST, then revalidate. Do not go chase
    the list when 40% of the failures are yours.

bounce_rate > 3% AND sender_share > 50% AND auth incomplete
  → SENDER_AUTH. Fixable. Fix the record, re-check in 7 days.

bounce_rate > 3% AND sender_share > 50% AND auth clean
  → BURNED. Configuration is clean and we are still refused.

bounce_rate > 5% either way
  → stop the campaign immediately to prevent ISP suspension, then classify.

rising 4.x share, low permanent bounce
  → throttle. Cut volume. Do not cancel.

步骤 1b：抽样——不要枚举每一封退信

退信行不会告诉你由哪个域名发送；只有提取消息历史后才能进行归因。因此，你无法预先按域名分层。先设定全局预算，并在之后确保达到最低样本数：在时间窗口内的名单中均匀抽样（使用 roster[::step]，绝不要只用 offset=0，否则会产生时间偏差），预算大约为 30 × (需要判定的域名数) × 1.5，任何归因退信数不足 30 的域名都应标记为样本不足，而不是对其作出判断。

⚠️ 退信线索名单通常会返回某个 campaign 的全部历史记录，且没有日期参数。请在客户端按发送日期筛选，否则六个月前已结束的 campaign 产生的退信会左右本周的决策。

⚠️ 获取消息历史时可能会遇到暂时性失败。在记录“无可用 DSN”之前，请使用退避策略重试至少 3 次——在一次实际运行中，64 条看似没有正文的线索中有 61 条在重试后返回了正文。

步骤 2：如果是名单问题

1. 从 campaign 导出剩余线索
2. 使用 MillionVerifier 批量验证（每 1,000 条约 $2）
3. 仅重复使用状态为“ok”的邮箱
4. 丢弃其余邮箱

步骤 3：如果是信誉问题

大幅放慢速度。将每个收件箱的每日发送量削减 50%，持续 2 周。更积极地进行预热。

决策树：“域名被列入黑名单”

步骤 1：确认黑名单状态

检查：

• 通过 /email-deliverability-audit → 垃圾邮件测试报告 → 黑名单详情，查看 Spamhaus、Barracuda、SURBL
• 查看 MX Toolbox（https://mxtoolbox.com/blacklists.aspx）以获得第二意见

步骤 2：属于哪一级黑名单？

• 域名被列入 Spamhaus DBL 或 SURBL → 问题严重。你可能需要彻底更换域名。
• 发送 IP 被列入 DNSBL → 通常是 IP 池的问题（如果使用 Zapmail 共享 IP，则不是你的问题）。Zapmail 会轮换 IP；等待 1-2 周。
• 次要黑名单（例如 Barracuda） → 通过其门户提交移除申请。通常会在 3-7 天内解决。

步骤 3：替换还是修复

• 域名注册时间不到 30 天且被列入黑名单 → 替换。不值得花精力清理。（请注意，这是注册时间不到 30 天的域名唯一会被替换的情况：确认被列入黑名单，而非依据回复率作出的判断。绝不会因为效果不佳而取消新域名的使用——参见 /inbox-lifecycle-manager。）
• 域名注册时间超过 90 天且被列入黑名单 → 尝试修复。停止发送 7 天，提交移出黑名单的申请，然后逐步恢复发送。
• **如果要替换：**归档旧域名，通过 /zapmail-domain-setup-public 购买一个相似的新域名，预热 2 周后再使用。

决策树：“收件箱在预热期间被屏蔽”

步骤 1：为什么会被屏蔽？

Smartlead 的 is_warmup_blocked: true 标记通常表示：

• 你的预热邮件被预热网络判定为垃圾邮件
• 太多预热网络中的同伴将这些邮件标记为垃圾邮件
• 收件箱类型或服务提供商实施了速率限制

步骤 2：排查

1. 检查 blocked_reason 字段（如果有值）
2. 如果是预热网络问题 → 收件箱信誉可能已受损。权衡成本与收益：
   • 较新的收件箱（不到 30 天）→ 停用，配置新的收件箱
   • 已建立的收件箱（超过 90 天，且此前信誉良好）→ 尝试关闭并重新开启预热，同时降低 total_warmup_per_day（尝试设为 15，而不是 40）
3. 如果是 ISP 速率限制 → 等待 48 小时，然后重新开启预热

步骤 3：停用工作流（通过 /smartlead-inbox-manager）

# Tag as retired
npx tsx scripts/tag-inboxes.ts --ids=<id> --add-tag=retired --remove-tag=active

# Disable warmup
npx tsx scripts/set-warmup.ts --mode=disable --ids=<id>

# Replace — buy new domain, create new inbox
# See /zapmail-domain-setup-public

决策树：“Gmail 将邮件标记为促销邮件”

步骤 1：在全新的 Gmail 账号上测试

将营销活动中的第 1 封邮件发送到一个全新的 @gmail.com 账号（你自己的，不在营销活动中）。邮件进入了哪个收件箱？

• 主收件箱 → 没问题
• 促销邮件 → 问题就在这里
• 垃圾邮件 → 送达能力存在更严重的问题（见上文）

步骤 2：触发促销邮件分类的因素（及修复方法）

• 邮件中有多个链接 → 将第 1 封邮件中的链接减少到 0～1 个
• 图片／内嵌图片 → 删除
• HTML 样式过于复杂 → 简化，减少标签
• 营销风格的短语（“点击此处”“立即行动”“限时优惠”）→ 删除
• 标头中的退订信息（List-Unsubscribe）——实际上有助于提高送达能力，但格式必须正确
• 带徽标的大型签名块 → 简化为纯文本

步骤 3：A/B 测试

创建两个版本——当前版本和精简版。分别发送给 50 条潜在客户线索。7 天后检查哪个版本的回复率更高。

72 小时“彻底失败”检查清单

如果什么都不奏效，而且你不知道原因：

1. **暂停所有营销活动。**停止造成损害。
2. **审查：**运行 /email-deliverability-audit 完整套件
3. **垃圾邮件测试：**在 2 组发件人子集上运行 Smart Delivery
4. 检查每个域名的 SPF/DKIM/DMARC——如果缺少任何一项，修复后再恢复发送
5. 检查 Zapmail 健康状况仪表板——如果他们的 IP 遇到问题，使用同一 IP 池的所有人也会受到影响
6. 重启时将发送量减少 75%
7. 使用已验证有效的邮件文案——恢复期间不要发布新文案
8. 重启后连续 7 天每天监测回复率

何时联系专家

• 修复后仍有超过 2 周被归入垃圾邮件 → 基础设施层面的问题，可考虑迁移发送平台
• 多个域名被永久列入黑名单 → IP 池问题，更换服务提供商
• 域名信誉在 4 周后仍未恢复 → 停用并替换域名

接下来要做什么

7 天后重新运行 /email-deliverability-audit --days=7，确认是否已恢复。域名／收件箱信誉恢复得很慢——未满 7 天不要重新审计。

与此同时：通过 /cold-email-weekly-rhythm 继续每周例行检查，及时发现新出现的问题。

**或者等待：**如果此次事件需要替换域名／收件箱，等待替换项预热 2 周后，再期待全面恢复。

相关技能

• /email-deliverability-audit — 首先运行的诊断套件
• /inbox-lifecycle-manager — 当结论是“该域名已废弃”时，用于决定取消、替换还是购买
• /smartlead-inbox-manager — 为收件箱添加标签、轮换或停用
• /zapmail-domain-setup-public — 替换已废弃的域名
• /positive-reply-scoring — 确认已恢复（回复率回到基线水平）

1% 规则合理性检查

修复后，先按正常发送量至少发送 200 次，再判断修复是否有效。少于 200 次时，回复率无法区分域名已失效还是只是遇上了倒霉的一周。

• 回复率回升至 1% 以上——已恢复。恢复正常节奏。
• 发送 200 次以上后仍低于 1%——修复无效。要么重新从头执行操作手册，要么接受该域名已被弃用，并交由 /inbox-lifecycle-manager 更换。（它仍会拒绝取消使用时间不足 30 天的域名——时间短不等于已弃用。）

还要耐心等待：声誉恢复需要时间。2 天后重新审核毫无意义。