苹果把原本合并进行的邮件域名调整拆成了两部分。公司在 6 月宣布，iCloud+“隐藏邮件地址”和“通过 Apple 登录”将统一使用 @private.icloud.com；但在 8 月 24 日更新开发者公告后，苹果确认“隐藏邮件地址”别名仍将保留 @icloud.com。新生成的“通过 Apple 登录”地址则仍计划在 2026 年晚些时候从 @privaterelay.appleid.com 改为 @private.icloud.com，现有中继地址不会中断服务。10

这次苹果到底改了什么

苹果 6 月的原计划，是让两项隐私功能生成的新地址都使用 @private.icloud.com。旧的“隐藏邮件地址”别名（@icloud.com）和旧的“通过 Apple 登录”地址（@privaterelay.appleid.com）原本也会继续转发邮件。15

如今调整后的安排如下：

• iCloud+“隐藏邮件地址”：新别名继续使用 @icloud.com。
• “通过 Apple 登录”：新生成的中继地址将在 2026 年晚些时候使用 @private.icloud.com。
• 现有“通过 Apple 登录”地址：@privaterelay.appleid.com 地址仍然有效，并会继续转发邮件。

苹果将撤回“隐藏邮件地址”域名变更归因于“进一步考虑”以及社区反馈，并没有表示某一项具体的安全披露直接导致了这一决定。10

用户为何反对把“隐藏邮件地址”改成专用域名

争议的重点并不是：更换域名后，用户的真实邮箱就会自动暴露。真正引发担忧的是，@private.icloud.com 会明确表明该地址属于苹果的隐私中继服务。

网站或应用只要进行一次简单的域名检查，就可能识别出这类地址，随后拒绝注册、要求用户提供其他邮箱，或者将其作为反欺诈和风险筛查的信号。换句话说，专用域名可能让隐藏地址更容易在注册环节被“一刀切”屏蔽。44

相比之下，@icloud.com 也被普通 iCloud 邮箱使用。对于试图区分“隐藏地址”和普通邮箱的网站来说，使用这一通用域名的别名不那么显眼。

这正是用户反弹的核心：即使苹果的邮件转发基础设施完全不变，专用域名仍可能削弱“隐藏邮件地址”的实用隐私，以及用户在不透露真实邮箱情况下保留的模糊空间。35

使用“通过 Apple 登录”的开发者需要做什么

开发者应把这次变化视为中继域名的过渡，而不是简单替换旧域名。

同时接受新旧中继域名

账户系统、邮箱验证规则、正则表达式、允许列表以及所有依赖域名的业务逻辑，都应接受：

• @privaterelay.appleid.com
• @private.icloud.com

苹果此前的开发者说明还提到 @icloud.com 这一中继域名。因此，系统不应假设苹果只存在一个有效的中继邮箱后缀。810

尤其不要因为用户地址仍使用旧域名，就迁移、删除或冻结现有账户。苹果表示，现有 @privaterelay.appleid.com 地址会继续工作，并且邮件转发不会中断。10

检查发往用户的邮件中继配置

如果应用或网站需要通过苹果的私密邮件中继向用户发送邮件，开发者必须在 Apple Developer 账户中登记用于发送邮件的域名和子域名。苹果的配置说明还要求这些已登记的邮件来源通过 SPF 检查。6

开发团队应重点复核：

• 已登记的发信域名和子域名
• SPF 的 DNS 记录
• 邮箱验证和账户找回流程
• 允许列表与禁止列表
• 假定邮箱域名固定不变的数据库字段或数据结构
• 按邮箱后缀查找用户的客服和账户管理工具

苹果文档称，私密邮件中继会将邮件转发到用户已验证的 Apple 账户邮箱。3

近期隐私披露为何让这次争议更受关注

域名争议发生前后，苹果的其他隐私系统也出现了相关安全报告。这些事件并不能证明 @private.icloud.com 本身会泄露用户的真实邮箱或 IP 地址，但它们解释了用户为何会格外审视一项可能让隐私别名更容易被分类的改动。

“隐藏邮件地址”曾存在垃圾邮件退信漏洞

有报道称，“隐藏邮件地址”存在一个漏洞：当发往别名的邮件被判定为垃圾邮件并退回时，用户的真实邮箱地址可能出现在发件方的邮件传输日志中。这会削弱该功能最核心的隐私承诺。苹果表示已在 2026 年 7 月 3 日部署修复，之后的测试也称已无法重现该问题。474954

