小村软件有限公司
日本語 English 한국어 繁體中文 简体中文 العربية
联系我们
菜单

不依赖特定服务的中小企业群发邮件设计方法

· · 邮件群发, 现有资产利用, 咨询转化路径优化, 网站建设与SEO, B2B

“不想再增加一个专用的邮件营销服务，想用现有的域名和网站发送数十到数百封通知邮件”。 对这个问题的现实答案，不是 Bcc一发了之，而是搭建一套具备按收件人逐一发送、订阅管理、退订、SPF / DKIM / DMARC 的小型发送体系。

这里所说的”不使用特定服务”，并不是”什么都不用”。 而是把SMTP这一标准、订阅者名单、模板、退订流程留在自己手中，只让发送手段本身可以随时更换。

另外，本文的前提是面向既有客户、会员、资料索取者、订阅了电子报的读者等已存在某种关系或已获得同意的对象发送邮件。 并不是讨论把公开地址收集起来无差别群发的做法。广告宣传邮件有其法律前提，从发送质量的角度看，这种做法也难以长久维持。12

以下内容基于截至2026年4月能够确认的日本《特定电子邮件法》相关公开信息，以及Google / Yahoo / Outlook的发信人准则整理而成。12345

1. 先说结论

中小企业面向外部群发邮件时，现实中应该采取的形态大致是以下4点。

  1. 按收件人逐一发送 不把地址一股脑塞进Bcc，而是按每封邮件单独发送的前提切分发送队列。
  2. 由自己掌握订阅状态 用自己的数据库或CSV，清晰管理active、unsubscribed、bounced这类状态。
  3. 自动接受退订 不要把”请不要再发了”这种要求交给人工处理。要在正文中放置可见的链接，条件允许时再加上List-Unsubscribe。345
  4. 对发信域名进行认证 配齐SPF / DKIM / DMARC、反向PTR、TLS。就算能发出去，缺了这些也很难送达。345

归根结底，这不是邮件软件怎么操作的问题，而是发送体系的问题。

如果把”想要群发”理解为”在收件人 / Cc / Bcc里塞一大堆地址”，这个思路本身就会崩溃。 实际需要的是这样一套机制：

  • 可以发给谁
  • 不能再发给谁
  • 出于什么目的获得了同意
  • 如何接受退订
  • 发信方是否处于可被信任的配置状态

2. 为什么Bcc一发了之不够用

对外群发时，Bcc看起来简单，但运营上该有的基础它一样都没有。

问题 会发生什么 之后会因此受困
追不到退订 “请别再发了”只能通过回信或电话传达 下次发送很容易误发
没有退信管理 继续向不存在的地址发送 信誉容易下滑
没有同意记录 说不清是何时、在哪里获得同意的 法务与投诉应对都很薄弱
发送类型混杂 营销邮件和通知邮件从同一个邮箱发出 容易连累日常的收发订单邮件
无法控制速度 容易一次性集中发送 容易触发限制或被判定为垃圾邮件
依赖特定人员 靠个人的邮件客户端和个人操作运转 难以交接

尤其危险的是，“能发出去”这一点会让人产生”机制已经成立”的错觉。 但实际上，由于没有退订、退信抑制、同意记录、发送日志，一旦人数稍有增加，人工运营就会崩溃。

Bcc并不是完全不能用。 内部联络、面向封闭会员的小规模通知、一次性的相关人员联络，有时也能成立。 只是，作为面向外部客户和潜在客户持续发送的基础，它确实太薄弱了。

3. “不使用特定服务”的现实含义

这里容易产生的误解是，”不使用特定服务” = “全部手工完成”，但事实并非如此。

在实务中，只要把以下这3件事掌握在自己手中，就能相当程度地避免被供应商锁定。

3.1 应由自己掌握的东西

  • 订阅者数据
    • 邮件地址
    • 同意时间
    • 同意获取渠道
    • 发送类别
    • 退订状态
  • 发送规则
    • 发送什么内容、给谁
    • 以什么速度发送
    • 如何反映退信和退订
  • 发信身份
    • 发信域名
    • SPF / DKIM / DMARC
    • 用于接收回复的邮箱地址
    • 退订URL

3.2 可以之后替换的东西

  • 实际投递用的SMTP中继
  • 管理后台的实现方式
  • 发送队列的实现位置
  • 日志的存储位置

也就是说，”不使用特定服务”的本质在于不把发送规则和状态完全交给对方保管。

  • 收件人名单存放在自己的数据库中
  • 退订URL位于自己的域名之下
  • 主题和正文模板由自己掌握
  • 只有SMTP出口之后可以替换

