苹果要更换你的中继邮箱域名——但收回了一半决定

2026 年 8 月 24 日，苹果发布了一份开发者说明，标题平平无奇：「更新：Sign in with Apple 的新域名」。但其中有一句话真正值得关注，而且不是关于新域名的那句。

经过进一步考虑并参考社区反馈后，iCloud+「隐藏我的邮箱」地址将继续使用 icloud.com。

这是苹果推翻了十周前自己宣布的决定。而推翻的原因，恰好说明了大多数人对这类隐私功能实际运作方式的一个普遍误解：对一个邮箱别名来说，能被识别出来才是真正的失败。

关键要点

• 「使用 Apple 登录」的中继地址正在迁移，从 privaterelay.appleid.com 迁移到 private.icloud.com，从今年晚些时候开始。
• iCloud+「隐藏我的邮箱」地址保持不变，仍在 icloud.com 上。苹果原计划在 6 月迁移，8 月已取消。
• 你已经在用的地址不会受影响。 旧域名上的现有地址继续可用，继续转发邮件。
• 撤回的根本原因是：独立域名等于一条黑名单规则。 网站可以整体拒绝一个域名，但无法在不拒绝所有真实 iCloud 用户的前提下拒绝 icloud.com。
• 要预防钓鱼利用这次变更。 一个陌生的、真实归属苹果的新域名毫无预警地出现在收件箱里，正是攻击者最喜欢围绕来做文章的那种变化。

三个不同的东西，都叫「隐私」

在往下讲之前，有必要先把这几个概念理清楚，因为 6 月那份计划之所以听起来合理，正是因为把其中两者混为一谈了——而它出错的原因恰恰是：它们不是同一个产品。

1. 「使用 Apple 登录」的私人邮件中继

当你在某个 App 或网站上点击「使用 Apple 登录」并选择隐藏你的地址时，苹果会为这个具体的开发者生成一个中继地址，并把邮件转发给你。任何 Apple 账户都可以免费使用这项功能。

• 当前域名：@privaterelay.appleid.com
• 新域名：@private.icloud.com，适用于今年晚些时候起新生成的地址
• 在 Mac 上的管理入口：系统设置 →［你的名字］→ Sign in with Apple

2. iCloud+「隐藏我的邮箱」

这是一项付费的 iCloud+ 功能。你可以自己生成别名，用于任何场景——订阅邮件、表单、购物网站——并附带标签和备注，方便日后记得每个别名是干什么用的。它不绑定任何登录流程。

• 域名：@icloud.com——保持不变
• 在 Mac 上的管理入口：系统设置 →［你的名字］→ iCloud →「隐藏我的邮箱」
• 也可以直接在 Safari 和「邮件」中，点击地址栏位并选择「隐藏我的邮箱」来使用

3. iCloud 隐私中继

这根本不是邮件功能。它是为 Safari 浏览和部分未加密流量提供的双跳中继，目的是防止任何单一方同时看到「你是谁」和「你在访问什么」。它只是恰好共享了「中继」这个词，除此之外与前两者毫无关系。我们在《iCloud 隐私中继泄露你真实 IP 地址》一文中报道过这项功能的一种真实失效场景。

这种混淆并不是读者的错：前两者都会弹出一个标着「隐藏我的邮箱」的按钮。 一个给你的是 privaterelay.appleid.com 地址，另一个给你的是 icloud.com 地址，而苹果从未把这两者的区别讲清楚过。这个共用的标签几乎可以肯定就是 6 月那份「统一域名」计划乍看之下显得合理的原因。

苹果两个版本的原话对照

值得并排阅读，因为这次修改的措辞相当精确。

2026 年 6 月 15 日：

今年夏季晚些时候，苹果将把「使用 Apple 登录」和 iCloud+「隐藏我的邮箱」使用的邮箱域名统一为单一共享域名：private.icloud.com。

两项功能新生成的地址都将使用新域名。例如：

• 「使用 Apple 登录」的地址，此前使用 privaterelay.appleid.com，将改为使用 private.icloud.com。
• iCloud+「隐藏我的邮箱」的地址，此前使用 icloud.com，将改为使用 private.icloud.com。

