M3AAWG 发件人最佳通用实践 v3.0
概述
商业邮件发送者面临的核心挑战从来不是"把邮件发出去",而是"确保邮件被正确地送达收件箱,同时不被识别为滥用"。M3AAWG(反恶意软件消息传递及移动反滥用工作组)发布的《Sender Best Common Practices v3.0》正是应对这一挑战的行业共识性指南。与 2011 年的 v2.0 相比,v3.0 进行了全面重写,显著加强了对地址收集透明性和数据使用透明度的关注,并合并了之前的《发件人最佳通信实践》和《执行摘要》两个独立文档。
这份指南的核心原则可以概括为一句话:收件人的期望应当始终高于法律的最低要求。合法发送邮件只是底线,让收件人感到被尊重、拥有控制权、不会因为收到你的邮件而投诉——这才是优秀发件人的标志。
本文在完整译介原文全文(共四个章节及三个附录)的基础上,针对中国境内市场增加了补充说明。
TL;DR(太长不看版)
如果只有时间读一段话:在发送任何商业邮件之前,确保你已获得收件人的明确同意(最好用双重确认 opt-in),让退订像注册一样容易,部署 SPF/DKIM/DMARC 认证,监控你的投诉率(保持 < 0.1%)和退信率(硬退 < 2%),并在共享 IP 环境中对每个客户进行严格的发送前和发送后审核。收件人的期望,永远是最高优先级。
1. 引言(Introduction)
M3AAWG 发件人委员会编制本最佳通用实践(BCP)的目的是支持 M3AAWG 减少消息滥用的使命。具体目标是:提升正当发件人在消息传递中的透明度,使个人收件人和邮箱服务商都能更容易地将合法消息与滥用消息区分开来。清晰的透明度让邮箱服务商能够将其资源更有效地用于打击消息滥用、更好地保护终端用户。
M3AAWG 明确声明:可验证的、清晰的、显著的、知情的选择加入(opt-in)订阅者同意,是消息许可的最佳实践。至少,可接受的消息交换最佳实践必须符合消息和邮箱服务商的可接受使用政策(AUP)以及适用的国家/地区法律法规要求。发件人必须遵守这些要求,以避免行业及监管行动,避免催生新的监管需求。发件人也应考虑加入相关行业团体并遵守自律性倡议。
需要说明的是,本文件所描述的最佳实践是行业共识基线。一些接收网络或发件人可能因网络基础设施的复杂性、公共政策考虑或平台可扩展性而无法完全实施所有实践,但这些流程代表了行业的共识基线。
2. 地址收集的意图透明性(Transparency of Intent for Address Collection)
本章围绕如何收集和使用邮箱地址以进行批量/商业和事务性消息发送,提出了一套最佳实践。核心关注点在于:发件品牌和邮件服务商(ESP)都必须对消息的最终收件人保持透明。本章讨论收件人订阅(选择加入)、退订方法以及个人数据处理的相关实践。
2.1 选择加入(Opt-in)、订阅与邮箱地址收集
发送电子邮件或其他电子消息(尤其是批量消息和营销消息)的首要规则是:在向某邮箱地址发送消息之前,以及在将该收件人添加到持续、重复的通信列表之前,发件人必须获得该收件人的明确同意。主动注册的收件人将消息报告为滥用或垃圾邮件的可能性要低得多。
选择加入订阅分为三个层级,每个层级都建立在前一层级的基础上,对确保收件人明确同意的有效性逐层增强:
- 单一选择加入(Single Opt-in):
- 终端用户向发件人提供其邮箱地址
- 终端用户开始接收与该订阅相关的定时邮件
- 不发送订阅通知消息
- 不获取同意确认
- 带通知的单一选择加入(Single Opt-in with Notification)——更好:
- 终端用户向发件人提供其邮箱地址
- 向收件人发送通知/欢迎邮件,告知他们将会收到消息
- 不获取同意确认
- 确认式选择加入(Confirmed Opt-in)——最佳:
- 终端用户向发件人提供其邮箱地址
- 向收件人发送确认消息,要求其执行特定操作(如点击链接或回复邮件)以完成订阅
- 收件人必须执行规定的操作以确认同意接收未来消息;在确认完成之前,不发送任何订阅消息
单一选择加入应极其谨慎地使用——它允许将未经确认的地址添加到邮件列表中,这意味着拼写错误或直接伪造的地址都可以不加检查地进入列表,从而引发投诉、退信和发送信誉的最终恶化。
确认式选择加入(也称为"双重选择加入"double opt-in 或"闭环订阅"closed-loop subscription)是业界最高标准的订阅最佳实践。确认消息的收件人必须采取明确的操作才能被添加到列表中,从而防止拼写错误或被恶意提交的地址被加入持续邮件列表。
Level 1 细则——单一选择加入
- 收件人必须在地址被收集时明知地给予同意。
- 同意声明必须清晰明确。向收件人邮箱地址发送消息的意图声明不应隐藏在小型字体、法律术语或单独的页面中。
- 注册时应明确指出收件人加入的具体列表类型。在可能的情况下,发件人应允许收件人指定它们希望包含或排除的列表。(例如:用户可能愿意接收已购产品的更新通知,但不希望收到相关产品的推荐。)收件人对收到的消息控制越多,将消息报告为滥用的可能性就越小。
- 发件人应告知收件人可能的通信频率和类型,并在每个方面给予收件人选择权。消息频率的意外增加往往会导致滥用投诉增加。
- 邮箱地址只能用于注册时向收件人披露的目的。如果创建了新的二次用途(如不同内容的附加新闻通讯),应给予收件人选择加入该二次用途的选项。二次用途不得默认勾选。判断消息是否构成二次用途应从收件人角度出发。此外,某些司法管辖区要求在发送主要用途之外的附加通信之前必须收集此类许可。
- 发件人可以包含一个视觉示例,展示收件人将收到的邮件样式。这使得收件人在收到邮件时更可能识别出这是他们请求的通信,从而降低被标记为滥用的可能性。
- 在地址收集时,发件人应考虑保留何种额外数据(如 IP 地址、收集日期、收集发生的网站或活动)。大型企业还应跟踪哪个部门最初收集了地址及其方式。这些信息在需要向个人、ISP、RBL(实时黑洞列表)运营商或监管机构证明同意时应当易于获取。发件人还必须考虑关于 PII(个人身份信息)数据存储的法律要求。
Level 2 细则——带通知的单一选择加入
- 在终端用户提交地址后应立即发送确认消息。这些消息应遵循以下指南:
- 消息应包含提交至列表的地址及用户提供的任何其他信息
- 消息应包含邮件的频率和内容类型通知
- 消息应使用与未来邮件相同的"发件人"(From)地址
- 如可能,发送确认消息的服务器应与常规批量发送 IP 进行隔离
Level 3 细则——确认式选择加入(最佳)
- 确认消息的收件人必须采取明确操作才能被添加到列表中。应在地址提交时通知用户需要检查邮箱并对确认消息采取行动。确认邮件应简单且不含广告,以防止被自动过滤为滥用消息。
2.2 隐含(默认)同意(Implied/Implicit Consent)
隐含同意是指通过一个人与组织的互动来推断其许可。一个常见的例子是:顾客在购买时提供了邮箱地址,但没有被告知这样做会导致被加入持续邮件列表;商家随后推断该顾客希望加入其营销列表。虽然这种方式通常被接受为增长列表的手段,但它不被视为最佳实践——容易导致滥用投诉,且并非对所有发件人适用。如果发件人采用此方法,应密切监测该列表段的投诉率、打开率和点击率,以判断是否需要调整。
最佳做法是在地址收集点增加一个明确的勾选框以获取明确同意。如果确实通过隐含同意收集地址,建议通过"权限传递"(permission pass)或"确认"活动来争取获得收件人的明确同意。
无论采用哪种订阅方法(或组合),都必须记录每个地址的来源——包括注册 IP、时间戳、注册时的披露文本截图以及所有相关的隐私政策。这对将来列表问题的排查至关重要。
2.3 邮箱追加(Email Append)
邮箱追加(又称"epending")是指发件人尝试将有效的客户记录与邮箱地址进行匹配的数据操作。该邮箱地址的所有者既未明确提供该地址,也未同意从发件人处接收消息。
邮箱追加直接违反了 M3AAWG 的核心价值观。这种做法除了产生大量垃圾邮件投诉和消息拒绝外,还带来违反隐私和反垃圾邮件法律的重大风险。参见 M3AAWG 关于邮箱追加的完整立场文件:
http://www.maawg.org/sites/maawg/files/news/MAAWG_Epending_Position_2011-09.pdf
2.4 取消订阅(Unsubscribe)
- 取消订阅流程必须尽可能清晰且易于使用。
- 必须毫不延迟地处理所有退订请求——既是遵守法律的要求,也是尊重收件人的表现。
- 在退订过程中应设定预期的处理时间范围,并告知用户从哪个或哪些列表/通信类型中移除。收件人移除的时间越长,用户越可能将后续邮件视为滥用并提出投诉。
- 应具备通过出站邮件的 From 和 Reply-to 地址处理邮件退订请求的能力。
- 退订链接应包含成功退订所必需的全部信息:
- 订阅者 ID
- 多个列表时需要指明从哪个列表退订
- 用户身份验证令牌(防止第三方恶意退订他人)
- 应采用 List-Unsubscribe 头机制(RFC 2369):
- Mailto 退订:在出站消息中编码一个仅对应特定收件人的邮箱地址,任何发送至该地址的邮件均视为退订请求。
- URL 退订:提供指向发送平台退订功能的链接,建议将个人信息编码以防止恶意滥用。
- 应制定无法展示偏好中心时的退订策略。最佳做法是默认将收件人从所有邮件列表中移除。
- 退订超链接应使用易于阅读的文本说明(而非图片)并指向一键式在线退订网页。
- 应考虑提供离线退订方式:邮寄地址或免费电话号码(本地非国际地址/免费号码)。
- 当展示含多个订阅选项的偏好中心时,退订选项应默认预勾选。
- 当提供新的订阅选项时,返回的订阅者应默认处于未勾选状态。
- 订阅者不须登录偏好中心或经历任何安全验证即可取消订阅。发件人可提供登录表单管理其他偏好,但退订特定列表须在安全区域外完成。
- 强烈建议在邮件正文中包含收件人的邮箱地址,以提醒其订阅时所使用的邮箱。
2.5 数据安全(Data Security)
ESP 及其他涉及存储和管理订阅者邮箱地址或个人身份信息(PII)的发件人,强烈建议维护一套全面的安全计划,利用行业标准的最佳实践确保环境和应用程序的安全。详细建议超出本文件范围,以下是学习起点:
- OWASP(开放 Web 应用安全项目):https://www.owasp.org
- SANS 研究所:https://www.sans.org
- Online Trust Alliance(OTA):《数据保护和违规应急指南》:https://otalliance.org
- ISO/IEC 27002:2013:访问控制、通信与运营管理、信息安全事件管理
M3AAWG 极为强烈地建议将安全性作为数据处理流程设计的首要考虑因素。因为罪犯"那里有钱"而抢银行,天真地假定网络犯罪分子不会将邮件服务商和 PII 数据保管者作为获取邮箱地址数据的目标是不明智的。同样,不要假设"只存邮箱地址"就不会成为攻击目标。存储的数据既对所有者(订阅者)有价值,也对恶意行为者有价值。确保数据被妥善保管、远离犯罪分子之手,是消息生态系统中所有成员的职责。
3. 数据透明度(Transparency of Data)
本章概述了发件人应纳入运营的各种透明度实践。透明度是建立行业信任的基本原则,既适用于发送服务器的 IP 和域名,也适用于邮件正文中包含的任何链接。当所有信息都公开透明时,发件人就能为其客户的好行为和坏行为承担责任。当发件人通过以下机制使自身为人所知时,接收方就能更容易地识别出问题客户并进行沟通。
3.1 WHOIS 信息
WHOIS 协议是系统管理员获取 IP 地址分配或域名管理联系信息的方法。承担大量邮件发送责任的域名,其准确的 WHOIS 信息是透明度的关键组成部分。
- 发件人必须维护准确、最新的 WHOIS 记录,为收件人和其他方提供适当的联系点以帮助解决滥用相关问题。必须通过 WHOIS 或 rWHOIS 完成。
- 子分配的 IP 地址块(IPv4 /29 或更大、IPv6 /56 或更大)必须准确、完整地记录,符合 ARIN 等 RIR 政策。
- 匿名或代理域名注册的 WHOIS 数据违背了透明度原则。对于不打算滥用消息网络的实体,没有令人信服的业务理由使用故意模糊或不准确的 WHOIS 数据。
3.2 邮件认证(Email Authentication)
认证通过进一步识别消息的发件人来支持透明度,同时有助于减少或消除伪造地址。当发件人能够更轻松、更准确地被识别时,接收方可以基于认证域名的发信历史和信誉做出决策。认证还有助于检测伪造,从而提供更强的品牌保护。
四种主要认证形式:
- SPF(Sender Policy Framework):根据 return-path(机器名称)和 HELO 域验证发件 IP。
- Sender ID:根据"声称负责地址"(PRA)验证发件 IP(该技术已不再广泛使用)。
- DKIM(DomainKeys Identified Mail):使用数字加密签名,可针对头信息中的特定域名进行验证。
- DMARC(Domain-based Message Authentication, Reporting & Conformance):赋予发件人更多控制权,决定接收方如何处理未经认证的邮件,并提供认证通过和失败的可见性。
更多背景信息请参阅 M3AAWG 白皮书《Trust in Email Begins with Authentication》(2015 年 2 月更新):https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Email_Authentication_Update-2015.pdf
3.3 技术 IP 详情(Technical IP Details)
以下指南的目标是为声誉/过滤决策系统提供发件人所有权的透明度并明确发件服务器的责任。这些指南也为调查投诉问题的系统管理员提供有用的环境信息。
正向 DNS
- 必须选择明确标识责任方域名的名称。IP 共享时使用服务商/ESP 域名;专用 IP 情况下使用客户/广告主的域名。
- 名称必须明确表明该机器是服务器,而非通用池空间。(例如
server03.espname.com而非pool-dhcp-456.espname.com) - 共享 IP 情况下可能有多个名称指向同一 IP,但按 (1a) 选择的名称应视作主要名称。
- 所有向终端用户发送邮件的服务器必须使用相同或少量名称("域注册级别"统一),必要时使用子域名区分。
反向 DNS(PTR)
- 发件服务器的 IP 地址必须配置反向 DNS。
- 每个 IP 地址只能配置一个反向 DNS 名称。
- 该名称必须与正向 DNS 的主要名称完全匹配。
HELO 名称(RFC 5321)
- HELO 必须是可解析的主机名。中括号括起的 IP 地址字面量不可接受。
- 专用 IP 环境中,HELO 必须与主要正向 DNS 名称完全匹配。
- 共享 IP 环境中,HELO 名称必须至少与主要名称的"域注册级别"匹配。建议每个邮件系统或客户使用子域名作为 HELO 名称。
3.4 共享 IP 与专用 IP(Shared vs. Dedicated IPs)
使用 ESP 批量发送邮件的组织通常可以选择共享或专用 IP 环境。每种环境都有显著的优缺点。ESP 及其客户在确定最合适的环境时应评估多种因素。
定义
专用 IP 环境:一个独立实体独占使用并对该环境的出站邮件负责。可由一个或多个 IP 组成,但只能有一个实体对其使用负责。
共享 IP 环境:多个独立实体被分配到同一 IP 或 IP 池中共享使用。
选择专用环境的场景
- 实体邮件或列表质量不明或低于平均水平——隔离以保护其他实体
- 实体邮件或列表质量高于平均水平——隔离以保护其免受其他实体影响
- 希望对发件 IP 的出站邮件量实施更精确的控制
- 实体希望完全对自己的邮件负责,不希望因声誉和认证原因被等同于 ESP
- 需要第三方认证、白名单等增强投递服务,且要求专用环境为前提条件
选择共享环境的场景
- 多个实体的邮件量组合可维持总体发送量稳定,有助于建立 IP 信誉
- IP 信誉由多个实体共享,单个实体的错误影响会被稀释
- 共享环境对客户更具成本效益
共享环境配置最佳实践
- 共享环境中的实体应具有相似的内容和质量指标(投诉率、退信率)。建议对共享中的实体进行额外尽职审查。
- 共享环境中的每个实体的邮件应使用DKIM 进行认证,使用唯一的域名或子域名作为邮件负责实体标识。这使 ISP 有机会区分不同实体。
- 同时认证 ESP 域名和各个实体的域名。
- 提供两种环境的 ESP 应建立从共享迁移到专用环境的标准和监控条件。
专用环境配置最佳实践
- 每个专用 IP 的反向 DNS 应针对实体而非 ESP,例如
entity.cust.esp.com。 - ESP 应具备定义良好的 IP 预热流程并一致执行。
- ESP 应帮助专用环境的实体进行IP 白名单申请。
- ESP 应帮助实体维持一致的发送量以维护最佳信誉。
3.5 客户审核(Vetting)
代表客户发送大量邮件的 ESP,其命运受制于最差客户的最差实践。所有 ESP 都必须具备:
- 发送前审核流程:主动识别恶意发件人
- 发送后审核流程:监控客户发信后的行为
良好的审核流程有助于 ESP 区分真正的恶意垃圾邮件发送者和仅仅需要列表卫生指导的客户。客户审核是维护良好信誉和减少消息滥用的核心组成部分。
3.6 滥用投诉/反馈循环(FBL)处理
ESP 作为大量邮件的发送者,经常会收到关于这些邮件的投诉。投诉数据最大的来源通常是邮箱服务商设置的自动反馈循环(FBL),但 ESP 也会从收件人处直接收到发送到 abuse 邮箱的投诉。
ESP 必须有一个系统来处理 FBL 消息和直接投诉消息,以及一个确定如何处理这些投诉的流程。投诉是判断客户是否违反条款条件或行为不当的关键指标之一。
3.7 转发服务(Forwarding Services)
有时 ESP 可能选择为小型客户设置基于 ESP 发送域的地址用于消息头信息,并需要将回复和其他响应转发回客户。在这种情况下,ESP 应设置邮件转发服务。详细最佳实践请参见 M3AAWG《Email Forwarding Best Practices》。
3.8 连接/退信(NDR)处理
即使邮箱地址正确,也不能保证发送的邮件一定能被送达。退信的原因多种多样。接收系统可能在 SMTP 会话中同步拒绝(约占全部退回的 95%),也可能通过发送至 return-path 地址的消息异步退回(可能数小时甚至数天后)。发件人必须具备足够资源处理发送和接收两个方向的 SMTP 流量。
SMTP 状态码
- 2xx — 成功:消息被接受
- 4xx — 临时失败:消息未被接受——发件人应将消息重新排队并稍后重试
- 5xx — 永久失败:消息未被接受——发件人不应重试
临时失败的常见原因:接收服务器繁忙,或接收方检测到异常发件特征。发件人必须正确区分临时和永久失败——一些接收方会通过临时失败初始消息来检测发件人是否遵循 RFC。最常见的永久失败是"用户未知"(user unknown)。
退信处理策略
数值状态码 4xx 和 5xx 告诉发件服务器如何处理,但这些编码并非为营销人员设计的。发件人必须查看描述文本以确定如何处理列表中的特定地址。
- 接收方可能会惩罚出现大量永久失败退信的发件 IP。如果接收方告知地址不存在,不要重试并将该地址从未来的邮件中排除。
- 大量硬退信表明注册流程管理不善或列表不当,会扣减 IP 信誉分数。
- 推荐最佳实践:如果一个地址在连续多次活动中持续失败,应从列表中移除。通常的共识是:在两周或更长时间内连续退信至少两次的地址应被移除(以排除接收方偶发故障导致的误退信)。
4. 结论(Conclusion)
发件人从本文件中最应该带走的核心理念是:终端用户及其期望应始终是最高优先级。发件人法律上有权做什么或隐私政策下被授予了什么权利——并不重要;重要的是收件人的偏好和期望受到尊重。即使完全遵循本文所有建议,仍可能遇到投递问题或不愉快的收件人,但严格遵守这些最佳实践将解决最为严重和突出的问题。所有发件人还应咨询其法务部门,确保符合所有必要法律要求。
国内场景补充(CN-specific Context)
中国境内邮件群发合规要求
《通信短信息服务管理规定》(工信部令第 31 号)
虽然主要针对短信,但其精神对电子邮件同样适用:未经用户同意或请求,不得发送商业性消息;用户同意后明确表示拒绝的,应当停止发送。这与《网络安全法》第四十一条关于个人信息收集使用须经同意的要求一致。
《电子邮件信息服务管理规定》(工信部)
- 邮件服务提供者应建立垃圾邮件投诉举报机制
- 发送商业性邮件前须征得收件人同意或收件人未明确拒绝
- 邮件中应包含有效退订方法
- 严禁伪造邮件头信息、使用虚假路由
- 严禁自动收集、购买、交换获取邮箱地址
《个人信息保护法》(PIPL,2021 年起)
- 处理个人信息应遵循"告知-同意"原则
- 个人有权撤回同意
- 处理敏感个人信息需取得单独同意
- 数据跨境传输需进行安全评估
《网络数据安全管理条例》(2025 年起)
细化数据处理活动中的安全要求,商业邮件发送者应确保数据处理全过程合规。
国内外 ESP 发送策略对比
| 对比维度 | 国际典型做法 | 国内典型做法 | 国内合规建议 |
|---|---|---|---|
| Opt-in 标准 | Confirmed Opt-in(双重确认)为行业标准 | 多为 Single Opt-in,少数隐含同意 | 建议过渡到双重确认,至少确保明确单次确认 |
| 取消订阅 | List-Unsubscribe 头 + 一键退订,可离线退订 | 邮件内退订链接为主,List-Unsubscribe 头不普遍 | 强制部署 List-Unsubscribe 头(mailto + URL) |
| 投诉反馈(FBL) | 主流邮箱商广泛提供自动 FBL | 仅部分大型 ESP 提供,中小企业获取困难 | 主动向主流邮箱商申请 FBL,自建投诉监控 |
| 邮件认证部署 | SPF + DKIM + DMARC p=reject 普遍 | SPF 较普遍,DKIM 逐渐增多,DMARC 部署不足 | 三步走:SPF → DKIM 签名 → DMARC p=none/quarantine/reject |
| IP 信誉管理 | ReturnPath、250OK 等第三方信誉监控成熟 | 缺乏独立第三方信誉监控服务 | 利用 Google Postmaster、腾讯开放平台监测数据 |
| 发送速率控制 | 自适应节流(adaptive throttling)成熟 | 部分 ESP 提供,精细度不够 | 根据接收域逐域限流,关注灰名单延迟 |
| 数据合规要求 | GDPR/CAN-SPAM/CASL 法律体系清晰 | PIPL + 工信部规定,执法力度逐步加强 | 建立 PIA 流程,保留同意证据 |
注:国内现状基于 2025–2026 年行业观察,以各服务商最新政策为准。
国内 ESP 发送策略建议
- 地址收集:采用双重确认(Confirmed Opt-in),保存 IP、时间戳、披露文本截图。
- 列表清洗:每次批量发送前清洗 6 个月内无互动的地址。
- 投诉率监控:保持在 0.1% 以下,超过 0.5% 暂停发送并排查。
- 退信率控制:硬退信率 < 2%,软退信合理重试。
- 认证配置:SPF 覆盖所有发件 IP,DKIM 签名密钥 ≥ 1024 位,DMARC 逐步从 p=none 过渡到 p=reject。
- 发送节奏:新 IP 预热 4–8 周,从低量逐步增加。
- 法律合规:遵守 PIPL 告知-同意要求,邮件内含退订方式和发件人实体信息。
参考文献
- M3AAWG — Sender Best Common Practices Version 3.0, Updated February 2015(M3AAWG 官方网站:https://www.m3aawg.org)
- M3AAWG — Trust in Email Begins with Authentication, February 2015. https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Email_Authentication_Update-2015.pdf
- RFC 5321 — Simple Mail Transfer Protocol. https://tools.ietf.org/html/rfc5321
- RFC 3463 — Enhanced Mail System Status Codes. https://tools.ietf.org/html/rfc3463
- RFC 2369 — The Use of URLs as Meta-Syntax for Core Mail List Commands. https://tools.ietf.org/html/rfc2369
- RFC 5598 — Internet Mail Architecture. https://tools.ietf.org/html/rfc5598
- RFC 7208 — Sender Policy Framework (SPF). https://tools.ietf.org/html/rfc7208
- RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures. https://tools.ietf.org/html/rfc6376
- RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC). https://tools.ietf.org/html/rfc7489
- 中华人民共和国《个人信息保护法》(PIPL),2021 年 11 月 1 日起施行
- 工信部《通信短信息服务管理规定》(令第 31 号)
- 中华人民共和国《网络安全法》,2017 年 6 月 1 日起施行
- 《网络数据安全管理条例》,2025 年 1 月 1 日起施行
