Apple 將原本一次過統一兩項私隱功能電郵網域的計劃拆開處理。公司在 6 月宣布，iCloud+「隱藏電郵地址」（Hide My Email）和「使用 Apple 登入」（Sign in with Apple）日後都會採用 @private.icloud.com；但 Apple 於 8 月 24 日更新開發者公告，確認 Hide My Email 新別名會繼續使用 @icloud.com。至於 Sign in with Apple，新生成的轉發地址仍會在 2026 年稍後由 @privaterelay.appleid.com 轉用 @private.icloud.com，現有地址則會繼續正常轉寄，不會中斷。10

今次到底改咗乜？

Apple 6 月原定將兩項功能的新電郵地址集中到同一個 @private.icloud.com 網域。原有的 Hide My Email 地址（@icloud.com）及 Sign in with Apple 地址（@privaterelay.appleid.com）則預計會繼續有效和轉寄郵件。15

更新後的安排如下：

• iCloud+ Hide My Email： 新別名繼續使用 @icloud.com。
• Sign in with Apple： 新的私密轉發地址將於 2026 年稍後使用 @private.icloud.com。
• 現有 Sign in with Apple 地址： @privaterelay.appleid.com 地址仍然有效，並會繼續轉寄郵件。

Apple 只表示，撤回 Hide My Email 網域改動是經過「進一步考慮」及參考社群意見後作出的決定，並沒有指明是任何一宗安全披露直接導致這個改動。10

點解用戶反對 Hide My Email 改用新網域？

爭議重點並不是改用 @private.icloud.com 就會自動暴露背後真正的收件地址，而是這個網域本身太容易表明：這是一個由 Apple 私隱轉發服務產生的電郵別名。

網站或 App 只要進行簡單的網域檢查，就可以識別這類地址，繼而拒絕註冊、要求用戶改用另一個電郵，甚至將它視為防止濫用或風險評估的訊號。換句話說，Hide My Email 會更容易在註冊頁面被「一刀切」封鎖。44

相比之下，@icloud.com 同時用於一般 iCloud 電郵地址。網站若想分辨隱藏別名和普通郵箱，難度會高一點。這正是用戶反彈的核心：即使 Apple 背後的轉發機制沒有改變，專用的 @private.icloud.com 仍可能削弱 Hide My Email 的實際私隱效果，以及讓地址看起來像普通電郵、保留「合理否認空間」的能力。35

使用 Sign in with Apple 的開發者要做咩？

對開發者來說，今次不是舊網域被新網域完全取代，而是一段需要兼容兩套網域的過渡期。

同時接受兩個轉發網域

帳戶系統、電郵格式驗證、正則表達式、允許清單，以及任何按網域作出判斷的程式邏輯，都應接受：

• 現有地址：@privaterelay.appleid.com
• 日後新地址：@private.icloud.com

Apple 早前的開發者指引亦曾提到 @icloud.com 相關轉發處理，因此系統不應假設 Apple 只有一個固定的轉發網域。810

最重要的是，不要因為用戶的地址仍然是舊格式，就要求他們重新開戶、改電郵或令帳戶失效。Apple 表示，現有 @privaterelay.appleid.com 地址會繼續使用及轉寄郵件，不會中斷。10

檢查寄出電郵的轉發設定

如果網站或 App 需要經 Apple 私密電郵轉發服務向用戶發送通知、驗證信或帳戶復原電郵，就要在 Apple Developer 帳戶內登記用來寄信的網域及子網域。Apple 的設定指引亦要求相關寄信來源通過 SPF 檢查。6

開發團隊應逐項檢查：

• 已登記的寄信網域及子網域
• DNS 內的 SPF 記錄
• 電郵驗證及帳戶復原流程
• 允許清單及封鎖清單
• 是否有資料庫欄位或結構假設電郵只有固定網域
• 客戶支援及帳戶查找工具是否以電郵尾綴配對用戶

Apple 文件指，私密轉發服務會將郵件轉送至用戶 Apple 帳戶內已驗證的電郵地址。3

近期私隱披露，點樣影響大家理解今次決定？

Hide My Email 網域爭議，正好發生在 Apple 私隱系統接連受到關注之際。不過，這些事件並不代表 @private.icloud.com 本身會泄露用戶的真正電郵或 IP 地址；它們較像是解釋用戶點解會對任何令私隱別名更容易被分類的改動格外敏感。

Hide My Email 的垃圾郵件退信漏洞

