Apple 將原定的電子郵件網域調整拆成兩部分處理。公司在 6 月宣布，iCloud+「隱藏我的電子郵件」與「使用 Apple 登入」都會改用 @private.icloud.com；但在 2026 年 8 月 24 日更新說明後，Apple 決定讓「隱藏我的電子郵件」別名繼續使用 @icloud.com。另一方面，新的「使用 Apple 登入」轉寄地址仍預計在 2026 年稍晚從 @privaterelay.appleid.com 改用 @private.icloud.com，現有轉寄地址則會繼續運作，不會中斷郵件轉寄。10

Apple 這次改了什麼？

Apple 6 月的原始方案，是把兩項隱私功能新產生的地址統一到 @private.icloud.com。當時的說法是，既有的 @icloud.com「隱藏我的電子郵件」別名，以及既有的 @privaterelay.appleid.com「使用 Apple 登入」地址，仍會保留並繼續轉寄郵件。15

現在的方案則縮小為：

• iCloud+「隱藏我的電子郵件」： 新別名仍使用 @icloud.com。
• 「使用 Apple 登入」： 2026 年稍晚開始，新轉寄地址改用 @private.icloud.com。
• 既有「使用 Apple 登入」地址： @privaterelay.appleid.com 地址仍然有效，並會持續轉寄郵件。

Apple 表示，撤回「隱藏我的電子郵件」網域變更，是經過「進一步考量」並檢視社群回饋後作出的決定。Apple 並未表示這項決策是由任何特定的資安揭露事件直接促成。10

為什麼使用者反對 @private.icloud.com？

爭議重點並不是改用新網域就會自動揭露別名背後的真實信箱，而是 @private.icloud.com 會非常明顯地表明：這是一個由 Apple 隱私轉寄服務產生的地址。

網站或 App 只要檢查網域，就能辨識這類地址，接著拒絕註冊、要求使用者改填其他電子郵件，甚至把它當成防詐與風險評估訊號。換句話說，專用網域會讓平台更容易在註冊階段封鎖匿名別名。44

相較之下，@icloud.com 同時也是一般 iCloud 電子郵件地址所使用的網域。對想區分匿名轉寄地址與一般信箱的服務來說，使用 @icloud.com 的別名並不那麼顯眼。

這正是反彈的核心：即使 Apple 的轉寄基礎設施本身沒有改變，使用者仍擔心新網域會降低「隱藏我的電子郵件」的實用隱私，以及在網站面前維持「看起來像一般信箱」的空間。35

使用「使用 Apple 登入」的開發者要做什麼？

開發者應把這次變更視為轉寄網域的過渡，而不是一次性淘汰舊網域。

同時接受新舊轉寄網域

請更新帳戶系統、電子郵件驗證規則、正規表示式、允許清單，以及所有依網域執行特殊處理的程式邏輯，讓系統同時接受：

• @privaterelay.appleid.com：現有的「使用 Apple 登入」地址
• @private.icloud.com：2026 年稍晚開始發行的新地址

Apple 先前的開發者指引也曾在轉寄網域處理中提到 @icloud.com，因此系統不應假設 Apple 只會有一個固定的轉寄網域後綴。810

最重要的是，不要因為使用者的地址仍是舊網域，就要求他們重新註冊或停用帳戶。Apple 表示，既有的 @privaterelay.appleid.com 地址仍可使用，郵件轉寄也不會中斷。10

檢查寄出郵件的轉寄設定

如果 App 或網站需要透過 Apple 的私密電子郵件轉寄服務寄信給使用者，開發者必須在 Apple 開發者帳戶中登記用於寄送郵件的網域與子網域。Apple 的設定說明也要求這些已登記的郵件來源通過 SPF 檢查。6

建議團隊逐項檢查：

• 已登記的寄信網域與子網域
• SPF 的 DNS 記錄
• 電子郵件驗證與帳戶復原流程
• 允許清單與封鎖清單
• 是否有資料庫欄位或結構假設電子郵件只有固定網域
• 客服與帳戶查詢工具是否依電子郵件後綴尋找使用者