旧域名上的现有地址将继续正常工作并为用户转发邮件，不会中断。

2026 年 8 月 24 日：

从今年晚些时候起，新生成的「使用 Apple 登录」地址（此前使用 privaterelay.appleid.com）将改为使用 private.icloud.com。privaterelay.appleid.com 上的现有地址将继续正常工作并为用户转发邮件，不会中断。

经过进一步考虑并参考社区反馈后，iCloud+「隐藏我的邮箱」地址将继续使用 icloud.com。

两处变化。「隐藏我的邮箱」被排除在迁移之外。而时间表也从「今年夏季晚些时候」改成了「今年晚些时候」——原定的时间表其实已经推迟过去了，如果你在按这个时间做规划，这点值得留意。

为什么让「隐藏我的邮箱」留在 icloud.com 是正确的决定

原理值得弄清楚，因为它适用于所有别名类服务。

一个邮箱别名，只有在收件方无法低成本判断出「这是个别名」时才能真正保护你。一旦某项服务能够识别出别名地址，它就可以拒绝这些地址——而服务方确实有很强的动机去拒绝别名，因为一个别名用户是它无法重新识别身份、无法与数据经纪商的记录做匹配、也无法在你销毁地址后继续触达的客户。

John Gruber 在这次撤回决定公布时，直接点出了用户这一侧的诉求：

我们经常想在那些宁愿屏蔽这类隐藏邮箱地址、并试图强迫我们使用「真实」地址的网站上使用这类隐藏地址

一个独立的 private.icloud.com 域名就是一个单一字符串。任何注册表单只需一行校验代码就能拒绝它。苹果此前发出的每一个别名，都会在任何加上这行代码的网站上同时失效。

icloud.com 无法被这样对待。它是数亿人日常个人邮箱在用的域名。一项服务如果为了阻挡别名而屏蔽 icloud.com，就等于屏蔽了自己相当一部分真实客户。「隐藏我的邮箱」的保护力并非来自加密——而是来自这些别名混杂在真实地址之中，无从分辨。 把它们迁移到一个独立域名，等于抽走了这个藏身之处。

这似乎正是苹果最终得出的结论，而且是正确的结论。这也是一个罕见的案例：一项已经上线的计划，因为一个隐私层面的论证而被撤回，而不是因为技术问题。

而「使用 Apple 登录」迁移域名，为什么不是同一个问题

很容易就此得出结论，认为苹果把「使用 Apple 登录」的用户暴露在风险之中。但这个结论并不成立，其中的原因值得说清楚。

「使用 Apple 登录」的中继地址本来就处在一个独立的、一眼就能识别出来的域名上。privaterelay.appleid.com 本身就在「自报家门」。任何想要拒绝这类地址的服务，自 2019 年起就一直可以这么做。迁移到 private.icloud.com，在「是否可被识别」这条轴上只是一次平移——换了一个同样可识别的域名，而不是从「不可识别」变成「可识别」。

还有一个结构性原因，使得这里的风险敞口影响更小。「使用 Apple 登录」的中继地址不是你手动填进表单里的东西，而是作为一项该网站自己选择接入的认证流程的一部分被生成出来的。一个不想要中继地址的网站，根本不会接入「使用 Apple 登录」。让「隐藏我的邮箱」变得脆弱的那种「被屏蔽」场景，在这里基本不会出现。

所以老实说，事情的全貌是：苹果保护了真正需要保护的那项功能，迁移了不需要保护的那项。 6 月的计划原本会伤害其中一个功能，而苹果及时发现并纠正了这一点。

这对你实际意味着什么

对大多数人来说影响很小——但有些细节值得提前了解，免得日后被打个措手不及。

你现有的地址不会改变。 你已经拥有的每一个 privaterelay.appleid.com 地址都会继续工作、继续转发。苹果在两份公告中都明确说明了这一点。你不需要更新任何东西，不需要在任何地方重新注册，也不需要迁移账户。

新的登录会生成一个你之前没见过的域名。 变更生效后，在新服务上使用「使用 Apple 登录」会生成一个 private.icloud.com 域名下的地址。如果你有记录「哪个别名对应哪个服务」的习惯，从此以后这份列表里就会出现两个域名。