有了这样的结构，最初可以先使用现有的邮件基础设施，之后也能顺利转向其他发送手段。

4. 面向中小企业的现实构成

4.1 最低限度的组成部件

如果每次的规模是数十到数百封，从一开始就没必要搭建过于庞大的体系。 不过，最低限度也应该把以下内容分开管理，这样才更稳定。

  1. 订阅者表
  2. 抑制表
    • 退订
    • 硬退信（hard bounce）
    • 投诉
  3. 发送模板
    • 主题
    • 正文（HTML / 纯文本）
    • 发送类别
  4. 发送队列
    • 各收件人的状态
    • 发送结果
    • 重试次数
  5. SMTP中继
    • 使用现有邮件基础设施
    • 或自建服务器
  6. 日志
    • 何时发给了谁
    • 成功 / 失败
    • 退订 / 退信的反映情况

开信率、点击率这类高级指标的测量，一开始并非必需项。 首先需要的是能安全发送、能被随时停止、能说明清楚。

4.2 发送对象表应持有的字段

最低限度的字段大致如下。

字段 示例 原因
email user@example.com 收件地址本身
status active / unsubscribed / bounced 用于判断是否可以发送
consent_at 2026-03-20 12:34:56 用于留存获得同意的时间
consent_source 表单 / 展会 / 既有合同 / 手动录入 用于说明来源渠道
consent_purpose 电子报 / 研讨会通知 / 维护信息 用于留存同意的具体用途
unsubscribed_at 2026-03-29 09:10:11 退订的证据
last_bounce_at 2026-03-30 08:00:00 判断是否应停止再次发送
notes 经由业务人员 / 既有客户 补充信息

即便最初的主数据来源是Excel或既有客户台账，也应该拆分管理到这个粒度。 特别重要的是，要让抑制信息始终优先生效。

举例来说，即便销售台账上还留着某人的地址，只要抑制表中标记为unsubscribed，就不应发送。 如果没有这条规则，退订后仍可能从其他渠道重新混入名单，从而引发事故。

4.3 架构图

官网 / 订阅表单订阅者表既有客户台账 / 会员台账发送模板主题 / HTML / 纯文本发送队列抑制表退订 / 退信 / 投诉SMTP中继现有邮件基础设施 或 自建中继收件人退订URL回复退信 / 投诉运营窗口SPF / DKIM / DMARC / PTR / TLS

这张图的要点在于，发送手段并不是核心。 核心是订阅者表、抑制表和发送队列。

SMTP中继只是一个出口。 只要把这一层分离出来，将来即便更换发送手段，也不会丢失过去积累的退订记录和同意历史。

5. 按规模决定该做到什么程度

5.1 每月1次、数十封规模

在这个规模下，最小配置往往已经足够。

  • 专用于合并邮件的发送模板
  • 按收件人逐一发送
  • 退订URL
  • 发送日志的保存
  • SPF / DKIM / DMARC的配置

这里的关键是，即便人数少，也不要退回到Bcc。 即便是50封以下，只要是对外持续发送，早早采用”逐一发送 + 状态管理”的形式，之后会更省心。

5.2 每月多次、数百封规模

到了这个阶段，加入以下几项会更稳定。

  • 发送队列
  • 发送速度控制
  • 退信反映
  • 退订即时反映
  • 专用于发送的子域名
  • 审批流程
    • 测试发送
    • 正式发送
    • 结果确认

此外，把日常的人际邮件与营销、通知类邮件区分开也很重要。 Google给出了按消息类型区分From地址或IP的思路，Yahoo也建议不要把bulk / marketing与transactional / alerts混用同一个IP或DKIM域名。34

例如，仅仅按用途分开地址，运营就能整理得相当清晰。345

  • 订单确认、账单类：billing@example.com
  • 故障通知、维护信息：notice@example.com
  • 电子报、活动通知：news@example.com

5.3 接近每天数千封时

到了这个量级，”不使用特定服务”本身很容易变成目的。

Google已明确要求，对Gmail每天发送超过5000封邮件的发信人，要满足SPF / DKIM / DMARC、From域名的一致性、一键退订等要求。 Outlook同样对每天发送超过5000封邮件的域名要求配置SPF / DKIM / DMARC，不满足要求的邮件可能会被投入垃圾邮件文件夹或直接拒收。35

到了这个规模，运营的主要课题也会发生变化。

  • IP信誉
  • 投诉率
  • 退信率
  • 退订处理
  • 增量的节奏
  • 监控

到了这个阶段，改用专用服务反而更省成本的情况也不少见。

也就是说，本文的结论并不是”无论规模多大都应全部自建”， 而是在数十到数百封的规模下，由自己掌握状态和规则的小型发送体系恰到好处。