Apple 文件指出，私密轉寄地址會將郵件轉送到使用者已驗證的 Apple 帳戶電子郵件地址之一。3

近期隱私揭露，如何影響這場爭議？

網域爭議發生的同時，Apple 的其他隱私系統也傳出弱點。這些事件並不能證明 @private.icloud.com 本身會洩露真實信箱或 IP 位址，但確實有助於理解使用者為何會特別審視一項可能讓隱私別名更容易被分類的改動。

「隱藏我的電子郵件」曾有垃圾郵件退信漏洞

據報導，「隱藏我的電子郵件」的一項漏洞可能在寄往別名的郵件因垃圾郵件而遭拒時，讓寄件方的郵件傳輸紀錄顯示別名背後的真實地址，從而破壞這項功能原本要提供的隱私保護。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

這些問題與電子郵件網域的可見性是不同機制：前者涉及垃圾郵件退信可能暴露真實地址，Private Relay 報告則涉及網路流量脫離轉送路徑。兩者都不能證明 @private.icloud.com 會直接揭露使用者身分。

Apple 撤回決定的最合理解讀

目前最直接、也最有明確依據的解釋，是使用者反對專用隱私網域讓別名更容易被網站封鎖。Apple 自己的公告也確認，撤回決定是在檢視社群回饋後作出。10

近期的資安揭露更適合被視為信任層面的背景，而不是已證實的因果關係。這些事件讓使用者對 Apple 隱私防護的信心更加脆弱，也讓大家更難接受一項會使匿名地址更容易被分類或拒絕的改動；但 Apple 並未把這些報告與網域決策直接連結起來。

對使用者而言，結果是「各退一步」：「隱藏我的電子郵件」保留較不顯眼的 @icloud.com 後綴；使用「使用 Apple 登入」的開發者，則必須準備同時支援 @private.icloud.com 與舊有的 @privaterelay.appleid.com。

Apple 將原定的電子郵件網域調整拆成兩部分處理。公司在 6 月宣布，iCloud+「隱藏我的電子郵件」與「使用 Apple 登入」都會改用 @private.icloud.com；但在 2026 年 8 月 24 日更新說明後，Apple 決定讓「隱藏我的電子郵件」別名繼續使用 @icloud.com。另一方面，新的「使用 Apple 登入」轉寄地址仍預計在 2026 年稍晚從 @privaterelay.appleid.com 改用 @private.icloud.com，現有轉寄地址則會繼續運作，不會中斷郵件轉寄。10

Apple 這次改了什麼？

Apple 6 月的原始方案，是把兩項隱私功能新產生的地址統一到 @private.icloud.com。當時的說法是，既有的 @icloud.com「隱藏我的電子郵件」別名，以及既有的 @privaterelay.appleid.com「使用 Apple 登入」地址，仍會保留並繼續轉寄郵件。15

現在的方案則縮小為：

• iCloud+「隱藏我的電子郵件」： 新別名仍使用 @icloud.com。
• 「使用 Apple 登入」： 2026 年稍晚開始，新轉寄地址改用 @private.icloud.com。
• 既有「使用 Apple 登入」地址： @privaterelay.appleid.com 地址仍然有效，並會持續轉寄郵件。

Apple 表示，撤回「隱藏我的電子郵件」網域變更，是經過「進一步考量」並檢視社群回饋後作出的決定。Apple 並未表示這項決策是由任何特定的資安揭露事件直接促成。10

為什麼使用者反對 @private.icloud.com？

爭議重點並不是改用新網域就會自動揭露別名背後的真實信箱，而是 @private.icloud.com 會非常明顯地表明：這是一個由 Apple 隱私轉寄服務產生的地址。

網站或 App 只要檢查網域，就能辨識這類地址，接著拒絕註冊、要求使用者改填其他電子郵件，甚至把它當成防詐與風險評估訊號。換句話說，專用網域會讓平台更容易在註冊階段封鎖匿名別名。44