少数网站会拒绝识别新域名。 任何在注册校验、白名单或反滥用规则里硬编码了 privaterelay.appleid.com 的服务，在更新之前都无法识别 private.icloud.com。苹果的说明中明确要求开发者同时接受两个域名，但不是所有人都会去读这份说明。

企业邮件过滤规则可能会拦截邮件。 如果你在工作相关场景中使用「使用 Apple 登录」，而所在组织按发件人或收件人域名做过滤，一个全新的域名可能会被扣在隔离区里。

钓鱼窗口期

这是真正涉及安全风险的部分，也是目前几乎没人写到的部分。

苹果这次公告面向的是开发者。没有面向普通消费者的公告，没有系统设置里的通知，也没有发给用户的邮件。大多数人第一次接触到 private.icloud.com，很可能就是它毫无预兆地直接出现——出现在发件人一栏、账户设置页面，或密码管理器的条目里。

一个真正归属苹果、却让人感到陌生的域名，在一次已经公开报道过的迁移过程中毫无预警地冒出来——这几乎是钓鱼活动梦寐以求的完美条件。钓鱼邮件几乎不用费心编写：你的 Apple 中继地址正在迁移，请确认你的账户，以免失去你曾用它登录过的服务的访问权限。

不管这次变更如何，以下几条规则始终成立：

• 苹果不会要求你为这次迁移做任何操作。 任何要求你确认、验证、迁移或重新认证中继地址的消息都是欺诈信息。这里不存在需要用户操作的步骤，因为原本就没有这一步。
• 永远不要点击「关于你 Apple 账户」的邮件里的链接。 自己主动打开系统设置去查看。如果变更是真实的，那里一定能看到。
• 仔细核对链接实际指向哪里。 private.icloud.com 才是苹果的域名。private-icloud.com、privateicloud.com、private.icloud.com.example.net 和 icloud-private.com 都不是。攻击者专门为这类时机注册这种「形似域名」。
• 一个你没有主动触发的密码弹窗，本身就是危险信号。 真正的 macOS 密码弹窗，总是紧跟在你刚刚执行的某个操作之后出现。我们在《伪造的 Mac 崩溃报告密码弹窗》一文中报道过这类伪造手段有多以假乱真。

如果你想了解更全面的加固措施，我们的《Mac 安全与隐私指南》覆盖了相关设置。

审查一下你自己实际拥有哪些

这是一个不错的检查时机，因为大多数人从来没有查过这些。

哪些 App 在使用「使用 Apple 登录」：

在 Mac 上打开系统设置，点击侧边栏顶部你的名字，然后进入 Sign in with Apple。你会看到用过这项功能的每一个 App 和网站，可以逐一单独关闭其中任何一个的「使用 Apple 登录」。

在撤销任何权限之前，先仔细看一遍这份列表。为某项服务关闭「使用 Apple 登录」会让中继地址失效，意味着该服务将无法再联系到你——包括无法用来重置密码。如果你在那里没有注册其他登录方式，就可能把自己锁在账户外面。请先设置好替代的登录方式。

存在哪些「隐藏我的邮箱」别名：

系统设置 →［你的名字］→ iCloud →「隐藏我的邮箱」。每一条记录都会显示它的标签、备注，以及转发到的地址。你可以停用一个不再需要的别名，这会停止投递，但不会删除关于它用途的记录。

邮件转发到哪里：

同一个设置面板。如果你的 Apple 账户上有多个个人地址，其中一个会作为所有别名的统一转发目标。请确认那是一个你仍在查看的地址——一个已经被你放弃使用的转发地址，是一种只有在需要账户找回邮件时才会暴露出来的静默失效。

顺手做的另外两件事

给你的别名打上合适的标签。 备注字段存在的意义，就是让你两年后还能看懂一个别名当初是为什么用途注册的。一个没有标签的别名，会是一个你不敢轻易停用的地址。

