用瀏覽器底層邏輯解決驗證信痛點! Email Verification Protocol (EVP)
平時在網站註冊會員或購物結帳，大家應該都很習慣這個繁瑣的流程：填完 Email，點送出，然後到另一個分頁，去收件匣或垃圾郵件翻驗證信，再把驗證碼複製起來，回到網頁貼上。
Chrome 和國外一些老大哥最近在推一項新功能——Email Verification Protocol (EVP)，標榜能讓使用者填完信箱就直接完成驗證，根本不用去開信箱收信。
這東西聽起來很方便，正式告別信箱收驗證碼的痛苦？實際部署跑過一次前後端開發流程，才發現從瀏覽器支援到前後端協作，到處都是坑，傳統的寄驗證碼信件流程還是要留著，整個系統複雜度繼續疊加。這篇就來記錄實測過程以及開發上會踩到的地雷。
什麼是 EVP？為什麼不用寄信也能驗證信箱？
不寄信，要怎麼確認這組 email 存在，而且信箱是使用者本人的？
道理其實很直覺：直接看你瀏覽器裡有沒有登入該信箱。
使用者會看到的畫面像這樣:
1.驗證時會看到一個像這樣的瀏覽器小對話視窗
2.驗證成功後，視窗上面會跑出一條提示
3.在瀏覽器的自動填入設定的聯絡資訊內，會看到已經驗證的 email。
原則上只要成功認證過，下次走流程就不會再看到第1步的那個視窗，如果要重新測試的話就要從上圖這邊把它清掉。
讓網站偷看 Gmail 登入狀態聽起來就很可怕，但其實背後有一套看似很安全的密碼學機制：
- 在其中一個瀏覽器分頁本來就登入著 Gmail 帳號。
- 網站的網頁表單放一個隱藏欄位
<input type="hidden" autocomplete="email-verification-token" nonce="...">。 - 當你填完信箱，瀏覽器在背景向發證端點要憑證。確認你目前在瀏覽器確實有登入該帳號，就用私鑰發一張 SD-JWT 憑證塞給瀏覽器。
- 網站後端收到表單後，直接去查公開 JWKS 金鑰驗證數位簽章，並核對 DNS TXT 委派記錄與 Nonce，確認無誤就放行。
下面放一個簡易範例給有緣人玩玩:
使用 EVP 的先決條件：天選之子
這項功能要能成功觸發，使用者與網站需要同時滿足非常多條件，包括電子郵件廠商要支援、網頁瀏覽器要支援、網站程式要支援，還有一堆條件，缺一不可，簡直是天選之子才能用。
以下來稍微介紹一些必要條件
1.要手動開啟瀏覽器設定
EVP 目前還在 Origin Trial 實驗階段，瀏覽器必須先手動到 chrome://flags 開啟 EVP 的設定。
2.必須使用 Chromium 核心 150 以上的版本。
WICG/email-verification 的 GitHub repo 在2025年9月建立，過了將近一年，直到2026年7月左右才開始有 Chrome 150+ 的版本支援 EVP。
撰文時穩定版的版號是 152，用 Hermes AI 調閱網站的 GA4 API，統計了近 30 天（2026/08/04 – 2026/09/02）全站實際訪客的瀏覽器版本分佈，結果滿足條件的是少得可憐。
| 類別 | 活躍使用者 | 佔比 |
|---|---|---|
| 全站活躍使用者 | 13,031 | 100% |
| Chrome 150 以上 | 3,406 | 26.14% |
統計下來，近一個月全站只有約 26.1% 的訪客使用 Chrome 150 以上，其他人可能使用別的瀏覽器，或是版本沒這麼高，也就是說幾乎是每 4 個人只有 1 個人的瀏覽器版本符合門檻。
更何況這 26% 的人裡面，絕大多數根本不知道要去開 Flag 設定(測試期間)，也不一定完全滿足以下所有條件。現階段這項技術只能在某些情境下當作少數人的加速捷徑，不可能取代傳統驗證。
3.建議使用 Google Chrome 瀏覽器
因為不一定每個 Chromium 核心的瀏覽器都有做這功能，像 Microsoft Edge 的 flag 就直接找不到 EVP。
EVP 不是直接把用戶在當下網站域名和輸入的電子郵件地址送給郵件商的驗證伺服器，還需要透過瀏覽器作為中介來與電子郵件提供商通訊，所以需要瀏覽器也支援此功能。
但是翻閱其他瀏覽器標準組織的討論（如 Mozilla Standards Position #1316、WebKit #578），跟桃園鐵路地下化全線通車一樣遙遙無期。
4.使用者必須正好在同一個瀏覽器中，登入該 Email 帳號。
官方在Test the Email Verification Protocol with an origin trial的原文是這樣寫:
The user must be signed in to their email provider or issuer on the same browser profile. For example, if they use Gmail, they must be signed into their Google Account.
但我實測發現，一人多帳的，不一定要真的把每個 Google 帳號都登入 Chrome Profile (瀏覽器右上角的頭像)，像我的 Google Chrome 只登入一組 Chrome Profile，然後在瀏覽器分頁分別登入不同 Gmail 帳號，這樣也是能驗證。
但使用者不一定有在裝置上登入 Gmail 啊!
例如我在圖書館公用電腦上填問券調查表單，基於隱私考量，我根本不可能在這電腦上登入私人 Gmail。這時候如果在表單輸入個人信箱，表單想用 EVP 來驗證，Chrome 因為在本地找不到該帳號的登入狀態，根本生不出憑證，只能乖乖走傳統的寄信驗證碼流程。我只能掏出手機收信，在電腦上填上驗證碼。
驗證控制權這很合理，畢竟如果信箱沒登入也能驗證成功，任何人都能隨便輸入別人的信箱冒用了。
至於採用「在同一個瀏覽器登入」這個條件，在某些使用場景還是不太方便了。按照慣例，這種不方便就是設計師和工程師該死，那些決定規則的國外大廠都能置身事外。
5.信箱所屬的網域要正確設定額外的 DNS
信箱所屬的網域必須在 DNS 設定好指向 Issuer 的 TXT 記錄。
流程中會去驗證電子郵件地址網域的 _email-verification DNS 記錄，然後根據記錄值再順著網路線，到電子郵件服務供應商的那邊去驗證。
6.電子郵件服務供應商也要實做驗證機制
承上一點，使用的電子郵件服務供應商如果沒有導入這套驗證機制，DNS 沒有把 _email-verification 的值加好，就通通武功全廢。
全球真正實作並部署發證伺服器的，只有 Google（Gmail / Workspace）一家，其他家微軟 Outlook、Yahoo、Apple 跟進遙遙無期。
微軟（Outlook / Hotmail / Microsoft 365）在公開消息中完全沒有任何關於 EVP 的消息；商務市場有極大比例的企業依賴微軟 Office 365 企業信箱。只要微軟不支援，任何輸入 @outlook.com、@hotmail.com 或微軟代管企業信箱的使用者，EVP 通通無效，全球覆蓋率直接少了一大半。
7.網站需要調整程式，程式需要走後端驗證。
並不是更新瀏覽器之後，以後網頁上要驗證 email 的地方，就會自動變成按一下就能輕鬆驗證。
購物網站、活動報名網站自己也必須要調整程式，前端表單要加上 <input type="hidden" autocomplete="email-verification-token" nonce="...">，後端要串 Google 的 JWKS 公鑰驗證 SD-JWT 簽章，還要核對 DNS TXT 記錄與 Nonce。
以下繼續詳談其他 EVP 導入地雷。
轉發型信箱根本無法驗證
現在不少站長會用 Cloudflare Email Routing、Firefox Relay 之類的郵件轉發服務，對外公開自訂域名信箱，背後轉寄到個人 Gmail。
但這類轉發型信箱，天生完全無法支援 EVP。
因為 EVP 需要一個能讓使用者登入的身分授權中心（Issuer）。當 Chrome 看到自訂網域時，會去查 DNS TXT 記錄尋找 Issuer。
但 Cloudflare Email Routing 純粹只是一台收信並轉發的伺服器，它根本沒有使用者的登入 Session，也沒有發證端點與公鑰庫。
你不可能在瀏覽器裡登入 Cloudflare 信箱，它自然無法向 Chrome 證明你是信箱擁有者，最終只能退回傳統發驗證信流程。
與發信商的商業矛盾
知名現代郵件發送服務商 Resend 近期也撰文介紹了這個新功能：Email Verification API
Resend 雖然撰文介紹了這個技術，卻沒有說他們的產品要「馬上開始支援或主推」這個功能。
如果你從商業利益的角度稍微思考一下，這個功能變得非常可笑。
就像當年共享計程車進入台灣，不少搭車的民眾覺得非常棒，但計程車業者卻是去抗議，因為共享計程車讓他們少賺很多錢。
對郵件發送服務商（Resend 等 ESP）也是一樣，以他們的商業模式來說，寄信量就是一大收費指標，除了一些廠商是單純寄幾封就收幾封信的錢，其他大多有精心設計一些階梯制方案，只要每天、每個月發的信件量剛好超過方案額度，就勢必得付更多錢給郵件發送服務商。
也不只郵件發送服務商，像 Zeabur 這種 PaaS 廠商，也有一些方案說是每個月附多少發信量(如上圖)，用超過就要付費升級。
如果全世界的網站通通採用了 EVP 免寄信驗證，經營網站線上服務的人再也不需要發送一大堆註冊 OTP 驗證信，那寄信的公司、相關慘業，都會少賺很多錢！
擋人財路如殺人父母的概念，大家應該都懂。一個會「讓客戶大幅減少使用自己產品」的技術，相關業者又怎麼可能全心全意替它抬轎呢？
EVP 驗證信箱擁有權，不驗證可送達性
EVP 設計一套密碼學機制，證明「使用者當前能登入這個信箱」，但「信件能不能寄得進去」又是另一碼子事，它沒辦法保證。
最常見的情況就是信箱空間爆滿，或是郵件可能被某些規則擋掉，真的寄信過去，一定會被退信（Bounced）。
使用者確實通過 EVP 驗證信箱地址是有效的，不是隨便亂填一組，不是亂填別人的信箱，但我們要寄訂單確認信、帳單，一寄過去就直接被退件......那我們一開始驗證信箱的意義在哪?
如果是需要實際寄送重要文件、憑證、電子機票、帳單的網站，光看 EVP 通過就放行是不夠的，只會引發更多客訴。確認「信箱能不能通」的寄信測試，在許多業務本質上依舊不可廢除。
各大信箱支援度和 DNS 設定問題
如果你使用的是 Google Workspace 企業信箱（例如 ceo@yourcompany.com），要先在網域 DNS 新增一筆 TXT 記錄：
- 名稱：
_email-verification(或_email-verification.yourcompany.com) - 類型：
TXT - 值：
iss=accounts.google.com
但問題是一般 Google 企業信箱根本沒設定這組 DNS 紀錄。我們工程師、科技自媒體在網路上把這功能吹到天上去，但在現實中，只要公司 IT 人員或是有域名 DNS 管理權限的人，不去設定這組紀錄，今天這功能就跟大家一點關係都沒有，所有人還是乖乖收信點連結，或是收信填驗證碼。
另一個問題又來了：又不是每家公司都用 Google 企業版，又不是每個人都用 Gmail，有人是用 Microsoft Office 365 的 Outlook 或是 Outlook.com，有人用 Yahoo! 信箱，有人用 HiNet 的信箱，那本文討論功能跟他們一點關係都沒有，大家還是乖乖收信點連結，或是收信填驗證碼。
在手機 App 與 In-App WebView 幾乎派不上用場
許多手機 App 在註冊與登入時也極度依賴驗證信，但在行動裝置的世界裡，EVP 幾乎起不了作用：
- 原生 App（iOS / Android）根本沒有網頁 DOM 和 Autofill 發證連接口。
- 很多混合型 App 為了省成本，直接用 In-App WebView 包 RWD 網頁。但 WebView 預設有嚴格的沙箱隔離，通常不共享系統 Chrome 的 Google 登入 Cookie，也叫不起底層的原生授權彈窗。
結果只要使用者是在手機 App 裡開網頁，EVP 跟他一點關係都沒有，依然必須退回傳統寄信流程。
瀏覽器 Native UI 的文字或樣式無法修改
當我們好不容易把前後端功能都打通，把 EVP 搬上測試環境給專案經理、主管或客戶驗收時，可能會遇到這種靈魂拷問：
「這個彈窗的文字能不能改成：『驗證成功就可以領取 30 元折價券』？」
「按鈕顏色能不能換成我們品牌的企業色？」
「標題能不能加上我們公司的 Logo？」
「跳出來的文案要換一下？」
「跳出來的授權畫面長得太像資安警告了，會嚇跑客人，能不能改成可愛插畫小卡片？」
這時候前端工程師只能兩手一攤：臣妾做不到啊
因為 EVP 跳出來的授權氣泡框，是瀏覽器乃至作業系統層級的 Native UI，它根本不屬於網頁 DOM 的一部分。前端的 CSS 與 JavaScript 對它完全起不了任何作用，連 1 個像素的邊距、1 個字的文字都碰不到。
所有的文案、語系、按鈕外觀與排版，全都是由 Chromium 瀏覽器核心寫死決定的。如果主管、客戶或品牌設計師非常在乎 UI/UX 的一致性與客製化文案，這項技術在視覺審核階段就直接出局了，最後依然只能摸摸鼻子退回傳統用 HTML和CSS 自己刻的驗證碼彈窗。
想到本站一篇近10年前的廢文:網頁嵌入Google 地圖的小小需求，例如顯示英文地圖，有人堅持「網頁明明是全英文版，畫面上絕對不應該出現任何一個中文字！」偏偏頁面上嵌入了 Google Maps，只要使用者是用繁體中文系統的電腦打開，不管你怎麼解釋 Google 會依照使用者環境自動切換語言，別人就是不能接受、不相信，為什麼基層工作人員不乖乖聽話改網頁，還一堆廢話?
最後為了解決這件事，還特地把簡單的嵌入地圖改成 Google Maps API，只為了在參數裡強制鎖死英文。
在網頁上每多放一個由瀏覽器或外部控制的東西，就多一樁破事情。EVP 這種連傳參數改文字、換語系的機會都不給的原生 UI，在真實專案或公司內部跨部門溝通時，往往會成為最難交代的一塊心病。
前端開發人員負擔劇增，純前端無法獨立運作
原本的前端表單很單純：使用者輸入 Email，前端用一些 Regex 大概驗證格式就好。現在為了支援 EVP，前端突然多出很多工作。
本以為表單上的 Nonce 是要發給 Google 換憑證，其實完全不是。Nonce 是由網站自己的後端伺服器產生，並塞進表單隱藏欄位。
Chrome 向 Google 拿第一層憑證時，基於隱私考量完全不會把 Nonce 與網址交給 Google（Google 不會知道你在哪家網站購物）。拿到 Google 憑證後，Chrome 在本機把你的 Nonce 打包進第二層 Key Binding，最後表單送出時，再整包發回給你自己的後端核對。
這表示每次 render 或使用者輸入信箱時，前端必須發 AJAX 向後端要一組隨機碼。
在上個月(2026/8)的時候才又發布一次更新，Email verification updates, August 2026，本來只能從 autocomplete 觸發，現在手動輸入(打字或複製貼上)也能觸發了。
然後有些前端工程師會想：既然瀏覽器的 Web Crypto API 能驗證 Ed25519 簽章，能不能讓前端 JS 直接向 Google JWKS 抓公鑰自己驗證，省下後端的工？
答案是技術上算得出來，但資安上毫無意義。驗證在前端跑，任何人按 F12 打開 Console 改個變數就繞過了；而且沒有後端產生 Nonce，前端自己生 Nonce 自己驗，完全失去防重放價值。最後資料終究要存進資料庫，後端 API 還是得自己重驗一次。
後端在驗證當下可能就要想辦法紀錄驗證狀態，否否如果第一步驗證了 EVP，40 分鐘後使用者才把整份表單送出，各種跨步驟傳遞狀態的架構負擔，還是落在開發者頭上。
在一些團隊裡，前端跟後端工程師是分開的。現在光是在表單加個 email 驗證功能，就得請後端開一套發 Nonce 的 API、一套接收 SD-JWT 的核驗管線，還要串外部 Google JWKS。然後還要重新驗證本來的驗證通知信流程有沒有被「改壞」? 再結合剛剛提的只能驗帳號控制權，驗不到是不是真的能收信?
從整個協作成本和實用性來說，實在很懷疑到時候正式發布，大家是否會真的導入，還是純粹給一些人拿來炫技用。
「今天試用了新出的某某 AI 模型實作 EVP 驗證，5分鐘就加好了，工程師要失業了」
「之前使用某某平台每年繳好幾萬，連個 EVP 都沒有，現在使用誰誰的系統，直接內建」
維護成本翻倍，還有自動化測試問題
原本以為導入新技術可以簡化 email 驗證，實測後才發現維護成本反而越疊樂高：
前面提過，瀏覽器環境和 email 符合條件的使用者，根本是天選之子，Safari、Firefox、Outlook 信箱都跑不動 EVP。
所以原本的寄驗證信程式碼非但不能刪，反而要同時維護兩大套驗證邏輯。
一般的簡易表單可以跑自動化測試。但 EVP 是由 Chrome 核心發起、會跳出瀏覽器 Native UI 的權限彈窗。還需要真實 Gmail session，才能拿到 Google 簽發的 SD-JWT 憑證。這些條件都無法在 CI 的 Headless 無頭瀏覽器環境中直接模擬。
要嘛手動測試，要嘛用官方提供的 mock issuer/verifier demo 作假測試，不然只能等以後正式推出時，期待官方提供更好的建議流程。
網站後端放第三方域名? 現階段難支援 EVP
現在有些網站架構是網站第一方域名本身沒有後端程式，然後後端可能是用 Auth0、Clerk 這類第三方身份服務商提供的 API 來做各種功能，又或是像 Manus, Supabase 這種一堆後端 API 功能的架構。這些廠商目前都還無法申請 EVP 的 Origin Trial。
EVP 的官方說明 Third-party origin trials 有寫到一段:
Third-party origin trials are not supported for email verification as of August.
目前官方是開放 Gmail 讓大家玩一下，走走流程(Gmail is participating in the origin trial as a provider. You can test the verification flow with any @gmail.com address without additional configuration.)
如果要真的申請 Origin Trial，目前主要只有 First-party origin trial，用網站自己的域名去註冊 trial，然後在自己的頁面用 meta 或 HTTP header 放 Origin-Trial token，功能只在這個 origin 上啟用。
從目前的技術規格發現，第二層 Key Binding JWT 的 aud 欄位，是由 Chrome 核心自動且強制綁定當前視窗的來源網域，那碰到本段開始提的這種架構，根本不能用 EVP 來驗證，要嘛整個 EVP 的規格流程大改一番，要嘛退回它的功能定位: 我只是用來代替 Email 驗證的，不用就拉倒，再乖乖回去寄驗證信嘛！
後續功能正式進入 Chrome stable 後，可能還有很多變動，以後的事誰知道呢。
為了 EVP Token 又要多保管一堆金鑰嗎？不用
一看到 EVP 資料中的「加密」、「數位憑證」、「token」等字眼，心裡立刻警鈴大作：
網站資料庫是不是又要開新欄位，幫每個會員保管公鑰或憑證？
後端伺服器的環境變數裡，是不是又要多存一組對稱加密的 Secret Key 來算雜湊？
答案是：完全不需要！
這也是 EVP 在架構上少數值得稱讚的優點——它是純粹的非對稱公鑰密碼學（PKI），網站後端完全零金鑰管理負擔。
1.不用共享秘密（No Shared Secret）：
後端驗證第一層 EVT 時，是直接連線去向 Google 官方端點抓公開的 JWKS 公鑰；驗證第二層 KB-JWT 時，是拿第一層裡面隨附的臨時公鑰（cnf.jwk）。整個驗簽過程全部使用公開金鑰，後端不需要在 .env 藏任何密鑰，自然也不會有密鑰外洩或 key rotation 的維運負擔。
2.不用替會員保管任何憑證：
使用者的金鑰是瀏覽器臨時隨機產生的，用完即丟。網站資料庫根本不需要為會員儲存任何公鑰、私鑰或憑證紀錄。
3.後端純粹是「無狀態核驗」：
後端只負責把整串 token 拆開、驗算簽名、對照 nonce，確認無誤後就把 Email 認定有效，token 就可以直接扔了。
所以，工程師不用擔心伺服器又要多管一堆密鑰，後端只需要能連上外網去抓 Google 的公開 JWKS 即可。
然後同一組 Email、同一個人、同一台電腦，在不同時間或不同網站送出的 EVP Token 也都是不一樣的，目前是用 email 地址、 iat(簽發秒數時戳)、cnf.jwk(暫時性公鑰)等資料組合算出來的，可以參考token payload的說明。
如果 Token 在同一台電腦上算出來都一樣，各大電商就能私下比對 Token 字串，跨站追蹤使用者的上網痕跡。
這套設計兼顧了隱私與安全：
- Google 不知道你去哪家網站：Google 簽發的第一層 EVT 根本沒寫目標網站網址。
- 電商無法跨站追蹤：不同網站拿到的 Token 與臨時公鑰完全不同，無法關聯。
- 中間人無法攔截盜用：有 Nonce、Audience 與短時效限制，攔截下來也沒辦法拿去其他地方用。
總結
發驗證信本身有很多破事，例如:
- 網站用免費信箱發信或方案額度不夠，瞬間湧入一堆註冊時，整個會員驗證流程就卡住。
- 有些行銷或設計大師可能認爲等待收信、收回信再跳回來，都容易是新客戶註冊卡住或流失的點，最好都不用驗證，使用者填什麼就記錄什麼。
- 如果有人亂填email，寄信失敗率會影響到寄件網域的聲譽，以後容易導致寄信都跑到垃圾郵件匣或被退信。
Email Verification Protocol (EVP) 確實是滿有意思的嘗試，從來沒想到這件事可以拉到瀏覽器底層完成。
現階段的實務結論:
- 完全不能取代傳統寄驗證信：因為支援的瀏覽器有限、其他電子郵件大廠尚未跟進、還要先登入，很多人都用不了。
- 當作加速外掛就好：把它當成漸進式增強（Progressive Enhancement），能用的 user 直接順暢完成操作；拿不到的就乖乖去收驗證碼。
- 準備好雙倍維護成本：享受酷炫的快速驗證，背後得自己各種開發和維護成本。