不过，修复并不一定能抹去过去已经产生的暴露记录。第三方邮件系统可能保留较早的投递日志，因此在修复前暴露的地址仍可能留在苹果无法控制的外部记录中。4860

有报道称 Private Relay 会泄露真实 IP

研究人员还报告称，部分与 WebKit 相关的网络流量可能绕过 iCloud Private Relay，从而暴露用户的真实 IP 地址。涉及的路径包括与通行密钥相关的 WebAuthn 请求、WebTransport 和 DNS 预取。192023

随后有报道称，iOS 26.6.1 中似乎已经修复这一问题。不过，现有报道主要提供了有关补丁的证据，苹果尚未就相关架构或影响范围作出更全面的公开说明。18

这两类问题与邮件域名是否显眼，是不同的技术机制：

• “隐藏邮件地址”漏洞涉及退信过程暴露真实邮箱；
• Private Relay 报告涉及网络流量绕过中继路径，暴露真实 IP。

它们都不能证明 @private.icloud.com 会直接泄露用户身份。但在用户眼中，这些事件无疑会放大对苹果隐私保护体系的审视，也让人更难接受一项会使隐藏地址更容易被网站识别和拒绝的改动。

如何理解苹果的撤回决定

目前最直接、证据最充分的解释，是用户担心专用隐私域名会让隐藏地址更容易被屏蔽。苹果自己的公告也明确表示，撤回决定是在进一步考虑并审阅社区反馈后作出的。10

同期曝光的安全问题更适合作为信任背景，而不是已被证实的直接原因。它们可能让用户对苹果隐私防护的信心更加脆弱，但苹果并未表示这些报告促成了域名调整。

最终结果是一种折中：

• **“隐藏邮件地址”**保留相对不显眼的 @icloud.com 后缀；
• **“通过 Apple 登录”**仍会改用 @private.icloud.com，开发者需要在过渡期同时支持新旧中继域名。

对普通用户来说，现有地址无需更换；对开发者来说，真正需要避免的是把旧域名当成失效地址，或在邮箱验证和发信配置中遗漏新域名。

苹果把原本合并进行的邮件域名调整拆成了两部分。公司在 6 月宣布，iCloud+“隐藏邮件地址”和“通过 Apple 登录”将统一使用 @private.icloud.com；但在 8 月 24 日更新开发者公告后，苹果确认“隐藏邮件地址”别名仍将保留 @icloud.com。新生成的“通过 Apple 登录”地址则仍计划在 2026 年晚些时候从 @privaterelay.appleid.com 改为 @private.icloud.com，现有中继地址不会中断服务。10

这次苹果到底改了什么

苹果 6 月的原计划，是让两项隐私功能生成的新地址都使用 @private.icloud.com。旧的“隐藏邮件地址”别名（@icloud.com）和旧的“通过 Apple 登录”地址（@privaterelay.appleid.com）原本也会继续转发邮件。15

如今调整后的安排如下：

• iCloud+“隐藏邮件地址”：新别名继续使用 @icloud.com。
• “通过 Apple 登录”：新生成的中继地址将在 2026 年晚些时候使用 @private.icloud.com。
• 现有“通过 Apple 登录”地址：@privaterelay.appleid.com 地址仍然有效，并会继续转发邮件。

苹果将撤回“隐藏邮件地址”域名变更归因于“进一步考虑”以及社区反馈，并没有表示某一项具体的安全披露直接导致了这一决定。10

用户为何反对把“隐藏邮件地址”改成专用域名

争议的重点并不是：更换域名后，用户的真实邮箱就会自动暴露。真正引发担忧的是，@private.icloud.com 会明确表明该地址属于苹果的隐私中继服务。

网站或应用只要进行一次简单的域名检查，就可能识别出这类地址，随后拒绝注册、要求用户提供其他邮箱，或者将其作为反欺诈和风险筛查的信号。换句话说，专用域名可能让隐藏地址更容易在注册环节被“一刀切”屏蔽。44

相比之下，@icloud.com 也被普通 iCloud 邮箱使用。对于试图区分“隐藏地址”和普通邮箱的网站来说，使用这一通用域名的别名不那么显眼。

