在依賴組織通知前，先驗證 GitHub 電子郵件

為什麼只改一個電子郵件，就可能悄悄中斷組織通知

正在停用信箱的擁有者，通常只想改一件事：郵件要寄到哪裡。但 GitHub 可能以至少三種不同角色使用同一個地址，而它們出錯的方式各不相同。

請把這些當成各自獨立的檢查。改動其中一項，不能確認其他項目也已完成。

網域限制是最常被忽略的部分

如果你的組織將通知寄送限制在已核准的網域，你打算保留的地址必須屬於該網域，而且必須完成驗證。

當組織將通知寄送限制在特定網域時，GitHub 要求該已核准網域的電子郵件必須完成驗證。來源

因此，你自己掌控的個人地址不一定會被接受。在停用舊信箱之前，請先詢問組織擁有者哪個網域已獲核准，再確認你的替代地址位於該網域，並在 GitHub 電子郵件設定中顯示為已驗證。

第二項限制排除了最省事的變通做法：

GitHub 不允許透過一次性電子郵件服務進行驗證。來源

如果替代信箱是一次性或臨時服務，請改規劃其他地址。把郵件轉寄到一次性信箱，只是同一個問題多繞一站。

別把提交地址和通知地址混為一談

提交可以顯示 no-reply 地址，這是刻意設計。

no-reply 提交作者地址是一種隱私機制，不能取代可收信且已驗證的通知信箱。來源

這在你檢查設定時很重要：在提交歷史中看到 no-reply 地址，完全無法說明組織郵件會不會寄達你。請分別檢查通知地址與登入地址。

停用檢查清單

請依序完成下列步驟，而且在每一步都完成之前，不要關閉舊信箱。

1. 列出舊地址扮演的角色。 登入、復原、通知寄送與公開提交身分。記下舊信箱目前負責其中哪些角色。
2. 先新增替代地址。 在移除任何東西之前，先把它加入帳號並完成驗證。
3. 確認已核准的網域。 詢問組織擁有者哪個網域已獲准用於通知寄送，並確認你的替代地址符合該網域。
4. 排除一次性服務。 如果替代地址依賴臨時電子郵件供應商，請改用其他地址。
5. 讓復原方式保持在你掌控之下。 確保在整個變更過程中，你仍能在自己掌控的地址收到登入與復原郵件。
6. 寄送測試。 觸發一則影響較小的組織通知，確認它寄達新信箱。
7. 到這時才停用舊信箱。 在你看到真實郵件寄達替代地址之前，請保留回頭路。

決策表：替代地址準備好了嗎？

常見的失敗情況

• 驗證錯地址。 你驗證了個人地址，但組織只寄送到已核准網域。郵件會悄悄停止寄送。
• 太早移除舊地址。 帳號本身可能還需要驗證郵件。在新信箱經過實證之前，請讓舊信箱保持開啟。
• 信任提交身分。 乾淨的 no-reply 提交地址看起來像一切都設定好了，但它完全不能說明通知寄送狀況。
• 使用免洗信箱。 它無法通過限制寄送的驗證，也不適合用來接收復原郵件。

如果你無法確認已核准的網域，請把這次遷移視為尚未完成。詢問組織擁有者，不要自行猜測。

本指南未涵蓋的範圍

本文不說明 GitHub 目前的選單標籤、確切字元規則，或每種方案類型的操作步驟。這些細節會變動，應在你自己的設定與組織文件中查核。上述檢查著重於角色與驗證，而非特定畫面配置。

相關的下一步任務

組織郵件穩定之後，你可能會想知道還有哪些帳號綁定在你即將停用的地址上。這與通知寄送是不同問題，相關說明請見用電子郵件地址尋找帳號指南。

如果你想先快速掃描公開個人檔案，TraceSeek 可跨 3,000+ 個平台檢查使用者名稱，首次掃描免費且無需註冊。公開比對結果只是線索，不能證明帳號屬於同一個人，因此任何重要事項都請直接查證。