同一预付钱包中的事务型邮件：一本账

财务团队往往能暂时容忍两套账单故事——直到无法再容忍。短信走预付费、邮件绑另一张卡、语音在第三个标签页——月末财务只能在电子表格里拼凑。正经 B2B 平台让事务型邮件与消息共用同一预付费钱包，并遵循同样的诚实规则。

IOSOR 在能力 live 时将邮件与 SMS、语音并列展示——白标界面，客户端不出现任何上游品牌名称。月平台用量接近 USD 1,000+ 时，通道证据、退信处理记录与预付费账本行会成为更紧密的商务复盘材料；先拿证据，再谈扩量。

共享钱包应包含什么

参见 同一钱包里的交易邮件。财务、运维与产品必须读取 SMS、语音与邮件的同一套借记行——不是月末再手工对齐的三张表。共享钱包让每类消息的真实成本在同一账户界面可见，低余额停止与充值告警也覆盖邮件走廊，而不是邮件静默超支后才发现。

试点团队常把「收据类邮件」与「OTP 邮件」混在同一模板策略里：前者容忍轻微延迟，后者要求秒级可达性与严格 TTL。营销必须走独立同意车道——用事务型标签群发促销，既伤可达性，也让财务无法辩护借记。目录标 live 时，对外承诺的发送能力必须与真实状态一致；in setup 不是 live。

生产前的认证门槛

SPF、DKIM、DMARC 对齐不是装饰——而是可达性基础设施。在放大 OTP 邮件之前完成 auth，否则试点阶段的半套配置会变成生产债。对照 上线前的邮件认证。在 OTP 放量前文档化域名、selector 与 DMARC 策略；staging 上的「能发出去」不等于收件箱可达。认证未完成时，不要在销售材料里承诺生产级 OTP 邮件。

作为财务事件的退信与投诉

退信是卫生信号；投诉是信任紧急事件。两者都应：

• 自动更新抑制名单
• 按已发布策略借记或贷记
• 绝不向终端用户倾倒原始诊断信息

复盘 退信、投诉与延迟处理。每次退信都应留下可辩护的账本痕迹——财务应能解释「为什么扣了 / 为什么没扣」。投诉应触发合规复核，而不只是清名单。Webhook 必须进入已认证、幂等的 consumer；退信只进日志、不进账本，是常见的月末对账雷区。

危险信号

• 邮件后付而 SMS 预付费
• 退信 webhook 未进入 consumer
• 营销群发贴事务型标签
• Auth「试点可选」
• 邮件运维需单独门户登录
• 客户端错误信息出现上游品牌名称
• 目录写 in setup 却对外承诺邮件已 live

一周计划

1. 在 staging 发送测试收据 + OTP 邮件并保留投递回执。
2. 在真实域名验证 SPF/DKIM/DMARC 对齐。
3. 强制一次退信；确认抑制名单更新 + 账本行。
4. 与财务文档化借记规则与低余额停止阈值。
5. 销售文案与目录 live 状态完全对齐。

从 IOSOR 开始

请在 IOSOR 控制台中配置电子邮件退信与短信发送报告的 Webhook，以建立统一的预付费总账。在启动针对共享账户余额的正式业务邮件流量之前，请确认域名的 SPF、DKIM 和 DMARC 配置是否正确。在关闭测试阶段网关之前，请务必核实退信和投诉 Webhook 能否正确触发自动屏蔽，并符合财务扣款规则。

IOSOR 要点

在单一预付费总账上运行业务邮件和短信，可以彻底消除工程运维与财务团队之间的账单对账差异。统一投递日志与总账扣款，确保每一次动态验证码请求、业务回执和退信事件都在一个清晰的审计追踪下有账可查。

请在通过共享钱包余额路由正式邮件流量之前，配置好自动屏蔽列表和域名身份验证网关。切勿将营销群发混入业务通道，也不要在短信依赖预付费储备的同时，让电子邮件采用独立的后付费条款。