这正是用户反弹的核心：即使苹果的邮件转发基础设施完全不变，专用域名仍可能削弱“隐藏邮件地址”的实用隐私，以及用户在不透露真实邮箱情况下保留的模糊空间。35

使用“通过 Apple 登录”的开发者需要做什么

开发者应把这次变化视为中继域名的过渡，而不是简单替换旧域名。

同时接受新旧中继域名

账户系统、邮箱验证规则、正则表达式、允许列表以及所有依赖域名的业务逻辑，都应接受：

• @privaterelay.appleid.com
• @private.icloud.com

苹果此前的开发者说明还提到 @icloud.com 这一中继域名。因此，系统不应假设苹果只存在一个有效的中继邮箱后缀。810

尤其不要因为用户地址仍使用旧域名，就迁移、删除或冻结现有账户。苹果表示，现有 @privaterelay.appleid.com 地址会继续工作，并且邮件转发不会中断。10

检查发往用户的邮件中继配置

如果应用或网站需要通过苹果的私密邮件中继向用户发送邮件，开发者必须在 Apple Developer 账户中登记用于发送邮件的域名和子域名。苹果的配置说明还要求这些已登记的邮件来源通过 SPF 检查。6

开发团队应重点复核：

• 已登记的发信域名和子域名
• SPF 的 DNS 记录
• 邮箱验证和账户找回流程
• 允许列表与禁止列表
• 假定邮箱域名固定不变的数据库字段或数据结构
• 按邮箱后缀查找用户的客服和账户管理工具

苹果文档称，私密邮件中继会将邮件转发到用户已验证的 Apple 账户邮箱。3

近期隐私披露为何让这次争议更受关注

域名争议发生前后，苹果的其他隐私系统也出现了相关安全报告。这些事件并不能证明 @private.icloud.com 本身会泄露用户的真实邮箱或 IP 地址，但它们解释了用户为何会格外审视一项可能让隐私别名更容易被分类的改动。

“隐藏邮件地址”曾存在垃圾邮件退信漏洞

有报道称，“隐藏邮件地址”存在一个漏洞：当发往别名的邮件被判定为垃圾邮件并退回时，用户的真实邮箱地址可能出现在发件方的邮件传输日志中。这会削弱该功能最核心的隐私承诺。苹果表示已在 2026 年 7 月 3 日部署修复，之后的测试也称已无法重现该问题。474954

不过，修复并不一定能抹去过去已经产生的暴露记录。第三方邮件系统可能保留较早的投递日志，因此在修复前暴露的地址仍可能留在苹果无法控制的外部记录中。4860

有报道称 Private Relay 会泄露真实 IP

研究人员还报告称，部分与 WebKit 相关的网络流量可能绕过 iCloud Private Relay，从而暴露用户的真实 IP 地址。涉及的路径包括与通行密钥相关的 WebAuthn 请求、WebTransport 和 DNS 预取。192023

随后有报道称，iOS 26.6.1 中似乎已经修复这一问题。不过，现有报道主要提供了有关补丁的证据，苹果尚未就相关架构或影响范围作出更全面的公开说明。18

这两类问题与邮件域名是否显眼，是不同的技术机制：

• “隐藏邮件地址”漏洞涉及退信过程暴露真实邮箱；
• Private Relay 报告涉及网络流量绕过中继路径，暴露真实 IP。

它们都不能证明 @private.icloud.com 会直接泄露用户身份。但在用户眼中，这些事件无疑会放大对苹果隐私保护体系的审视，也让人更难接受一项会使隐藏地址更容易被网站识别和拒绝的改动。

如何理解苹果的撤回决定

目前最直接、证据最充分的解释，是用户担心专用隐私域名会让隐藏地址更容易被屏蔽。苹果自己的公告也明确表示，撤回决定是在进一步考虑并审阅社区反馈后作出的。10

同期曝光的安全问题更适合作为信任背景，而不是已被证实的直接原因。它们可能让用户对苹果隐私防护的信心更加脆弱，但苹果并未表示这些报告促成了域名调整。

最终结果是一种折中：

• **“隐藏邮件地址”**保留相对不显眼的 @icloud.com 后缀；
• **“通过 Apple 登录”**仍会改用 @private.icloud.com，开发者需要在过渡期同时支持新旧中继域名。

对普通用户来说，现有地址无需更换；对开发者来说，真正需要避免的是把旧域名当成失效地址，或在邮箱验证和发信配置中遗漏新域名。