服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 账单与发票、付款、融资、防欺诈、订阅五类邮件分别使用 [email protected]、[email protected]、[email protected]、[email protected]、[email protected]。
- AWS 把更新白名单、邮件过滤器和转发规则标为 Action required；官方页面未给出统一迁移开始、完成日期或逐账户切换顺序。
- 默认邮件对象包括 root、operations、billing、security 联系地址；额外邮箱、移动端和 Amazon Q Developer 聊天渠道须在 User Notifications 中单独配置。
- 敏感账单事件默认不会发送到额外聊天或移动推送渠道；开启需要相应 IAM 权限，不能用扩大转发范围代替权限审查。
- 迁移应保留旧规则，新增 @aws.com 与五个精确发件地址，验证实际投递和下游工单后再决定是否收紧旧规则。
- PRODUCT_FIT=NONE：这是通知治理与邮件路由问题，更换出口 IP 不能修复发件人白名单、账户联系人或敏感事件权限。
发生了什么：账单通知进入 AWS User Notifications
截至 2026 年 9 月 21 日直接核对，AWS Billing and Cost Management 官方文档把账单与发票、付款、融资、防欺诈和订阅列为五类 managed notifications。通知可出现在 Console Notification Center，并发送到账户邮箱、额外邮箱、AWS Console Mobile Application，以及 Amazon Q Developer 的 Slack 或 Microsoft Teams 集成。
官方文档没有给出一个所有账户同时切换的发布日期，也没有说明旧发件地址与新地址会并行多久。因此本文把新地址视为当前必须支持的投递路径，但不声称每个历史模板、邮件头或账户已在同一时刻完成迁移。
五类发件地址要逐项放行，不能只写一个宽泛规则
AWS 列出的对应关系是：Billing and Invoices 使用 [email protected]，Payment 使用 [email protected]，Financing 使用 [email protected]，Fraud Prevention 使用 [email protected]，Subscriptions 使用 [email protected]。原来仅匹配 [email protected] 的规则可能漏掉这些邮件。
通用 User Notifications 文档还说明聚合通知可能来自 [email protected]，并建议使用邮件 allow list 的组织加入 @aws.com 域。安全团队应根据现有邮件网关能力，决定使用受控域规则还是五个精确地址加聚合地址；不要因为迁移就绕过 SPF、DKIM、DMARC、反钓鱼或附件策略。
收件人不是一个列表：账户联系人、额外渠道与订阅分开
Billing and Cost Management 默认把邮件发送给现有账户联系人：root user、operations、billing 和 security。管理员可在 User Notifications 的 AWS managed notifications subscriptions 中，按五个子分类选择联系人，并增加经过验证的邮箱、移动端或聊天渠道。
新增邮箱会收到验证邮件，收件人必须登录添加该地址的 AWS 账户完成验证。AWS 还会把同一子分类的多个邮箱合并到一封邮件的 To/CC，并对 plus addressing 做账户级去重；因此下游解析不要把收件人数变化误判为通知丢失。
敏感事件默认边界：能订阅不等于能在聊天和移动端看到
部分账单通知包含付款和联系人等敏感信息。AWS 默认把敏感事件排除在额外聊天与移动推送渠道之外；若要把它们加入特定渠道，需要在渠道配置中开启 Include sensitive events。
查看敏感事件需要 notifications:AccessSensitiveEvents，把敏感事件关联到投递渠道需要 notifications:SubscribeSensitiveEvents。应先确认业务必要性、最小收件范围、聊天空间成员与留存规则；不要为了解决一封漏信而给所有频道扩大敏感事件权限。
六步迁移：先并行放行，再按分类验收
第一步盘点所有匹配 [email protected] 的邮件网关、SaaS 过滤器、共享邮箱、转发、SIEM、工单和财务解析规则；第二步标注 owner 与五类业务；第三步新增五个精确地址，并按策略加入 @aws.com 或 [email protected]；第四步保留旧规则；第五步在 User Notifications 核对每类联系人和额外渠道；第六步用实际收到的授权通知完成邮件、工单、聊天和审计链路验收。
没有官方通用 test email 能证明五个业务分类都成功时，不要把单次验证邮件当成完整验收。至少保存发件地址、分类、接收时间、目标邮箱、邮件网关结果、下游工单 ID 和核查人；不记录正文中的敏感付款或联系人数据。
回退与停手条件：不要过早删除旧规则
这项变更可通过保留旧 allow-list 条目来回退。新地址尚未在真实通知中出现、某类联系人为空、额外邮箱仍待验证、聊天频道成员不清楚或自动解析依赖旧模板时，应停止删除旧规则，只扩大可观测性并修复缺口。
AWS 说明邮件正文内容保持不变，更新的是视觉样式；但这不等于所有自定义解析器必然兼容。若解析依赖 HTML 结构、From 字段、To/CC 数量或固定 footer，应以脱敏样本重放测试。确认连续覆盖账单周期与高风险通知后，再由邮件和财务 owner 决定是否收紧旧地址。
失败排查：投递、订阅、权限和网络分层
完全收不到时先查邮件网关日志、隔离区和 allow list；只缺某一类时查该子分类联系人和订阅；额外邮箱收不到时查验证状态；聊天或移动端缺敏感事件时查 Include sensitive events 与两项 IAM 权限；重复或收件人减少时查 To/CC 合并和 plus-address 去重。
Console 或 API 本身出现 DNS、TLS、407 或超时，才进入站内《代理连接系统排查清单》。网络恢复不能替代邮件白名单、订阅、邮箱验证和 IAM 修复；连续出现欺诈或付款通知缺失时应停止自动化变更并由账户、安全与财务 owner 联合处理。
资料来源
常见问题
AWS 账单邮件现在会从哪些地址发送？
官方列出 [email protected]、[email protected]、[email protected]、[email protected] 和 [email protected]；聚合 User Notifications 还可能来自 [email protected]。
只放行整个 @aws.com 域就够了吗？
这取决于组织的邮件安全策略。AWS 建议加入 @aws.com 域，但安全团队仍应保留反钓鱼验证，并可选择五个精确地址加聚合地址的更窄规则。
可以立刻删除 [email protected] 旧规则吗？
不建议。官方没有公布所有账户统一切换和旧地址重叠结束时间，应先并行保留，完成各分类真实投递和下游处理验收后再决定。
哪些账户联系人默认会收到通知？
AWS 文档列出 root user、operations、billing 和 security 联系地址；具体订阅仍应在 User Notifications 中按子分类核对。
为什么聊天或移动端看不到敏感账单事件？
敏感事件默认排除在额外聊天和移动推送之外。开启还需要 Include sensitive events 以及 AccessSensitiveEvents、SubscribeSensitiveEvents 权限。
更换代理或固定 IP 能修复账单邮件漏收吗？
不能。邮件漏收应先查 allow list、订阅、联系人、邮箱验证和 IAM；只有 Console 或 API 存在明确网络错误时才检查出口链路。