Email 正規化檢查器用來判斷一批信箱地址在 Gmail 規則下是否可能指向同一個收件匣。產品、成長、客服、資料營運與 QA 團隊，都可以用它檢查註冊名單、CRM 聯絡人、客服紀錄或測試帳號。

這個頁面處理的不是「信箱是否存在」，而是更常見的資料問題：當這些地址進入註冊系統、名單表、等待名單、客服系統或測試資料庫時，哪些看起來不同的 Gmail 地址應該被放進同一個比對群組？

最後審閱日期：2026 年 6 月 23 日。本頁關於 Gmail 點號規則的說明，參考 Google Help 對 Gmail 點號地址的公開說明；關於加號地址的說明，參考 Gmail 官方部落格對加號與點號用法的介紹。

Google Help：Dots don't matter in Gmail addresses
Gmail Blog：Using plus signs and dots in Gmail addresses

什麼是 email 正規化

Email 正規化是把「看起來不同」的 email 字串轉換成穩定的比對形式。這個比對形式可用於去重、報表統計、異常排查、測試資料整理與客服核對。

它不是 email 驗證。正規化不會證明收件匣存在，也不會證明某個人擁有該地址。它只是把明確的服務商規則透明呈現，讓你在合併聯絡人、限制重複註冊或排查資料問題前，有更可靠的判斷基礎。

本工具採用的規則

輸入範例	正規化結果	為什麼會變更
`John.Smith+promo@GMAIL.com`	`johnsmith@gmail.com`	Gmail 網域以小寫比對，加號標籤會被移除，使用者名稱中的點號會被忽略。
`john.smith@googlemail.com`	`johnsmith@gmail.com`	`googlemail.com` 會對應到 `gmail.com` 進行比對。
`Alex@Example.COM`	`Alex@example.com`	只統一小寫網域，本機端名稱保持原樣。
`john.smith+promo@outlook.com`	`john.smith+promo@outlook.com`	非 Gmail 地址不套用 Gmail 的點號或加號規則。
`not an email`	無效資料列	保留在結果裡，方便回到來源檔修正。

這裡採用保守策略。不同郵件服務商對本機端名稱的解讀不一定相同；如果把 Gmail 規則套到所有網域，可能會把本來不同的使用者、lead 或客戶紀錄錯誤合併。

適合哪些實務情境

註冊系統去重

使用者可能用 john.smith@gmail.com、johnsmith@gmail.com、john.smith+app@gmail.com 或 john.smith@googlemail.com 進入同一個產品。正規化地址可作為重複檢測線索，協助你在註冊統計、等待名單、邀請名單或使用限制中找出潛在重複。

CRM 名單整理

業務與行銷團隊常從表單、活動報名、合作夥伴名單、廣告 lead 與人工紀錄中匯入 email。正規化能先把 Gmail 變體聚合出來，再決定是否合併聯絡人、調整負責人或修正來源歸因。

QA 與 staging 資料

測試人員常用 name+reset@gmail.com、n.ame+invite@gmail.com、name@googlemail.com 這類地址測試重設密碼、邀請信、通知信與註冊流程。檢查重複群組能幫助你判斷這些測試地址是否實際落在同一個比對鍵，避免誤判測試結果。

客服與信任安全核對

當使用者提交的 email 與系統紀錄不完全一致時，客服可以用正規化結果協助定位同一帳號。信任安全團隊也可以把重複群組當成排查信號，但仍應保留原始地址與操作紀錄。

如何理解檢查結果

正規化地址適合作為比對鍵，不適合直接替換使用者看到的 email。原始地址仍應保留，因為使用者可能認得它，郵件標頭可能出現它，稽核紀錄也需要知道當時提交的真實字串。

套用規則說明工具為何改寫某一列。Gmail 地址可能同時命中「移除加號標籤」與「移除點號」；企業網域通常只應該命中「網域轉小寫」。

重複群組表示多筆有效地址正規化後得到同一個比對鍵。它不是欺詐結論，也不是自動合併帳號的充分條件；它更適合作為人工審核、資料清理或產品邏輯判斷的入口。

建議的資料欄位設計

如果你準備在產品或後台系統中落地 email 正規化，建議同時保存原始值與正規化值：

欄位	建議用途
`email_original`	使用者提交或外部系統匯入的原始 email。
`email_normalized`	用於去重、統計與排查的比對鍵。
`normalization_rules`	記錄命中了哪些規則，方便除錯與稽核。
`provider_family`	粗粒度標記為 `gmail` 或 `other`，避免誤以為所有服務商規則相同。
`verified_at`	單獨記錄 email 驗證時間，不要用正規化結果取代驗證。

這樣可以保留使用者看得到的地址，同時讓後台穩定進行去重與統計。

上線前檢查清單

資料進入系統時產生正規化鍵，但不要覆蓋原始 email。
只對 gmail.com 與 googlemail.com 套用 Gmail 點號和加號規則。
把正規化結果視為重複檢測線索，而不是 email 歸屬證明。
對重複群組先做審核，再決定是否合併帳號、lead 或客戶紀錄。
為大小寫網域、Gmail 加號標籤、Gmail 點號、googlemail.com、無效輸入和非 Gmail 地址寫測試案例。
在客服、資料營運與風控手冊中說明這套規則，避免不同團隊用不同口徑處理同一批 email。

常見誤區

把所有服務商都按 Gmail 處理：這可能造成錯誤合併，尤其是企業信箱和非 Gmail 服務。
刪除非 Gmail 地址的加號標籤：有些系統可能把加號後的內容視為有效本機端名稱的一部分。
用正規化地址覆蓋使用者原始輸入：這會影響客服解釋、帳務紀錄和稽核追溯。
把正規化當成 email 驗證：確認 email 歸屬仍然需要驗證信、登入態或其他認證流程。
隱藏無效資料列：無效輸入應該保留在結果中，方便修正來源表，而不是在工具中被悄悄丟棄。

隱私與資料處理說明

這個檢查器在瀏覽器本地執行，本頁不會把輸入的 email 傳送到伺服器。如果下載 CSV，請依照客戶資料、lead 資料或測試資料的內部權限要求保存。

即使只是正規化後的 email，也仍可能識別到個人或帳號；若你的團隊處理受監管資料，應把原始 email 與正規化 email 都視為個人資料管理。

常見問題

它會驗證信箱是否存在嗎？ 不會。它只做格式檢查與服務商規則下的正規化判斷。
所有 email 都應該像 Gmail 一樣處理嗎？ 不建議。除非你掌握該服務商的明確規則，否則不要把 Gmail 點號和加號邏輯套到其他網域。
可以直接把正規化地址作為登入帳號嗎？ 可以作為去重鍵，但是否改變登入身份，需要產品、工程、安全與客服一起評估。
為什麼無效 email 也要顯示？ 因為靜默刪除會隱藏資料品質問題。保留無效列可以協助你回到來源檔修正。
已經有正規化地址，還需要保留原始地址嗎？ 需要。原始地址能還原使用者提交紀錄，也方便客服解釋帳號歷史。