有報道指，Hide My Email 曾存在一個漏洞：當寄往隱藏別名的郵件被判定為垃圾郵件並退回時，寄件方的郵件傳輸紀錄可能顯示別名背後的真正電郵地址，從而削弱功能最重要的私隱承諾。Apple 表示已於 2026 年 7 月 3 日部署修正，之後的測試亦指問題已無法重現。474954

不過，修補程式未必可以抹走過往已經外流的資料。第三方郵件系統可能保留舊有傳輸紀錄，因此在修正前曝光的地址，仍可能存在於 Apple 無法控制的紀錄內。4860

Private Relay 被報道可泄露真實 IP

研究人員亦報告，部分與 WebKit 有關的流量可能繞過 iCloud Private Relay，令網站取得用戶真實 IP 地址。涉及的路徑包括與通行密匙（passkey）相關的 WebAuthn 請求、WebTransport，以及 DNS 預取。192023

較後的報道指，iOS 26.6.1 似乎已修正相關問題；但目前可見的證據主要是報道所指的修補結果，Apple 並未就整體架構或影響作出更完整解釋。18

這兩類問題的運作方式，和電郵網域是否容易被看穿是兩回事：Hide My Email 漏洞涉及退信時暴露真正地址；Private Relay 報告則涉及網絡流量繞過轉發路徑。兩者都未能證明 @private.icloud.com 會直接公開用戶身份。

最合理的解讀：Apple 主要是在回應「太容易被封」

目前最直接、最有根據的解釋，是用戶反對把 Hide My Email 放到一個專門的私隱網域，因為網站可以更容易識別和拒絕這些地址。Apple 的公告亦確認，撤回決定是在檢視社群意見後作出。10

同期出現的安全披露，較適合作為信任層面的背景，而不是已證實的直接原因。它們令用戶對 Apple 私隱保障的信心變得更脆弱，也令大家更難接受一項會令隱藏地址更容易被網站分類的改動；但 Apple 從未表示這些漏洞促成了網域決定。

實際結果是一個折衷方案：Hide My Email 保留較不顯眼的 @icloud.com 尾綴，而使用 Sign in with Apple 的開發者，就要準備同時支援 @private.icloud.com 和舊有的 @privaterelay.appleid.com。

Apple 將原本一次過統一兩項私隱功能電郵網域的計劃拆開處理。公司在 6 月宣布，iCloud+「隱藏電郵地址」（Hide My Email）和「使用 Apple 登入」（Sign in with Apple）日後都會採用 @private.icloud.com；但 Apple 於 8 月 24 日更新開發者公告，確認 Hide My Email 新別名會繼續使用 @icloud.com。至於 Sign in with Apple，新生成的轉發地址仍會在 2026 年稍後由 @privaterelay.appleid.com 轉用 @private.icloud.com，現有地址則會繼續正常轉寄，不會中斷。10

今次到底改咗乜？

Apple 6 月原定將兩項功能的新電郵地址集中到同一個 @private.icloud.com 網域。原有的 Hide My Email 地址（@icloud.com）及 Sign in with Apple 地址（@privaterelay.appleid.com）則預計會繼續有效和轉寄郵件。15

更新後的安排如下：

• iCloud+ Hide My Email： 新別名繼續使用 @icloud.com。
• Sign in with Apple： 新的私密轉發地址將於 2026 年稍後使用 @private.icloud.com。
• 現有 Sign in with Apple 地址： @privaterelay.appleid.com 地址仍然有效，並會繼續轉寄郵件。

Apple 只表示，撤回 Hide My Email 網域改動是經過「進一步考慮」及參考社群意見後作出的決定，並沒有指明是任何一宗安全披露直接導致這個改動。10

點解用戶反對 Hide My Email 改用新網域？

爭議重點並不是改用 @private.icloud.com 就會自動暴露背後真正的收件地址，而是這個網域本身太容易表明：這是一個由 Apple 私隱轉發服務產生的電郵別名。

網站或 App 只要進行簡單的網域檢查，就可以識別這類地址，繼而拒絕註冊、要求用戶改用另一個電郵，甚至將它視為防止濫用或風險評估的訊號。換句話說，Hide My Email 會更容易在註冊頁面被「一刀切」封鎖。44

相比之下，@icloud.com 同時用於一般 iCloud 電郵地址。網站若想分辨隱藏別名和普通郵箱，難度會高一點。這正是用戶反彈的核心：即使 Apple 背後的轉發機制沒有改變，專用的 @private.icloud.com 仍可能削弱 Hide My Email 的實際私隱效果，以及讓地址看起來像普通電郵、保留「合理否認空間」的能力。35