检查你的账户找回路径是否依赖某个中继地址。 如果某个重要账户唯一的联系地址是一个「使用 Apple 登录」中继地址，而你之后又撤销了那个 App 的访问权限，该账户的找回路径也会随之失效。至少保留一条不经过你可能会关闭的中继地址的找回路径。

写给开发者和管理员

如果你运营的任何系统涉及邮箱地址处理，这里有实实在在需要做的工作。苹果的要求是：

使用「使用 Apple 登录」的 App 或网站的开发者，应确保自己的账户系统、邮箱校验逻辑和白名单，在继续接受现有 privaterelay.appleid.com 域名的同时，也能接受新的 private.icloud.com 域名。

具体来说：

1. 同时接受两个域名。 不是替换，而是两者都要接受。privaterelay.appleid.com 上的现有地址会无限期保持有效。
2. 找出硬编码的字符串。 在你的代码库和配置中搜索 privaterelay.appleid.com，它可能出现在校验正则、反欺诈规则、分析用的用户分组、可送达性白名单和客服工具里。
3. 检查你的邮件服务提供商规则。 基于域名的路由、抑制列表和信誉规则都在你的代码仓库之外，也是最容易被遗漏的地方。
4. 不要在 private.icloud.com 上新建屏蔽规则。 这不仅会伤害到你自己的用户——一个你在注册环节拒绝的地址，就是一个你没能获取到的客户，而且「使用 Apple 登录」是你的 App 自己选择接入的一种认证方式。
5. 测试完整的流程。 注册、验证邮件、密码重置、账户找回全都要测。一条在注册阶段接受该地址、却在密码重置阶段拒绝该地址的校验规则，是一种真正令人头疼的 Bug，也是这类失效最常见的表现形式。

给管理员的建议：如果你按域名过滤入站邮件，请把 private.icloud.com 加入 privaterelay.appleid.com 所在的那份名单，趁用户还没开始反馈邮件丢失之前就做好，而不是等到之后才补救。

中继功能实际隐藏了什么

这一点值得说清楚，因为人们往往把对这类功能的信任，延伸到了它实际能覆盖的范围之外。

开发者拿不到的东西： 你的真实邮箱地址。他们拿到的是一个中继地址，可以向它发信，苹果会负责转发。如果你撤销授权，中继会停止工作，他们手里那个联系你的地址就会失效。

开发者能拿到的东西：

• 一个在他们 App 内的稳定标识符。「使用 Apple 登录」会为每个开发者签发一个用户标识符，该标识符在不同会话和设备间保持不变，这也是他们能识别出你是老用户的原因。这个标识符只对该开发者有效——同一个 Apple 账户在不同开发者那里会生成不同的标识符，因此两个 App 无法凭这个标识符把各自的记录关联起来。
• 你的姓名，如果你选择了分享，而且你可以在登录时编辑它。
• 你之后主动告诉他们的一切信息。中继功能只覆盖你的地址，不覆盖你的行为。如果你在某个资料字段里填了自己的真实姓名，那就是你自己交出去的。
• 他们的分析工具能收集到的一切。设备指纹、IP 地址和广告标识符完全不在这项功能的保护范围之内。

苹果能拿到的东西： 邮件会经过苹果的服务器被转发出去。苹果表示自己不会读取或保留超出投递所需的内容，但从结构上看，这条中继路径本来就是经过苹果，而不是绕过苹果。

一个干净的理解方式是：中继地址是一条可撤销的通道，而不是匿名性。 它解决的是「这家公司把我的地址卖给了数据经纪商，而我没法阻止这些邮件」这个问题，解决不了「这家公司知道我是谁」这个问题。

这确实是一件很有价值的事，而「可撤销」这一点常常被低估——能够切断某一家公司联系你的能力，而不必更改你在其他任何地方使用的地址，这是普通邮箱从未提供过的能力。

与第三方别名服务的对比

苹果并不是唯一的选择，而这个对比恰好印证了「可被屏蔽性」这个论点。

