語法檢查輸入能否被解讀為郵箱地址
BillionVerify 會把本地部分與域名分開、規範化輸入，並拒絕缺少元件、分隔符損壞，或字元出現在地址解析器無法接受位置等結構失敗。這能在任何網路查詢前捕獲常見打字與複製貼上問題。
語法通過並不會詢問收件者的服務商。字串可能符合每一條格式規則，卻指向一個不收信的域名，或一個從未建立的郵箱。請把語法當第一道關卡，絕不要當成最終可投遞結果。
郵箱驗證工具
免費郵箱校驗器：語法與 MX 記錄驗證
檢查地址格式是否正確，以及域名是否已設定收信。此快速校驗器在 SMTP 之前停止，因此不會聲稱郵箱存在。
什麼是郵箱校驗器？
郵箱校驗器回答的問題比驗證器更窄：這個字符串是否是發布郵件伺服器的域名上格式正確的地址？這是格式與 MX——不能證明人或收件箱存在。
搜索者使用 “email validator” 和 “validate email” 時，想要快速、免費的初篩。BillionVerify 保持本頁誠實：不做虛假可達性聲明，無 SMTP 握手，對合法使用提供不限次的淺層檢查。
當退信風險重要時，請轉到郵箱檢查器或郵箱驗證器。這些工具在相同格式基礎之上增加郵箱探測與風險標記。
郵箱校驗器如何工作
僅兩層。刻意不做 SMTP。
1. 解析與規範化
按實用格式規則檢查本地部分與域名形態。拼寫錯誤在毫秒內失敗。
2. 解析 MX 記錄
檢查是否發布郵件交換記錄。若未找到，此淺層校驗器會回報無 MX，並在任何郵箱測試前停止。
3. 在郵箱之前停止
我們不開啟 SMTP 會話。Catch-all 域名仍可通過本校驗器。
4. 引導您做完整證明
若需要可達性，郵箱驗證器與郵箱檢查器在同一產品棧上運行 SMTP。
何時使用郵箱校驗器
速度比郵箱證明更重要時，使用淺層校驗。
捕獲明顯拼寫錯誤
表單字段與手動輸入會產生格式錯誤。在任何更深檢查前先修復。
確認域名可收信
已發布的 MX 路由可通過正常 DNS 關卡；無已發布 MX 會停止此次淺層檢查，並在不消耗 SMTP 配額的情況下給出原因。
完整驗證前的預篩
對大列表做批量 SMTP 任務前的廉價第一過濾層。
不能僅靠它做發送決策
不要把格式+MX 正常當作可安全冷郵件。發送決策請用 SMTP 工具。
郵箱校驗器 vs 其他郵箱驗證工具
這些是交互式郵箱驗證工具——不是批量任務、不是 API、也不是免費工具（DNS / SPF / DKIM）。
本頁只返回格式與 MX。其他工具增加 SMTP，或專攻某一風險標記。
| 工具 | 功能說明 | 適用時機 |
|---|---|---|
| 電子郵件驗證器 | 完整 SMTP 郵箱檢查加上全部風險標記 | 當送達率與發送安全重要時 |
| 郵箱檢查器 | 單個地址的完整 SMTP + 全部風險標記 | 需要一處查看完整多層結果時 |
| 免費郵箱檢查器 | 檢測免費個人郵箱服務商（Gmail、Yahoo 等） | 線索質量與 B2B 域名評分——不是“免費額度”驗證 |
| 郵箱校驗器 | 僅語法 + MX——無 SMTP | 快速格式與域名初篩 |
| 一次性郵箱檢測 | 標記臨時 / 一次性域名 | 註冊與線索捕獲 |
| 退信郵箱檢查器 | 聚焦退信與不可達風險 | 控制退信率的列表衛生 |
| Catch-All 驗證器 | 檢測 Catch-all 域名 | 當 SMTP 接受結果不可靠時 |
| 角色帳戶檢測 | 發現通用角色地址 | B2B 外呼質量 |
| 郵箱列表清洗 | 一次驗證多個地址（粘貼或 CSV） | 單次檢查不夠、需要清洗整份列表時 |
| 反向電子郵件查找 | 依郵箱地址找出公開歸屬線索與公司上下文 | 線索調研與未知寄件者審核 |
| 電話號碼驗證器 | 驗證電話格式、國家、類型和 E.164 輸出 | 外聯前清理 CRM 電話 |
如何閱讀校驗結果
「格式與 MX 正常」表示地址格式正確，且域名已發布 MX 路由。這不表示郵箱存在。語法無效會立即停止；無已發布 MX 會停止此次淺層檢查，但依賴隱式 MX 的異常域名，最終拒絕前需先複核。
本頁按設計不提供一次性、Catch-all 或退信讀數。這些需要完整驗證或專項工具。
兩層校驗
語法與 MX 校驗能確立什麼
校驗器刻意在兩層成本低廉的檢查後停止。這讓它適合表單與初篩，同時把結論範圍收得比完整郵箱驗證更窄。
MX 檢查域名是否發布郵件路由
域名系統讓域名發布郵件交換記錄，把寄件者導向接收伺服器。語法通過後，BillionVerify 會解析該路由上下文。可用路由表示域名已設定參與郵件投遞。
MX 證據適用於域名，而不是精確的本地部分。同一條郵件路由可以服務在職員工、已退役別名、未指派名稱、群組收件箱與 Catch-All 行為。這就是結果寫「格式與 MX 正常」，而不是「郵箱已驗證」的原因。
Null MX 與缺失 MX 需要符合標準的處理
域名可以發布 Null MX 記錄，明確聲明不接受郵件。IETF 的RFC 7505 Null MX定義了這個訊號，讓寄件者不必浪費時間嘗試投遞到已選擇退出郵件的域名。
缺少明確 MX 記錄在每個技術脈絡中並不完全相同，因為 SMTP 歷史上會透過域名的位址記錄定義回退行為。此淺層頁面不執行該隱式 MX 回退，並對兩種情況都回報無已發布 MX，因此異常域名在最終拒絕前需要複核。
在 SMTP 之前停止，是產品定義的一部分
本頁不會開啟收件者會話、測試郵箱指令，或從服務商行為推斷接受情況。不會發送任何郵件。有限範圍讓校驗器適合快速初篩，並把完整 SMTP 配額留給需要郵箱證據的檢查。
當精確郵箱很重要時，請繼續使用郵箱驗證器。它沿用相同的語法與路由基礎，再加入收件者層級 SMTP 與風險訊號。
校驗結果
在實際測到的層級解讀結果
淺層結果有用，前提是標籤保持精確。多數錯誤發生在把格式或域名證據改名成郵箱證據時。
格式與 MX 正常表示可以進入更深驗證
此結果表示地址結構可用，且域名在校驗器規則下暴露了收信基礎設施。這是正面初篩，不是把郵箱稱為可投遞的許可。
可用它暫時接受表單輸入、繼續增強流水線，或在完整任務前減少明顯不可能的列。硬退信有營運成本的發送，請先加上 SMTP。
語法無效表示修復來源值
解析器無法把輸入解讀為可用地址。常見原因包括缺少 @、域名不完整、空白被複製進值的中間，以及標點錯誤。
向使用者顯示原始欄位並讓他們自行修正。不要自動捏造缺少的字元或替換域名，因為語法上「修好」的猜測可能屬於另一個人。
無郵件路由表示域名尚未準備好正常投遞
當域名在校驗規則下沒有可用路由時，繼續做郵箱驗證也救不了目前這個地址。它可能拼錯、過期、停放，或被刻意設定為不接受郵件。
請回傳原因，而不是籠統的無效標籤。域名層失敗對資料修復有行動價值，也不同於在其他方面正常運作的公司域名上發生的收件者拒絕。
通過校驗仍留下若干未回答的問題
郵箱可能未指派、已停用、已滿、受服務商原則保護，或藏在 Catch-All 行為後面。地址也可能是一次性、角色型，或與您記錄中的人無關。
這些不是校驗器缺陷，而是語法與 DNS 之外的問題。需要完整單地址面板時，請使用郵箱檢查器。
快速初篩
把郵箱校驗放在資料流水線的起點
校驗器在早期移除不可能輸入時，能節省時間與網路工作；後續階段仍負責郵箱與受眾決策。
- 1
在使用者還能修正時校驗結構
在表單輸入時或提交後立即執行語法校驗。欄位旁的清楚訊息，比使用者離開頁面後才發現畸形地址更有用。
避免在對方還在打字時過度即時阻擋。在穩定的互動點校驗，並保留已輸入的值，讓使用者——而不是自動更正規則——選擇修正。
當表單對業務關鍵時，在一般分析中記錄原因類別，而不是完整地址。產品團隊需要知道失敗來自語法還是 DNS，而不要把校驗事件流變成第二個聯絡資料庫。
- 2
在昂貴的增強或 SMTP 之前解析域名就緒情況
無已發布 MX 的結果會在郵箱探測或聯絡人增強之前停止這條淺層流水線。早期 DNS 篩選減少不必要的下游工作；依賴隱式 MX 的異常域名應分流到複核，而不是被默默當成普通硬失敗。
重試行為要合理，因為 DNS 可能暫時失敗。區分已確認的不收信狀態與未能完成的查詢，不要把短暫的基礎設施故障變成永久刪除客戶資料。
- 3
只升級需要發送決策的記錄
若工作流只需要乾淨格式與可收信域名，到此為止。若將發送入職、銷售、密碼、帳單或活動郵件，請在接近發送事件時繼續做完整 SMTP 驗證。
這種分層做法讓快速檢查保持快速，同時不降低可投遞性標準。結果名稱應隨資料一起走，讓下游系統知道收到的是已校驗還是已完整驗證的證據。
有用的欄位模型會分別儲存語法狀態、已發布 MX 狀態、校驗深度與檢查時間。這可避免後續匯出把格式與 MX 成功壓成誤導性的「已驗證」布林值。
- 4
每一列都需要完整決策時，使用批量清洗
大型檔案需要一致的去重、狀態處理、重試邏輯與匯出。淺層校驗器可以初篩資料集，但無法告訴活動操作者哪些精確收件者接受了 SMTP 探測。
活動規模驗證請使用郵箱列表清洗，並把語法、路由、SMTP 與風險原因保留為分開的輸出欄位。
誠實的界線
校驗不是驗證、身份或送達率測試
省略所測層級時，「有效」一詞容易誤導。BillionVerify 為各層命名，讓使用者能選擇正確的下一步。
沒有 SMTP，就不能聲稱郵箱存在
校驗器從不向接收系統詢問目標本地部分。因此即使 company.com 接受郵件，也無法確定 jane@company.com 是否已指派。
僅憑語法與 MX 就聲稱可投遞，是誇大證據。BillionVerify 把郵箱層級用語留給完整 SMTP 工作流。
Catch-All 域名可以通過每一個淺層
Catch-All 域名具備有效郵件基礎設施，並可能接受任意本地部分。地址可以看起來完美、域名可以路由郵件，而具名的人層級郵箱仍未確認。
使用Catch-All 驗證器理解該域名行為，並把 Catch-All 聯絡人留在複核區段，而不是稱之為已個別驗證。
這對生成式 B2B 模式最重要。在公司域名上猜測 firstname.lastname，可以對每個員工姓名通過語法與 MX，而 Catch-All 行為讓這些淺層檢查無法確認任何一個猜出的收件者。
域名就緒不能識別地址擁有者
DNS 記錄對 CRM 列上的人什麼也沒說。域名可能正確路由郵件，而掛在地址上的姓名、雇主、職稱或同意是錯的。
身份與許可需要第一方或授權證據。校驗防止技術輸入錯誤；它不會把第三方聯絡資料變成已驗證身份。
把身份信心與技術校驗分開存放。銷售團隊就能複核增強來源，同時不丟失「地址結構與已發布郵件路由已通過自身檢查」這個事實。這種分離也讓後續資料品質稽核更容易解釋。
收件者校驗不測試您的寄件設定
有效的目的地仍可能把訊息收到垃圾郵件，當寄件者聲譽差、缺少驗證、內容有風險，或活動行為不健康時。這些條件在寄件端。
寄件域名就緒請使用郵箱送達率測試。在同一發送工作流中，把收件者校驗與寄件者送達率當成分開的控制項。
協議參考
標準解釋了淺層校驗為何停在這裡
地址文法、DNS 郵件路由與 SMTP 收件者回覆，是網際網路郵件的不同部分。產品邊界跟隨該架構。
RFC 5322 描述訊息與地址結構
IETF 的RFC 5322 Internet Message Format定義用來表示郵箱地址與訊息的語法。它是判斷字串能否被解析為地址的基礎。
該文件不提供能證明郵箱存在的網路查詢。BillionVerify 在校驗結果中保持這個區分可見。
RFC 5321 描述郵件路由與 SMTP 回覆
IETF 的RFC 5321 Simple Mail Transfer Protocol定義郵件交換行為，包括收件者指令以及暫時與永久回應類別。那些收件者回覆屬於完整驗證，不屬於本頁。
校驗器使用確立域名就緒所需的路由層，並在收件者互動前停止。這讓結果快速、可解釋，且範圍正確。
下一個工具取決於下一個問題
常見問題
1. 郵箱校驗器檢查什麼？
本郵箱校驗器只檢查兩層：（1）地址格式是否正確（語法/結構），（2）域名是否發布 MX 記錄以便收信。它不會與郵箱開啟 SMTP 會話，也無法證明特定人或收件箱存在。這種誠實是刻意的——格式與 MX 是廉價初篩，不是完整郵箱驗證。
2. 郵箱校驗器使用 SMTP 嗎？
否。SMTP 郵箱驗證在郵箱檢查器、列表清洗與已登入產品流程中提供。校驗器停在語法與 MX，從而保持快速且基本不限次（僅防濫用的軟性限制）。需要退信風險與可達性時，請打開郵箱檢查器獲取完整 SMTP 結果。
3. 何時應使用郵箱校驗器而不是郵箱檢查器？
只需快速格式與域名初篩時使用郵箱校驗器——捕獲拼寫錯誤、拒絕無 MX 的域名，或在更重任務前預過濾。錯誤地址會帶來退信、ESP 處罰或浪費 SDR 時間時，使用郵箱檢查器。許多團隊在表單入口做校驗器式檢查，在活動或 CRM 導入前做完整 SMTP 郵箱檢查。
4. 郵箱校驗器免費嗎？
是的。淺層校驗（語法 + MX）免費，且不受郵箱檢查器 20 次完整 SMTP 配額限制。僅在防止自動化濫用時可能有軟性速率限制。批量 CSV 清洗與 API 用量請註冊帳戶。
5. 郵箱校驗器 vs 郵箱檢查器——該選哪個？
需要不限次的淺層檢查時選郵箱校驗器：“這看起來像能收信域名上的郵箱嗎？”需要多層驗證時選郵箱檢查器：SMTP 可達性加上一次性、Catch-all 與角色標記。它們回答不同問題；把校驗器結果當成完整驗證，是常見的可達性錯誤。
6. Catch-all 域名能通過郵箱校驗器嗎？
會。Catch-all 域名通常發布有效 MX，因此即使特定本地部分不是真實個人，語法 + MX 也可能看起來正常。只有完整驗證工具（郵箱檢查器 / Catch-All 驗證器）才能暴露 Catch-all 不確定性。若通過猜測 names@company.com 做線索增強，請勿僅依賴校驗器。
郵箱校驗
需要完整 SMTP 可達性？
運行郵箱檢查器獲取郵箱級證明與風險標記，或註冊以使用批量清洗與 API。
24 小時 20 次免費 SMTP 檢查 · 淺層檢查無需註冊 · 數秒出結果
99.9%
準確率
Real-time
API 速度
$0.00014
每封郵件
600/mo
永久免費