Sign in with Apple 私密轉送網域更新：帳號系統要接受 private.icloud.com

使用 Sign in with Apple 登入時，使用者可以選擇隱藏自己的真實電子郵件地址。服務收到的會是一組由 Apple 提供的轉送地址；後續寄往這個地址的信件，才會由 Apple 轉送至使用者實際收件匣。

Apple 近期公告，Sign in with Apple 的私密電子郵件轉送服務新增 private.icloud.com 網域。對已使用這項登入方式的網站與 App 而言，這是一項小而重要的調整：帳號系統若會寄出驗證信、登入通知或密碼重設信，需要確保寄件網域已納入 Apple 的設定範圍。

這次更新改了什麼

Sign in with Apple 提供「隱藏我的電子郵件」選項時，使用者不必把個人信箱直接交給服務。系統會產生專屬的私密轉送地址，讓服務仍能以電子郵件聯絡使用者，但不會直接取得其真實地址。

Apple 表示，私密電子郵件轉送服務新增了 private.icloud.com 網域。既有服務若只依賴舊有網域格式辨識地址，或在郵件設定中只登錄了部分寄件網域，便可能需要重新檢視設定。

這不代表每一位 Sign in with Apple 使用者都會立刻遇到登入問題。較常受到影響的情境，是服務需要寄出帳號相關信件，而信件無法順利透過私密轉送服務送達。

為什麼 Apple 要調整轉送網域

從使用者角度看，隱藏電子郵件地址能降低在不同服務間重複提供真實信箱的需求，也讓使用者保有停用特定轉送地址的選擇。對 Apple 而言，這類私密轉送服務需要持續維護可辨識、可擴充的郵件網域與傳遞機制；新增網域可為服務營運保留調整空間。

我們認為，這項更新也提醒帳號系統設計不宜把某一種電子郵件地址格式視為永久固定。使用者所見的是一次登入選擇，服務端面對的則是長期的帳號通知責任：註冊後能否收信、改密碼時能否驗證、重要安全通知能否抵達，都會影響使用體驗。

Apple 的官方文件同時說明，寄送給私密轉送地址的郵件，應由開發者先在 Apple Developer 帳號中登錄寄件電子郵件地址或網域。這項設計有助於限制未授權寄件來源，也表示郵件可達性不能只靠應用程式成功送出信件來推定。

對網站與 App 的實際影響

若服務提供 Sign in with Apple，且會寄送帳號驗證、訂單通知、客服回覆或安全提醒，這次變更最值得留意的是郵件流程。寄件系統可能由公司自建郵件主機、雲端郵件服務或交易通知平台處理，但寄件網域仍應能對應到 Apple Developer 後台的設定。

使用者端通常不需要手動更新。若使用者曾選擇隱藏電子郵件地址，仍可在 Apple 帳號相關設定中管理哪些 App 使用此功能，以及是否停止特定地址的轉送。

同時也要保留限制：私密轉送地址的目的在於降低真實信箱曝光，並不保證所有郵件都一定送達。寄件端若未正確登錄、信件內容被郵件系統判定為不適合轉送，或使用者停止轉送，服務便可能無法依原本方式聯絡對方。因此，涉及帳號恢復或重要交易時，仍應提供清楚的站內通知與聯絡支援管道。

使用 Sign in with Apple 前可先確認的事項

對一般使用者來說，選擇隱藏電子郵件地址前，可簡單確認以下幾點：

• 這項服務是否需要以電子郵件完成帳號驗證或接收重要通知。
• 是否知道可在 Apple 帳號設定中查看與管理已使用的私密轉送地址。
• 若日後停止轉送，是否仍保有其他方式登入帳號或聯絡服務支援。
• 服務的通知設定是否已開啟，避免只依賴電子郵件接收重要訊息。

對提供服務的一方，較合適的做法是把這次公告視為例行維運資訊：確認寄件網域與 Apple 的登錄資料一致，並用實際測試帳號檢查驗證信與帳號通知是否能送達。這些檢查不需要改變既有登入流程，卻能及早發現使用者看不見的郵件中斷。

結論

private.icloud.com 的加入，是 Sign in with Apple 私密電子郵件轉送服務的網域更新。它反映出隱私登入功能並非只停留在登入按鈕，而是連結到後續的帳號通知與郵件維運。

使用者可依自己的隱私需求選擇是否隱藏電子郵件地址；提供網站或 App 的團隊，則應依 Apple 官方說明維護寄件網域設定，並保留不依賴單一電子郵件管道的帳號支援方式。