使用 Sign in with Apple 的開發者要做咩？

對開發者來說，今次不是舊網域被新網域完全取代，而是一段需要兼容兩套網域的過渡期。

同時接受兩個轉發網域

帳戶系統、電郵格式驗證、正則表達式、允許清單，以及任何按網域作出判斷的程式邏輯，都應接受：

• 現有地址：@privaterelay.appleid.com
• 日後新地址：@private.icloud.com

Apple 早前的開發者指引亦曾提到 @icloud.com 相關轉發處理，因此系統不應假設 Apple 只有一個固定的轉發網域。810

最重要的是，不要因為用戶的地址仍然是舊格式，就要求他們重新開戶、改電郵或令帳戶失效。Apple 表示，現有 @privaterelay.appleid.com 地址會繼續使用及轉寄郵件，不會中斷。10

檢查寄出電郵的轉發設定

如果網站或 App 需要經 Apple 私密電郵轉發服務向用戶發送通知、驗證信或帳戶復原電郵，就要在 Apple Developer 帳戶內登記用來寄信的網域及子網域。Apple 的設定指引亦要求相關寄信來源通過 SPF 檢查。6

開發團隊應逐項檢查：

• 已登記的寄信網域及子網域
• DNS 內的 SPF 記錄
• 電郵驗證及帳戶復原流程
• 允許清單及封鎖清單
• 是否有資料庫欄位或結構假設電郵只有固定網域
• 客戶支援及帳戶查找工具是否以電郵尾綴配對用戶

Apple 文件指，私密轉發服務會將郵件轉送至用戶 Apple 帳戶內已驗證的電郵地址。3

近期私隱披露，點樣影響大家理解今次決定？

Hide My Email 網域爭議，正好發生在 Apple 私隱系統接連受到關注之際。不過，這些事件並不代表 @private.icloud.com 本身會泄露用戶的真正電郵或 IP 地址；它們較像是解釋用戶點解會對任何令私隱別名更容易被分類的改動格外敏感。

Hide My Email 的垃圾郵件退信漏洞

有報道指，Hide My Email 曾存在一個漏洞：當寄往隱藏別名的郵件被判定為垃圾郵件並退回時，寄件方的郵件傳輸紀錄可能顯示別名背後的真正電郵地址，從而削弱功能最重要的私隱承諾。Apple 表示已於 2026 年 7 月 3 日部署修正，之後的測試亦指問題已無法重現。474954

不過，修補程式未必可以抹走過往已經外流的資料。第三方郵件系統可能保留舊有傳輸紀錄，因此在修正前曝光的地址，仍可能存在於 Apple 無法控制的紀錄內。4860

Private Relay 被報道可泄露真實 IP

研究人員亦報告，部分與 WebKit 有關的流量可能繞過 iCloud Private Relay，令網站取得用戶真實 IP 地址。涉及的路徑包括與通行密匙（passkey）相關的 WebAuthn 請求、WebTransport，以及 DNS 預取。192023

較後的報道指，iOS 26.6.1 似乎已修正相關問題；但目前可見的證據主要是報道所指的修補結果，Apple 並未就整體架構或影響作出更完整解釋。18

這兩類問題的運作方式，和電郵網域是否容易被看穿是兩回事：Hide My Email 漏洞涉及退信時暴露真正地址；Private Relay 報告則涉及網絡流量繞過轉發路徑。兩者都未能證明 @private.icloud.com 會直接公開用戶身份。

最合理的解讀：Apple 主要是在回應「太容易被封」

目前最直接、最有根據的解釋，是用戶反對把 Hide My Email 放到一個專門的私隱網域，因為網站可以更容易識別和拒絕這些地址。Apple 的公告亦確認，撤回決定是在檢視社群意見後作出。10

同期出現的安全披露，較適合作為信任層面的背景，而不是已證實的直接原因。它們令用戶對 Apple 私隱保障的信心變得更脆弱，也令大家更難接受一項會令隱藏地址更容易被網站分類的改動；但 Apple 從未表示這些漏洞促成了網域決定。

實際結果是一個折衷方案：Hide My Email 保留較不顯眼的 @icloud.com 尾綴，而使用 Sign in with Apple 的開發者，就要準備同時支援 @private.icloud.com 和舊有的 @privaterelay.appleid.com。