先界定待驗證帳戶
登記表格收到電郵地址，只表示有人輸入了這串文字，並不代表該人能接收郵件。地址可能打錯、屬於另一人，亦可能被人故意冒用。OWASP 建議在啟用帳戶功能前確認信箱控制權。商戶應把新紀錄標示為「待驗證」，並列明這個狀態可以做甚麼：例如可否瀏覽商品，但不可取回私人訂單、把該地址當作已核實的重設密碼渠道，或接收只應寄給帳戶持有人的資料。若商店同時提供訪客結帳，應把訂單流程與註冊流程分開，清楚指出收據會寄往哪個地址。寄信前讓用戶看見及更正輸入內容；郵件系統接受寄件，也不等於信箱已完成驗證。
把驗證證明綁定正確帳戶
每宗待驗證登記應有內部帳戶識別碼，驗證憑證須綁定該帳戶及當時待核實的完整電郵地址。憑證要以安全隨機方式產生，難以猜測；伺服器只儲存核對所需資料，並設定有限有效期。兌換成功時，應在同一次可靠的資料更新中把憑證標記為已使用，只啟用其所屬帳戶。用戶再開啟同一連結，頁面可以解釋連結已用，不能重複啟用或執行其他動作。若登記地址已更改，舊地址的憑證不可替新地址作證。不能單靠網址上可修改的電郵參數決定啟用哪個帳戶。OWASP 所指的一次性及限時，是伺服器真正執行的條件，不只是郵件內的一句提醒。
保護寄送與到達頁面的連結
含憑證的網址應由已設定的可信 HTTPS 網域組成，不能直接採用外來請求的 Host 標頭。這與 OWASP 對重設密碼連結的建議相同，因為兩者都攜帶可兌換的秘密。驗證到達頁應避免載入不必要的第三方程式及外連，並設定合適的 no-referrer 政策，減少完整網址外洩。應用程式紀錄、分析事件、客服工單及錯誤追蹤都不應保存完整憑證或連結。郵件要清楚說明商戶及操作目的，但「郵件已送出」不代表收件者身份已獲確認。若用戶懷疑連結有問題，應能自行返回官方網站要求重寄；即使連結有限期，有效期間外洩仍可能令不當登記被啟用。
重寄與更正要有清楚結果
真正常見的問題是手民之誤。待驗證用戶應能在受控的登記流程中更正地址，或重新開始登記；新地址要有新憑證，舊憑證須失效。重寄機制要有簡單、可理解的規則，例如新郵件取代上一封未用的連結，並直接告知用戶只應使用最新一封。系統亦要按帳戶及合適的濫用訊號限制重寄頻率，避免成為轟炸郵箱的工具。若地址早已有帳戶，重寄頁不應揭露誰已註冊；中性的回應可引導用戶登入或使用正式的找回途徑。第一封郵件只是延遲，不應因此悄悄建立另一個已啟用帳戶。
向用戶說明每個狀態
確認畫面應展示輸入的地址、帳戶仍處於待驗證狀態，以及重寄和更正的方法。商戶不可承諾自己無法控制的準確到達時間。驗證郵件要清楚交代操作目的及可識別的寄件者；若收件人沒有登記，應說明可如何處理，不能要求對方回覆密碼。完成驗證後，頁面要明確顯示成功及下一步。連結過期或已用時，應解釋情況並提供重新索取方法，同時避免顯示私人帳戶資料。若顧客在另一個瀏覽器開啟郵件，連結仍可證明信箱接收能力；要取得帳戶內的私人內容，仍應走正常登入程序，不能假定該瀏覽器就是原先登記者。
用錯誤地址演練
假設顧客原想填寫 mei.chan@example.com，卻輸入 mei@example.com；後者可能是另一人的信箱。寄出連結不能讓該收件人取得顧客的購物紀錄。登記頁顯示待驗證地址後，顧客在原本的登記程序中更正。系統撤銷第一個憑證，把新憑證綁定更正後的地址，再寄出郵件。若非預期收件人稍後按下舊連結，伺服器應拒絕，亦不顯示訂單資料。正確收件人連按新連結兩次，首次才會改變待驗證狀態；第二次只會交代連結已使用。這個演練同時檢查帳戶綁定、狀態變更及真正可用的補救途徑，比單純確認「收到一封信」更有價值。
驗收伺服器判斷
驗收要測試伺服器真正作出的授權決定，不能只看按鈕是否變灰。以未驗證帳戶直接開啟受保護網址及 API，再測試有效、逾期、已用、格式錯誤、屬於其他帳戶的憑證；也要測試更正地址、連續重寄，以及兩個請求同時兌換。預期只有一個請求可完成狀態轉換，舊連結不能復活，私人資料始終受到保護。英文及繁體中文頁面應對同一狀態作相同解釋，補救連結亦要可用。檢查分析及紀錄有否洩漏憑證，並確認到達頁的 referrer 行為。最後模擬郵件延遲及退信：用戶應看見真實的待驗證狀態及返回途徑，員工亦要有調查方法，而不是憑猜測把未知信箱標為已驗證。
誠實界定驗證的意義
按下電郵連結，只能證明兌換當刻有人可控制該信箱，不能證明法律姓名、公司身份，亦不能保證日後永久控制。普通零售帳戶可以評估這種證明是否足以啟用一般功能；涉及敏感紀錄的服務，對高風險操作仍需其他核實措施。資料紀錄應分開保存帳戶建立狀態及驗證完成時間。日後若更改地址，應採用獨立的電郵變更程序，而不是再次使用註冊連結。產品需求亦要寫清楚這個界線，讓客服明白「郵件已送出」、「有人打開郵件」和「正確憑證已兌換」不是同一件事，不能把其中一項當作全部身份證明。
分清寄送失敗與驗證失敗
電郵服務商接受寄送請求後，郵件仍可能退回、延遲或落入垃圾郵件夾；任何一種情況都不代表信箱已驗證。系統內部應分開「已要求寄信」、「寄送失敗」和「地址已驗證」，對用戶的說法也不能超出服務商真正知道的事。頁面先讓登記者核對所顯示的地址，再提供重試與客服途徑；客服不應要求對方轉寄仍有效的秘密連結。調查退信的員工只需看到經遮蔽的地址、時間及錯誤類型，不應看到憑證。若多次寄送失敗，待驗證帳戶可能需要明確的到期或清理規則；但不能毫無提示地刪除仍與訪客訂單有關的紀錄。
避免地址比較造成帳戶衝突
登記時如何比較電郵地址，也會影響帳戶安全。OWASP 建議網域部分採用小寫作比較、保留用戶原本輸入的地址供顯示，並避免擅自套用某供應商的規則，例如自行刪除帳號部分的點號，除非系統確實能控制相關行為。商戶應訂明註冊、登入及找回帳戶共同使用的比較政策，再以大小寫及外觀相似的地址測試。不能因為某項猜測認為兩個信箱「大概相同」，就合併兩宗待驗證登記。若地址與現有帳戶衝突，應引導用戶走正常登入或找回途徑，避免披露受保護資料。驗證連結只對特定地址及待驗證身份有效，不能用來改寫另一名顧客的既有帳戶。
給客服一份有限度調查清單
客服要有處理「收不到郵件」及「我沒有登記」的決策清單。先確認對方使用官方網站，以及頁面上經遮蔽的待驗證地址；再查看寄送結果、退信狀態及重寄限制，不能代客閱讀或傳送憑證。對意外收到郵件的人，應說明不兌換連結便不會完成該次驗證，並提供舉報濫用方法；不能透露誰輸入了其地址。若反覆出現惡意登記，再交由濫用控制程序處理。客服個案結論與帳戶驗證狀態要分開記錄，避免一則支援備註意外變成授權。這個營運安排，令安全的憑證設計成為小團隊真正可處理的顧客旅程。
推出前核對
- 待驗證帳戶不能存取私人頁面
- 只有目前有效、綁定正確而未用的憑證可啟用帳戶
- 更正及重寄後舊連結失效