6. 法务与发送质量上最低限度不能省略的事

6.1 同意

广告宣传邮件原则上需要事先获得同意。 日本迷惑邮件咨询中心的整理也指出，未经事先同意发送广告宣传邮件原则上是不被允许的。2

另外，Google和Yahoo都要求只能发送给明确希望接收的人，不得使用购买来的名单，也应避免默认勾选的opt-in方式。34

实务中至少应保留以下信息：

  • 同意时间
  • 同意获取渠道
  • 发送内容说明
  • 说明文案
  • 获取同意时的页面或文案

需要说明的是，法律上对网站公开的企业业务邮箱存在例外规定。 但是，不建议把发送体系建立在这一例外之上。 无论从投诉、送达率、信誉，还是实际反应率来看，这种做法都难以长久维持。2

6.2 信息披露义务与退订

即便是发给已获得同意的对象，发信人依然负有信息披露义务。 根据迷惑邮件咨询中心的整理，至少需要包含以下信息。2

  • 发信人的姓名或名称
  • 用于接收拒收通知的邮箱地址或URL
  • 可以拒绝接收的说明
  • 发信人的地址
  • 投诉与咨询的联系方式

也就是说，邮件页脚至少应包含以下内容。

发信人: ○○有限公司
退订: https://example.com/unsubscribe/xxxxx
如需停止接收，请通过上方URL办理。
地址: 东京都...
咨询: support@example.com

此外，主要收件方对退订的便利性相当重视。

  • Google：对大量发信人要求一键退订3
  • Yahoo：要求或建议使用List-Unsubscribe及正文内链接，并在2天内生效4
  • Outlook：建议提供易于发现且能正常工作的退订机制5

因此，至少在正文中放置可见链接，并尽量加入以下请求头，是比较自然的做法。34

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/xxxxx>

6.3 认证与送达率

主要收件方已经不再只看”能不能发出去”，而是以”是否通过了认证”为前提。

Google的公开准则要求以下几点。3

  • 所有发信人：SPF或DKIM、PTR（正反解析一致）、TLS
  • 大量发信人：SPF + DKIM + DMARC、From域名的一致性
  • 较低的垃圾邮件率
  • 大量发信人需支持一键退订

Yahoo的要求如下。4

  • SPF / DKIM / DMARC
  • DMARC对齐
  • 有效的正反向DNS
  • 退订
  • 垃圾邮件率低于0.3%
  • opt-in
  • bulk与transactional分离

Outlook也针对大量发信人提出了要求。5

  • SPF通过
  • DKIM通过
  • DMARC（至少p=none，并与SPF或DKIM对齐）
  • 真实可用的From / Reply-To
  • 退订
  • 名单卫生（list hygiene）

将最低限度的运营检查项整理成表格如下。

项目 最低限度要做的事 目的
发信域名 设置SPF / DKIM / DMARC 防止伪造，提升送达率
发信服务器 使用可正常反向解析的固定环境，启用TLS 避免降低收件方的信任度
From / Reply-To 使用真实存在、能接收回复的地址 能接收投诉与退订请求
退订 正文链接 + List-Unsubscribe 降低投诉率
名单质量 仅保留opt-in用户，剔除无效地址 保护信誉
发送速度 不要一次性猛增，保持固定节奏 避免触发限制或被判定为垃圾邮件
监控 关注退信 / 垃圾邮件率 / 投诉 尽早止损

Google建议，增加发送量时应从较低的量开始，面向反应良好的对象，按固定节奏推进。 突然的峰值或一次性翻倍的发送方式，容易导致限制或信誉下降。3

7. 实施的推进方式

若从最小规模起步，比较现实的顺序大致如下。

  1. 区分要发送的邮件种类
    • 通知邮件
    • 电子报
    • 研讨会通知
    • 面向既有客户的通知
  2. 建立订阅表单或同意获取流程 在网站上，把说明文案和同意获取一起呈现。 写清楚”会收到什么内容、频率如何”非常重要。4
  3. 将订阅者表与抑制表分开管理 提前做好这一步划分，之后无论更换到哪个平台，运营都不会崩溃。
  4. 确定专用于发送的域名 / 子域名 例如news.example.com或mail.example.com。 至少不要与日常收发订单邮件或个人邮箱混用。34
  5. 配齐SPF / DKIM / DMARC / PTR / TLS 如果自行发送，这一步是最优先事项。 不要把无法反向解析的环境用作发送基础设施。34
  6. 管理后台不用做得华丽，但要具备基本功能 需要的不是华丽的界面，而是以下功能。
    • 编辑主题
    • 编辑正文
    • 测试发送
    • 正式发送
    • 发送对象预览
    • 设置批次大小
    • 结果确认
  7. 第一次只发送少量 面向既有客户或反应良好的订阅者，保持固定节奏发送。 没有问题后再扩大对象范围。3
  8. 把退订与退信的反映放在最优先级 在开信率之前，先确认这部分是否正常运转。

