TASK 22 · 客户获取与开发
发件域名与退信治理
配置发件域名认证、预热节奏、名单验证、退信与投诉监控，把送达率当作持续运维而不是一次性设置。
问题 · PROBLEM
新域名直接群发、SPF/DKIM/DMARC 配置不全、名单未验证，导致退信和投诉上升；团队只盯“发了多少”，没有监控送达与信誉。
目标 · GOAL
建立一套可持续的送达率运维：认证、独立发件域名、渐进预热、发送上限、名单验证、退信与投诉处理、暂停规则和负责人。
边界 · SCOPE
负责技术配置与发送纪律，不提供法律意见、不鼓励绕过平台规则；所有联系需有合法依据与退订路径。
常见输入
- 发件域名与 DNS 权限
- 邮箱服务商
- 名单来源与验证结果
- 历史退信与投诉
- 发送工具
预期输出
- 认证检查表
- 预热计划
- 发送上限
- 抑制名单
- 退信与投诉看板
- 异常暂停与恢复流程
风险边界 · RISK
高
本任务可能涉及个人信息、批量联系或对外发送。必须确认合法依据、平台规则、退订与投诉处理，并保留人工审核点；不要把自动化当作免责。
TASK BREAKDOWN
把任务拆成可执行的步骤。
步骤顺序不是唯一答案；它用于说明一项任务通常如何从证据走到输出，实际项目应按团队与市场调整。
- 01 配置 SPF、DKIM 与 DMARC
- 02 分离发件域名
- 03 验证名单
- 04 制定预热节奏
- 05 设置监控
- 06 异常暂停与修复
- 07 每月复盘
这个任务解决什么
送达率不是邮件工具的一个开关，而是域名信誉、认证配置、名单质量和发送行为的共同结果。新域名、未验证名单和突然放大的发送量，很容易让邮件进入垃圾箱；等到退信和投诉出现，域名信誉已经受损。
最佳实践
- 使用独立发件域名，不要用公司主域名做冷外联；主域名留给客户沟通和交易邮件。
- 完整配置 SPF、DKIM 和 DMARC，并在发送前验证通过。
- 新域名从小量开始，逐周增加，观察退信、投诉和回复，不要第一周就发满。
- 发送前做邮箱验证和抑制名单检查；硬退信、投诉和退订必须立即停止后续发送。
- 设置每日上限、异常告警和暂停规则；出现投诉率上升时先停，不要继续“跑完序列”。
- 每月复盘域名信誉、退信率、投诉率和有效回复，记录改动与结果。
常见失败
- 新域名直接群发，没有任何预热。
- 只配置 SPF，忽略 DKIM 和 DMARC。
- 使用来源不明的名单，退信和投诉一起上升。
- 没有暂停规则，问题发现时已经发出数千封。
衡量与边界
看送达率、硬退信率、投诉率、退订率和有效回复，而不是发送量。送达率运维不构成发送许可；联系人来源、合法依据、退订与数据保留仍需按适用规则确认。
SOLUTION COMPARISON
可选方案，按条件比较。
同一任务可能有现成 SaaS、自动化工作流或人机协作等不同路径。表格按技术门槛排序，不构成绝对排名；每个方案页都有更完整的限制、风险与核验说明。
| 方案 | 路径 | 技术门槛 | 部署 | 费用 | 核验 |
|---|---|---|---|---|---|
| 现成 SaaS | 无需编程 | 在线服务 | 免费 / 订阅 | L1 · 已核对官方资料 | |
| 现成 SaaS / 自动化工作流 | 无需编程 | 在线服务 | 订阅 | L1 · 已核对官方资料 |
WHERE TO START
根据你的能力选择入口。
入门建议不是能力评级，而是降低第一次尝试的成本。先用小样本验证流程，再决定是否扩大自动化范围。
低代码 / 需要配置
适合愿意维护表格、工作流或少量脚本的团队。
当前没有发布在这一门槛下的方案；可先查看其他路径或方案索引。
需要技术 / 开发
适合能维护 API、自托管服务和数据管道的技术团队。
当前没有发布在这一门槛下的方案；可先查看其他路径或方案索引。