“使用 Apple 登录”更换邮件域名，一个允许列表就可能让验证码消失
Apple 宣布，从 2026 年稍晚时候开始，“使用 Apple 登录”新生成的匿名转发地址将从 privaterelay.appleid.com 改为 private.icloud.com。旧地址继续转发，iCloud+“隐藏邮件地址”则在听取反馈后继续使用 icloud.com。
作者：周白｜OC 产品体验编辑
Apple 宣布，从 2026 年稍晚时候开始，“使用 Apple 登录”新生成的匿名转发地址将从 privaterelay.appleid.com 改为 private.icloud.com。旧地址继续转发，iCloud+“隐藏邮件地址”则在听取反馈后继续使用 icloud.com。
一句话结论：Apple 保证旧地址不断转，不等于开发者系统自动兼容新地址；真正可能坏掉的是邮件校验、允许列表、客服搜索和反欺诈规则。
“使用 Apple 登录”允许用户不向 App 暴露真实邮箱。Apple 为每个开发团队和用户关系生成匿名地址，再把邮件转发到用户已验证的邮箱。过去很多后端因此形成了一个简单假设：Apple Relay 地址只会以 @privaterelay.appleid.com 结尾。
域名变化会打破这种假设。如果注册接口用正则限制邮箱后缀，新用户可能无法完成开户；如果邮件服务商只允许向旧中继域发送，验证码、收据和安全提醒可能被拒绝；如果数据仓库用域名识别 Apple 账号，新旧用户会被拆成两个群体。
Apple 明确要求 App 和网站的账号系统、邮箱验证逻辑及 allowlist 同时接受 private.icloud.com 与现有 privaterelay.appleid.com。旧地址不会自动改名，也不需要迁移数据库主键。开发者应该扩大可接受集合，而不是批量替换历史地址。
这次公告还是一次政策修正。Apple 6 月曾计划把“使用 Apple 登录”和 iCloud+“隐藏邮件地址”统一到新域名；最新决定保留后者的 icloud.com。因此系统最终可能同时遇到三个相关后缀，具体来源却不同。把所有 icloud.com 地址都当成匿名邮箱同样会误判普通 iCloud 邮箱。
上线前应检查注册、登录、找回密码、通知邮件、退信处理、客服后台、风控特征和分析 SQL。最稳妥的测试不是只验证正则，而是创建新域名样例，完整走一遍邮件发送、点击和账号恢复流程。
关键事实
- 新“使用 Apple 登录”地址将采用
private.icloud.com。 - 现有
privaterelay.appleid.com地址继续工作，无需替换。 - iCloud+“隐藏邮件地址”继续采用
icloud.com。 - Apple 要求开发者更新账号系统、邮箱校验和允许列表。
OC 判断
这类更新没有新 API，却可能制造真实事故。用户不会知道验证码没来是因为开发者写死了域名；平台也不会替每个服务检查正则。兼容性工作的难点通常不在登录按钮，而在按钮后面那些多年没动过的业务规则。
为什么重要
- 对开发者：旧地址兼容与新地址放行必须同时满足。
- 对用户：错误过滤可能阻断登录、收据和账号恢复邮件。
- 对企业：身份来源不应只靠邮箱后缀推断。
评论
围绕这篇文章补充信息、提出问题或分享观察。