专门的别名服务——SimpleLogin、AnonAddy 等——提供数量不限的别名，通常都在与所有其他用户共享的同一个域名下。这个共享域名正是 6 月那份计划原本会为「隐藏我的邮箱」制造出来的那种黑名单目标，也正是这类服务经常被注册表单拒绝的原因。比较好的服务允许你使用自己的域名，这样能恢复「不可被屏蔽」的特性，代价是要注册并支付一个域名，而且一旦有人做关联分析，这个域名就是你独有的、可被追溯的标识。

Fastmail 及同类服务在你自己的域名或它们的域名上提供伪装地址，权衡取舍是一样的。

**苹果 iCloud+「隐藏我的邮箱」**之所以特别，恰恰在于这次被保留下来的东西：它的别名和数亿普通用户一起，共存在 icloud.com 上。它是唯一一个别名地址和真实地址无从分辨的主流别名服务。这是一种结构性优势，没有任何竞争对手能够复制，因为没有任何竞争对手拥有这种规模的消费级邮箱域名。

它的局限性也是真实存在的。苹果的别名只能转发到一个地址，除了苹果设备上的「邮件」App 之外没有从别名「代发」的功能，而且你不能使用自己的域名。如果你想要精细的路由控制，或者想从任意客户端回复邮件，专门的别名服务能做得更多。但如果你想要一个几乎在任何地方都能被接受的别名，苹果的方案是目前最强的选项——而这次它刚好保住了这个位置。

一段简史，以及旧域名为何一直有点奇怪

「使用 Apple 登录」于 2019 年上线，当时苹果 App Store 审核指南要求，任何提供第三方登录选项的 App 也必须提供这项功能——这也是为什么它几乎在一夜之间就出现在了各处，而不是慢慢普及开来的原因。私人邮件中继是它最与众不同的特性：其他登录服务商会把你的地址直接交给开发者，而苹果选择不这么做。

它交出去的地址是 @privaterelay.appleid.com。这个域名念起来很拗口，也是大多数用户在其他场合从未接触过的域名，而且它本身就「暴露」了自己的性质。从苹果的角度看这是说得通的——appleid.com 本来就是账户基础设施所在的地方——但从用户的角度看，它一直有点像是钓鱼工具会编出来的域名。

统一到 private.icloud.com 解决了这个问题。icloud.com 是普通人认得出来的域名，它的一个子域名读起来会显得可信，这是 privaterelay.appleid.com 从未真正做到过的。对于登录中继这项功能来说，这是一次直截了当的改进，这大概也是整个这次调整背后的初衷。

而 6 月的计划把这个逻辑用过了头。「统一」对本来就很显眼的那个地址是件好事；但对另一个价值恰恰在于「不显眼」的地址，却是实打实的伤害。这个纠正过程花了十周、并且需要公众的反对声音才促成，这本身就是一个很好的小案例：一项能改善某个产品的变更，可能会悄悄伤害到与它共享一个名字和一个按钮的另一个产品。

常见问题排查

某个网站把我的新 Apple 中继地址判定为无效

问题：该网站的邮箱校验逻辑还不认识 private.icloud.com。

解决方法：向该网站反馈这个问题——这是他们那边的 Bug，苹果已经公布了修复方式。与此同时，icloud.com 上的 iCloud+「隐藏我的邮箱」别名会被接受，因为这个域名不会变化，而且和任何普通 iCloud 地址一样无从分辨。这正是苹果这次特意保留下来的特性。

我用「使用 Apple 登录」登录过的某项服务不再收到邮件了

问题：有几种可能：你 Apple 账户上的转发地址是一个你已经不再查看的地址、你已经为该 App 撤销了「使用 Apple 登录」，或者你的邮件服务商正在过滤一个陌生域名。

解决方法：先到系统设置 →［你的名字］→ Sign in with Apple 确认该 App 仍处于启用状态，再到「隐藏我的邮箱」下核实你的转发地址，然后检查垃圾邮件和隔离文件夹里是否有来自新域名的邮件。

我撤销了「使用 Apple 登录」，现在无法登录了

问题：撤销授权会让对应的中继地址失效，如果该地址是账户唯一的联系方式，密码重置就没有地方可以发送了。

解决方法：直接联系该服务的客服并说明情况——这是一种已知情形，大多数服务都有人工处理路径。为避免这种情况，请在撤销任何授权之前先注册一种替代的登录方式。

