Apple 於 2026 年 8 月 24 日更新 Sign in with Apple 網域說明，確認新產生的中繼地址將在 2026 年稍後改用 private.icloud.com，而現有 privaterelay.appleid.com 地址仍會繼續轉發。Apple 官方更新沒有公布全面啟用的確切日期。你的本週動作應是先讓兩個網域並行通過帳號、郵件與風控規則，不要直接用新網域取代舊網域。
最後更新於 2026 年 8 月 30 日；日期、網域行為與相容邊界已核對 Apple Developer News、Sign in with Apple 文件及 Private Email Relay 官方說明。
這篇適合使用 Sign in with Apple，並在資料庫或後端校驗使用者郵箱網域的獨立開發者。
如果你的 App 依靠驗證碼、訂單通知或訂閱郵件觸達中繼地址，也應按郵件責任檢查。需要決定是否重新建置 App、使用遠端 Mac 和完成 TestFlight 回歸的小型團隊，同樣適用。
Sign in with Apple private.icloud.com 的遷移邊界
這次變更涉及的是新地址的網域，不是所有既有帳號資料的全量替換。Apple 已確認 private.icloud.com 將用於稍後產生的新 Sign in with Apple 中繼地址，同時保留現有 privaterelay.appleid.com 的轉發支援。官方目前沒有在公告中給出全面切換日期，因此不要先寫死一個截止日，也不要按未經確認的傳聞安排強制遷移。
你應把問題拆成四個責任面：客戶端、帳號後端、郵件系統，以及發布環境。單獨修改一條郵箱正則表達式，不能證明整條登入與通知鏈路已經相容。
| 檢查對象 | 需要接受或保留的內容 | 驗收重點 | 出錯後果 |
|---|---|---|---|
| 帳號後端 | 新舊兩個中繼網域 | 註冊、登入、恢復、合併 | 重複建號或無法找回帳號 |
| 郵件系統 | 新舊收件地址 | 驗證碼、交易信、退信與抑制列表 | 使用者登入成功但收不到信 |
| iOS、macOS、Web | 共用的郵箱分類與校驗邏輯 | 前端、API、匯入工具結果一致 | 不同平台判定不一致 |
| Xcode 與發布流程 | 需要時修正的客戶端邏輯 | Archive、TestFlight、登入回歸 | 新規則未進入實際 App |
後端應先修正身份與郵箱的角色
Apple 的身份令牌校驗需要由你的伺服器驗證簽章、iss、aud、有效期限等內容，具體欄位與驗證流程應以Apple 身份令牌校驗文件為準。郵箱網域只是登入回應中的一項資料，不能取代穩定的使用者識別值。
實務上，先搜尋下列位置是否寫死 privaterelay.appleid.com：
- 註冊 API 的郵箱格式與網域白名單。
- 資料庫欄位限制、唯一索引和匯入程式。
- 帳號合併、登入恢復及客服查詢工具。
- 風控規則、封鎖清單和管理後台搜尋。
- 前端顯示分類，以及服務端對同一帳號的判斷。
你的帳號主鍵應優先對應 Apple 回傳的穩定使用者識別值，而不是把中繼郵箱當作唯一身份。Apple 的認證流程文件可用來核對登入回應與帳號關聯方式。
新舊資料要分開測試
測試資料至少要包含三種狀態：已有 privaterelay.appleid.com 的舊使用者、新產生的 private.icloud.com 測試地址，以及一般真實郵箱。每組資料都要測試：
- 首次登入是否只建立一個帳號。
- 再次登入是否能找回原帳號。
- 修改個人資料後，郵箱欄位是否被錯誤覆寫。
- 忘記密碼或登入恢復是否仍能找到正確身份。
- 帳號合併時，是否以穩定識別值而不是郵箱文字作判斷。
測試日誌、郵箱、Apple 使用者識別值、Bundle ID、Team ID 和令牌都應先脫敏。不要把完整令牌或真實使用者地址直接貼到 issue、客服紀錄或 CI 日誌。
03郵件系統要驗證收件地址，不要混淆發信設定
private.icloud.com 和 privaterelay.appleid.com 是中繼收件地址相關的網域。你的寄信來源、已登記發信地址與 SPF、DKIM 設定，屬於另一組配置。Apple 的Private Email Relay 工作說明以及官方配置指南應作為核對依據。
郵件維護者應按郵件類型逐項發送測試，而不是只看 SMTP 是否回應成功：
- 登入驗證碼與一次性通知。
- 訂單、付款和訂閱狀態郵件。
- 服務變更、帳號安全與停用通知。
- 客服回覆和人工處理郵件。
- 退信、延遲、抑制列表與重新寄送流程。
每次測試保存脫敏後的收件網域、投遞時間、退信類型、中繼回覆與郵件服務商事件。若寄信服務顯示已接受，但使用者沒有收到，故障可能位於本地過濾、寄信來源登記、郵件服務商規則或 Apple 中繼轉發，不能直接判定為收件網域遷移失敗。
04跨平台規則與客戶端發版要分開判斷
網站、iOS、macOS、後台工具和第三方身份服務，常常不是同一套校驗程式。你需要搜尋前端表單、服務端 API、資料匯入任務與客服工具，確認它們都能處理新舊中繼地址。新使用者從網站註冊後，再登入 App，不應因其中一端仍只接受舊網域而被拒絕，或被建立成第二個帳號。
是否需要重新提交 App，可以按照下列條件判斷：
- 只改伺服器端白名單：先部署後端，完成登入和郵件回歸，通常不必重新提交 App。
- 客戶端寫死舊網域：修正網域判斷、展示分類或本地合併邏輯，然後以 Xcode 建置。
- 遠端設定可即時更新：如果校驗規則確實由伺服器或受控設定提供，可先走配置更新，但仍要測試舊版客戶端。
- 客戶端會把郵箱當身份主鍵：即使目前登入看似成功，也應修正資料關聯後再進行 TestFlight 回歸。
Apple 的Xcode Sign in with Apple 設定文件可用來核對客戶端能力設定。網站登入則應另外檢查網頁版 Sign in with Apple 配置，不要假設 iOS 設定會自動涵蓋 Web。
05發布前的可勾選驗收清單
將下列項目分派給不同維護者。每完成一項，附上測試案例編號和脫敏日誌，不要只在工作管理工具中標記「已完成」。
- [ ] 後端郵箱白名單同時接受
private.icloud.com與privaterelay.appleid.com。 - [ ] 註冊、登入、恢復、合併和資料更新均以穩定 Apple 使用者識別值作主要關聯。
- [ ] 資料庫唯一約束不會因新舊中繼郵箱而建立重複帳號。
- [ ] iOS、macOS、Web、後台與匯入工具使用一致的郵箱校驗規則。
- [ ] 驗證碼、訂單通知、訂閱郵件和客服回覆均完成投遞測試。
- [ ] 已核對 Private Email Relay 的發信來源登記、SPF 與 DKIM 狀態。
- [ ] 退信、延遲、抑制列表與中繼回覆已留下脫敏紀錄。
- [ ] 只有伺服器規則變更時，已完成後端回歸並記錄「不發版」決策。
- [ ] 客戶端存在舊網域判斷時，已完成 Xcode 建置與 TestFlight 安裝。
- [ ] TestFlight 測試涵蓋舊地址、新地址與一般真實郵箱。
- [ ] 已驗證登入不重複建號、郵件可投遞、舊使用者不受影響。
- [ ] 已準備可關閉新規則的回退開關，並確認日誌不洩漏帳號或令牌。
若你沒有本地 Mac，但需要執行 Xcode Archive 和 TestFlight 回歸，可先參考遠端 Mac 方案與使用方式。如果只是後端白名單調整，不要為了製造一次發版而增加 Mac 環境成本。
06常見問題
private.icloud.com 應加入哪些校驗規則
把新舊中繼網域同時加入後端白名單、註冊驗證、資料匯入和風控規則。檢查前端與管理工具是否沿用相同邏輯，但不要把收件網域與發信來源登記混為一談。
舊的 privaterelay.appleid.com 仍然有效嗎
Apple 已確認現有 privaterelay.appleid.com 地址仍會繼續轉發，因此舊使用者不能被迫改成新網域。你的資料庫、郵件系統和客服工具都應保留舊地址的查找與投遞能力。
網域變更是否一定要重新提交 App
不一定。只涉及後端規則時，通常可先部署伺服器並完成回歸；若客戶端寫死舊網域，或本地程式用郵箱判斷帳號，就要修正程式、重新建置，再以 TestFlight 驗收。
怎樣驗證登入與郵件投遞
使用舊中繼地址、新中繼地址和一般郵箱建立最小測試矩陣。逐一測試登入、恢復、重複建號、驗證碼、訂單通知和退信，並保存脫敏後的投遞事件與伺服器紀錄。
郵箱可以繼續作為唯一帳號識別嗎
不建議。中繼郵箱是聯絡資料，不是最穩妥的身份主鍵。帳號應使用 Apple 回傳的穩定識別值建立關聯，再把郵箱作為可更新欄位，降低網域變化造成的錯誤合併風險。
如果你的現行方案只是把舊網域硬編碼在多個客戶端、後端和郵件工具中，缺點是規則容易不一致、舊使用者可能被誤判，還會把一次後端調整擴大成不必要的發版工作。若需要在隔離分支修正客戶端並完成 Xcode 建置、TestFlight 安裝和登入回歸，租用 VpsMesh 的遠端 Mac 會比臨時購買一台只用於驗收的 Mac 更容易控制週期；但若本次只改伺服器白名單，直接部署與回歸即可，不必租用環境。你也可以先查看Mac mini 遠端租用方案與週期選擇，再按測試工作量決定是否需要臨時算力。