用途：为会发送事务性或生命周期消息（如预约提醒、CRM 通知）的中小企业产品，提供可送达、已获同意且合规的消息发送框架。
主要能力与要点： 一、事务性与营销分离。逐条消息判定归属：事务性（收据、预约确认/提醒、密码重置）由交易隐含同意，不强制退订但需处理 STOP；营销/生命周期（唤醒、促销、 newsletter、培育）需显式 opt-in、支持一键退订并快速执行。两者应使用不同发送身份（通常不同子域名／服务商），不要因“送达更好”而用事务性通道发营销内容。 二、服务商选择。邮件：Postmark（事务性送达最佳、对营销严格）、Resend（开发体验优先、良好默认）、SendGrid（规模）。默认事务性用 Resend，仅当生命周期量足够时再加营销级 ESP。短信：Twilio（Messaging Service + 发送方池）或 Telnyx；应使用 Messaging Service 而非单号码；美国 A2P 10DLC 需先注册品牌／活动。 三、域名认证（邮件必需）：SPF、DKIM、DMARC。DMARC 从 p=none 加 rua 报告起步，对齐后逐步到 p=quarantine、p=reject。新域名需逐步预热，不可冷域名群发。 四、同意与合规（以美国为主）：CAN-SPAM 需有效实体邮寄地址、准确的 From/Subject、可用的一键退订并在 10 天内执行；TCPA 营销短信需事先明示书面同意，自动处理 STOP/UNSTOP/HELP，尊重静默时段（收件人当地时间 21:00–08:00 不发营销），保留同意证据（时间戳、来源）；面向加拿大需 CASL。营销名单尽量双重确认。 五、抑制纪律：维护单一抑制名单，每次发送前检查；硬退信永久抑制、垃圾投诉抑制并调查、退订/STOP 立即按渠道抑制；迁移时不得未经重新同意导入被抑制地址。 六、可靠性：以领域事件为键做幂等发送（同一预约提醒重试也只发一次，与集成工程师协调键）；用状态回调/webhook 对账并暴露失败；对生命周期发送限流加队列，禁止循环发送；静默时段与时区按收件人 locale 计算。
使用方式：应用后向集成契约（docs/integrations/INTEGRATE-{slug}.md）贡献 Messaging 段落，记录渠道与服务商、事务性/营销身份、域名认证状态、各消息类型的同意方式、STOP/HELP 处理、静默时段、10DLC 注册情况、抑制存储与幂等键推导。
限制：资料未给出具体价格、平台覆盖细节或效果数据；上述为框架性规则，落地需结合产品实际与当地法规。