按这个顺序推进，就能从”总之能发出去”升级为“不出事故并能持续下去”的形态。

如果想连同订阅表单、同意文案、退订页面一起重新审视设计，可以结合网站建设一并整理。 而如果前提是要与既有客户台账、内部系统、Windows工具对接，从技术咨询与设计评审入手梳理职责划分会更安全。

8. 常见的失败模式

以下是比较常见的失败模式。

  • 让日常的人际邮件与营销、通知类邮件从同一个发信源发出
  • 只用自由文本的备注来管理同意信息
  • 把退订处理留给人工回信
  • 把旧的名片名单整批导入
  • 突然以历史最大发送量开始发送
  • 在通知邮件中混入营销文案
  • 发送结果的确认止步于”发送接口调用成功”
  • 既有客户台账的优先级高于抑制表

其中最后一项尤其容易出事。

销售人员的Excel里还留着某个人的地址。 但这个人已经退订了电子报。 如果没有确立”退订信息始终优先”的规则，这个人就会从其他渠道被反复重新发送邮件。

9. 总结

如果中小企业想在不依赖特定服务的前提下，向数量不算少的对象发送邮件，需要思考的并不是”该按哪个按钮”。

真正需要的是以下5点。

  • 不用Bcc一发了之，而是按收件人逐一发送
  • 订阅者表与抑制表
  • 自动接受退订的流程
  • SPF / DKIM / DMARC / PTR / TLS
  • 将通知类与营销类分开运营

归根结底，拥有发送规则，比拥有发送手段更重要。

如果每次规模是数十到数百封，即便不使用专用服务也完全能够运转。 但即便如此，也不应停留在”用邮件软件一次性群发”的思路上，而应当作一套小型发送体系来设计。

相关文章

参考资料

  1. 日本消费者厅, 关于特定电子邮件发送适当化等的法律（特定电子邮件法） ↩ ↩2

  2. 迷惑邮件咨询中心, 特定电子邮件法 ↩ ↩2 ↩3 ↩4 ↩5

  3. Google Workspace Admin Help, Email sender guidelines ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  4. Yahoo Sender Hub, Sender Best Practices ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  5. Microsoft Community Hub, Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

常见问题

汇总了咨询这一主题时常见的问题。

用Bcc一次性群发给所有人可以吗？
作为对外持续发送体系的基础太薄弱。Bcc本身可以发出去，但追不到退订、没有退信管理、没有同意记录、发送速度无法控制，而且很容易变成依赖某个人手工操作。营销邮件和日常收发邮件混在同一个邮箱里发送，也容易互相影响。小范围的内部联络或临时的一次性通知有时还能应付，但对外持续发送应改为按收件人逐一发送，并配合订阅者表与抑制表进行状态管理。人数稍微一增加，人工操作就会崩溃。
发送广告或通知类邮件需要事先获得同意吗？
广告宣传邮件原则上需要事先获得同意。日本迷惑邮件咨询中心的整理也指出，未经事先同意发送广告宣传邮件原则上是不允许的。Google和Yahoo都要求只能发送给明确表示希望接收的人，不得使用购买来的名单。实务中应至少保留同意时间、同意获取渠道、发送内容说明等记录。虽然法律上对网站公开的企业业务邮箱存在例外规定，但不建议把发送体系建立在这一例外之上。
要让邮件不被判定为垃圾邮件，最低限度需要做什么？
需要对发信域名进行认证。具体包括SPF/DKIM/DMARC设置、可反向解析的PTR、TLS、真实存在且能接收回复的From/Reply-To地址、正文中的退订链接与List-Unsubscribe请求头，以及只包含opt-in用户的名单质量。Google要求每天发送超过5000封邮件的发信人同时配置SPF、DKIM、DMARC并支持一键退订，Yahoo则要求垃圾邮件率低于0.3%等。另外，增加发送量时应从低量开始，按固定节奏逐步提升。
不使用邮件营销服务，能自己搭建发送体系吗？
如果规模是每次数十到数百封，完全可以做到。关键在于把订阅者数据、发送规则、发信身份（域名、认证、退订URL）留在自己手里，让SMTP中继这个出口可以随时更换。核心不是SMTP，而是订阅者表、抑制表和发送队列。不过一旦接近每天数千封的规模，IP信誉和投诉率的管理会成为主要课题，这时改用专用服务反而可能更省成本。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表