我收到了一封关于我的 Apple 中继地址正在变更的邮件

问题：苹果不会就此事给用户发邮件。这次迁移不需要你做任何操作。

解决方法：把它当作钓鱼邮件处理。不要点击。如果有任何担心，自己主动打开系统设置去核实。

我在设置里找不到「隐藏我的邮箱」

问题：这是一项 iCloud+ 功能，需要付费订阅 iCloud+ 或 Apple One。如果没有订阅，只能使用免费的「使用 Apple 登录」中继功能。

解决方法：在系统设置 →［你的名字］→ iCloud 下确认你的订阅状态。如果你没有订阅，「使用 Apple 登录」的隐藏地址选项仍然可以免费使用——只是它仅限于登录流程，不能像「隐藏我的邮箱」那样用在任何场景。

常见问答

我需要做什么吗？

不需要。现有地址会继续正常工作，这次变更只影响新生成的「使用 Apple 登录」地址。这里不存在任何需要用户操作的迁移步骤，这也正是为什么任何声称需要你操作的消息都是欺诈信息。

我原来的 privaterelay.appleid.com 地址会停止工作吗？

不会。苹果在两份公告中都明确说明，现有地址会继续正常工作并持续转发，不会中断。苹果没有公布过这些地址的任何停用日期。

苹果为什么在「隐藏我的邮箱」这件事上改变了主意？

苹果自己的措辞是「经过进一步考虑并参考社区反馈」。这些反馈的实质内容是：一个独立域名会让别名地址极易被屏蔽，从而使这项功能失去意义。让这些地址继续留在 icloud.com 上，意味着它们和普通 iCloud 地址无从分辨。

「隐藏我的邮箱」和「使用 Apple 登录」的隐藏地址是同一个东西吗？

不是，尽管两者弹出的按钮文案相同。「隐藏我的邮箱」是一项付费的 iCloud+ 功能，你可以为任何用途创建 icloud.com 别名。「使用 Apple 登录」的中继功能是免费的，绑定于某个具体的 App，也正是这次要迁移到 private.icloud.com 的那个功能。

这次变更具体什么时候生效？

苹果的说法是「从今年晚些时候开始」。6 月的公告说的是「今年夏季晚些时候」，所以时间表已经推迟过一次。目前没有公布具体日期。

这会影响 iCloud 隐私中继吗？

不会。iCloud 隐私中继是一项针对 Safari 浏览的网络隐私功能，和邮箱地址没有任何关系，尽管两者恰好共用了「中继」这个词。

我应该把重要账户都改用「隐藏我的邮箱」吗？

对于重要账户来说，更值得思考的问题是：一旦这个别名被关闭，你的账户找回路径是否还能正常工作。这两套系统本身都很可靠。它们面临的风险是一样的：如果一个别名是某个账户唯一的联系方式，而你之后又停用了它，找回该账户就会变得困难。对任何你承受不起丢失的账户，都要保留第二条找回路径。

结语

这次变更的头条新闻本身很小，也不需要你做任何事：新生成的「使用 Apple 登录」地址将出现在 private.icloud.com 上，旧地址继续正常工作，唯一真正有活要干的是那些在代码里硬编码了某个域名字符串的开发者。

真正值得记住的，是苹果撤回的那部分。一项人人都能识别出来的隐私功能，就不再是一项隐私功能了——而苹果 6 月那份看似合理的「统一域名」计划，原本会把一个整套保护机制都建立在「与普通邮件混杂难辨」之上的别名系统，贴上一个任何人都能拿来做过滤的标签。这个问题被及时、公开地发现并在十周内得到纠正。这既是一个好的结果，也是一个提醒：「把两个共用一个按钮的东西统一起来」这种设计直觉，当其中一个的价值恰恰建立在「不引人注意」之上时，值得再多想一步。

与此同时：苹果不会就此事给你发邮件。任何这么做的人都不是苹果。

相关阅读：iCloud 隐私中继泄露你真实 IP 地址、Mac 安全与隐私指南，以及伪造的 Mac 密码弹窗及识别方法。