相較之下，@icloud.com 同時也是一般 iCloud 電子郵件地址所使用的網域。對想區分匿名轉寄地址與一般信箱的服務來說，使用 @icloud.com 的別名並不那麼顯眼。

這正是反彈的核心：即使 Apple 的轉寄基礎設施本身沒有改變，使用者仍擔心新網域會降低「隱藏我的電子郵件」的實用隱私，以及在網站面前維持「看起來像一般信箱」的空間。35

使用「使用 Apple 登入」的開發者要做什麼？

開發者應把這次變更視為轉寄網域的過渡，而不是一次性淘汰舊網域。

同時接受新舊轉寄網域

請更新帳戶系統、電子郵件驗證規則、正規表示式、允許清單，以及所有依網域執行特殊處理的程式邏輯，讓系統同時接受：

• @privaterelay.appleid.com：現有的「使用 Apple 登入」地址
• @private.icloud.com：2026 年稍晚開始發行的新地址

Apple 先前的開發者指引也曾在轉寄網域處理中提到 @icloud.com，因此系統不應假設 Apple 只會有一個固定的轉寄網域後綴。810

最重要的是，不要因為使用者的地址仍是舊網域，就要求他們重新註冊或停用帳戶。Apple 表示，既有的 @privaterelay.appleid.com 地址仍可使用，郵件轉寄也不會中斷。10

檢查寄出郵件的轉寄設定

如果 App 或網站需要透過 Apple 的私密電子郵件轉寄服務寄信給使用者，開發者必須在 Apple 開發者帳戶中登記用於寄送郵件的網域與子網域。Apple 的設定說明也要求這些已登記的郵件來源通過 SPF 檢查。6

建議團隊逐項檢查：

• 已登記的寄信網域與子網域
• SPF 的 DNS 記錄
• 電子郵件驗證與帳戶復原流程
• 允許清單與封鎖清單
• 是否有資料庫欄位或結構假設電子郵件只有固定網域
• 客服與帳戶查詢工具是否依電子郵件後綴尋找使用者

Apple 文件指出，私密轉寄地址會將郵件轉送到使用者已驗證的 Apple 帳戶電子郵件地址之一。3

近期隱私揭露，如何影響這場爭議？

網域爭議發生的同時，Apple 的其他隱私系統也傳出弱點。這些事件並不能證明 @private.icloud.com 本身會洩露真實信箱或 IP 位址，但確實有助於理解使用者為何會特別審視一項可能讓隱私別名更容易被分類的改動。

「隱藏我的電子郵件」曾有垃圾郵件退信漏洞

據報導，「隱藏我的電子郵件」的一項漏洞可能在寄往別名的郵件因垃圾郵件而遭拒時，讓寄件方的郵件傳輸紀錄顯示別名背後的真實地址，從而破壞這項功能原本要提供的隱私保護。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

這些問題與電子郵件網域的可見性是不同機制：前者涉及垃圾郵件退信可能暴露真實地址，Private Relay 報告則涉及網路流量脫離轉送路徑。兩者都不能證明 @private.icloud.com 會直接揭露使用者身分。

Apple 撤回決定的最合理解讀

目前最直接、也最有明確依據的解釋，是使用者反對專用隱私網域讓別名更容易被網站封鎖。Apple 自己的公告也確認，撤回決定是在檢視社群回饋後作出。10

近期的資安揭露更適合被視為信任層面的背景，而不是已證實的因果關係。這些事件讓使用者對 Apple 隱私防護的信心更加脆弱，也讓大家更難接受一項會使匿名地址更容易被分類或拒絕的改動；但 Apple 並未把這些報告與網域決策直接連結起來。

對使用者而言，結果是「各退一步」：「隱藏我的電子郵件」保留較不顯眼的 @icloud.com 後綴；使用「使用 Apple 登入」的開發者，則必須準備同時支援 @private.icloud.com 與舊有的 @privaterelay.appleid.com。