邮箱域名预热：独立 vs 共享，以及为何冷域名不能群发

冷域名在第一天就群发收据、登录链接和「就这一次」促销，不是有野心——而是让事务邮件学会垃圾箱。预热是有节奏的信任曲线：接收方看量形、退信率、投诉与认证对齐，才会把你当已知发件人。独立与共享以不同方式失败，但都惩罚跳过曲线的团队。

IOSOR 将事务邮件视为 white-label 预付费与消息并列：每次发送是借记行，目录状态诚实为 live 或 in setup，认证未完成不是生产徽章。接近每月 USD 1,000+ 的发送量级时，退信/投诉率与预热斜率成为商务复盘的关键指标。先用数据说话，再考虑扩量。没有预先囤积的已预热域名可连夜替换——即时（JIT）诚实同样适用于邮件身份的构建。预热自动化若不能在投诉率达到阈值时立即停止，就只是定时群发。SPF、DKIM 与 DMARC 记录未正确配置和对齐时，预付费只是将借记打印到垃圾箱。事务身份与促销身份必须严格分开，否则登录信件的声誉会继承促销邮件的投诉记录。

独立与共享预热策略

独立域名并非意味着「DNS 配置完成后即可无限量群发」。它代表着一个有明确发送计划、指定负责人以及紧急停止机制的命名身份。共享池并非「别人的问题」，不良的邻居流量仍然会损害你的预付费额度和用户信任。在争论哪种路径更经济之前，务必先完成 上线前的邮件认证 的所有步骤。

不要从冷域名直接群发

预热的核心在于：从接收方已经期待的流量开始（例如，订单收据、已知用户的密码重置链接），按照预先设定的斜率逐步提高日发送量，一旦出现硬退信或投诉就立即停止发送，并且绝不将营销推广邮件隐藏在「事务邮件」身份之下。新创建的子域名同样被视为冷域名。目录状态为 in setup 并非预热的豁免条件。

退信与投诉作为预热的紧急刹车

在预热期间对硬退信进行重试，是导致干净身份被标记为垃圾邮件发送者的主要原因之一。投诉是用户的主观判断——一旦收到，必须立即抑制该发件人。延迟发送是控制节奏的手段，而非清理名单的信号。将退信、投诉和延迟数据集中展示，并指定专人负责处理；参考 退信、投诉与延迟处理 指南。如果预热自动化系统无法在投诉率达到预设阈值时自动停止，那么你所做的就不是预热，而只是定时的大规模群发。

预付费钱包与认证门禁

没有配置 SPF/DKIM/DMARC 的预付费邮件发送，本质上是将预付费额度打印成垃圾邮件。在邮件状态标记为 live 之前的必要门禁包括：已命名的发件人身份、已发布的 DNS 记录、已配置 DMARC 报告接收者、跨路径共享的抑制名单、以及将预付费钱包额度与实际发送事件进行绑定。与 同一预付费账本上的邮件 功能配合使用，可以让财务部门清晰地将预热阶段的发送量视为实际消耗而非不明的旁账。低余额自动停止机制同样适用：预热任务不得在运维人员试图「让它跑完」时，通过静默透支来继续执行。

关键危险信号

• 新域名在第一天即进行大规模群发。
• 促销邮件与密码重置邮件共用同一个发件人身份。
• SPF/DKIM/DMARC 配置未完成，却将发件人状态标记为 live。
• 对硬退信进行「再试一次」的操作。
• 预热期间，投诉率的上升没有指定负责人进行处理。
• 将目录状态为 in setup 的域名当作已生产环境的收件箱进行销售。
• 错误地将外来邮件品牌的信息倾倒到你的发送队列中。

开始使用 IOSOR 进行预热

在进行第一次发送之前，请先为你的事务邮件命名一个清晰的发件人身份（From 身份），并选择独立或共享的预热路径。在该路径上完成 SPF、DKIM 和 DMARC 报告的配置。为你所选择的路径制定一个为期七天的发送量增长计划，并包含退信和投诉的紧急停止机制，仅向已知用户发送预期的邮件。在提高发送量级之前，务必将预付费钱包的账单明细与已接受（accepted）和已退信（bounced）的邮件数量进行核对。

IOSOR 核心要点

冷域名绝不能直接进行大规模群发。独立预热旨在建立你自己的 IP 地址声誉；而共享池则会继承你邻居的声誉状况。

必须做：先完成所有必要的认证配置，然后沿着你选择的路径逐步增加发送量。切勿做：将独立路径的发送量增长计划直接复制到共享池，也不要在第一天就尝试达到第七天的发送量目标。