先檢查目標地址
BillionVerify 會校驗地址、解析已發布的接收路由，並在 SMTP 對話中評估目標收件人。永久拒絕是有用的否定證據。接受表示伺服器當時願意接收該收件人命令。
若要在一個結果中看到完整的語法、MX、SMTP、一次性、角色和 Catch-All 欄位，請使用 郵箱檢查器。本頁聚焦當域名有寬泛收件人策略時，接受意味著什麼。
郵箱驗證工具
Catch-All 驗證器：檢測 Catch-All 郵箱域名
該域名是否接受每個本地部分？檢測 Catch-all 行為，避免把猜測地址當作已驗證個人。
什麼是 Catch-all 驗證器？
Catch-all 驗證器檢測接受任意本地部分郵件的域名——即使地址不屬於真實個人。
在 Catch-all 域名上，SMTP“已接受”是弱證據。您需要聚焦的 Catch-all 讀數，避免銷售與增強工作流把每個猜測當作已驗證員工收件箱。
我們仍會探測郵件路徑；界面只強調是否存在 Catch-all 行為及如何解讀。
Catch-all 驗證器如何工作
衡量全域名接受，而不把它變成個人級證明。
1. 校驗地址
在任何網路工作前拒絕空或畸形輸入。
2. 解析接收路由
在測試域名如何處理收件人前，先定位已發布的郵件交換器。
3. 比較收件人行為
評估接受看起來是針對目標，還是與更廣的域名策略一致。
4. 僅展示 Catch-all 讀數
界面突出本頁維度及其白話含義——而非完整多標記面板。
何時需要 Catch-all 驗證器
當一個決策比完整報告更重要時，使用專項工具。
解釋已接受但不確定的結果
向營運說明：Catch-All 域名上的 SMTP 接受，弱於綁定到某一個精確收件人的接受。
複核富化或猜出來的聯絡人
當域名廣泛接受郵件時，猜出來的 firstname.lastname 地址需要更強的支持證據。
按置信度分段
把第一方 Catch-All 地址與產生的聯絡人分開路由，而不是刪除每一條結果。
重新整理過期結果
重要活動前複核較舊的分類，因為郵件服務商遷移可能改變域名行為。
Catch-All 驗證器 vs 其他郵箱驗證工具
這些是交互式郵箱驗證工具——不是批量任務、不是 API、也不是免費工具（DNS / SPF / DKIM）。
本頁隔離 Catch-all 決策。其他工具要麼展示完整多層結果，要麼聚焦不同專項標記。
| 工具 | 功能說明 | 適用時機 |
|---|---|---|
| 電子郵件驗證器 | 完整 SMTP 郵箱檢查加上全部風險標記 | 當送達率與發送安全重要時 |
| 郵箱檢查器 | 單個地址的完整 SMTP + 全部風險標記 | 需要一處查看完整多層結果時 |
| 免費郵箱檢查器 | 檢測免費個人郵箱服務商（Gmail、Yahoo 等） | 線索質量與 B2B 域名評分——不是“免費額度”驗證 |
| 郵箱校驗器 | 僅語法 + MX——無 SMTP | 快速格式與域名初篩 |
| 一次性郵箱檢測 | 標記臨時 / 一次性域名 | 註冊與線索捕獲 |
| 退信郵箱檢查器 | 聚焦退信與不可達風險 | 控制退信率的列表衛生 |
| Catch-All 驗證器 | 檢測 Catch-all 域名 | 當 SMTP 接受結果不可靠時 |
| 角色帳戶檢測 | 發現通用角色地址 | B2B 外呼質量 |
| 郵箱列表清洗 | 一次驗證多個地址（粘貼或 CSV） | 單次檢查不夠、需要清洗整份列表時 |
| 反向電子郵件查找 | 依郵箱地址找出公開歸屬線索與公司上下文 | 線索調研與未知寄件者審核 |
| 電話號碼驗證器 | 驗證電話格式、國家、類型和 E.164 輸出 | 外聯前清理 CRM 電話 |
如何閱讀 Catch-all 驗證器結果
Catch-All 表示該域名看起來願意廣泛接受郵件。目標地址可能收信，但 SMTP 接受無法證明具名的人或精確郵箱存在。
非 Catch-All 表示當前證據未顯示全域名接受；這不是對未來伺服器策略的永久承諾。未知仍無法定論，在決策重要時應重試。
域名行為
Catch-All 檢測如何改變 SMTP 結果
關鍵區別在於：關於郵件域名的證據，與關於某一個精確收件人的證據。
廣泛接受會削弱個人級確定性
Catch-All 配置可以為從未開通的本地部分接受郵件。伺服器可能把它們路由到共享收件箱、稍後處理，或靜默丟棄。這讓被接受的 RCPT 回應對 firstname.lastname@company.com 這類猜出來的地址證據更弱。
SMTP 協定載於 RFC 5321，描述收件人接受，但不會把該回覆變成人類身分或專用收件箱的證明。
Catch-All 作為獨立訊號保留
域名可以是 Catch-All，同時目標收件人被接受；角色或一次性標誌也可以與任一結果共存。BillionVerify 把這些事實分開，因此界面不會用單一營銷標籤替換送達能力證據。
需要實際發送決策時使用 郵箱驗證器。當關鍵問題是全域名行為是否讓該決策更不確定時，使用本頁。
決策指南
對 Catch-All、非 Catch-All 和未知分別解讀
每種結果對應不同的置信度，以及不同的後續動作。
檢測到 Catch-All
把地址視為不確定，尤其當它是從姓名格式產生、而不是收件人自己提供時。域名看起來廣泛接受，因此接受無法區分真實員工收件箱和編造的本地部分。
在大規模外聯前，優先使用與該人綁定的額外來源、近期互動或第一方表單提交。Catch-All 並不自動無效，但不應被提升為已驗證個人狀態。
未檢測到 Catch-All
當前探測未顯示廣泛的收件人接受。因此成功的目標回應對所提交郵箱更具體，但它仍是時點網路證據，而不是身分證明。
繼續套用 角色帳戶檢測 和一次性檢查。非 Catch-All 的 sales@ 地址仍可能是共享團隊郵箱，看起來像個人的本地部分也可能已經過時。
Catch-All 無法定論
有些伺服器會延遲、限流、誘捕或隱藏收件人策略。逾時或臨時 SMTP 回覆無法安全確立 Catch-All 或非 Catch-All 行為。保留未知，而不是選擇更方便的標籤。
稍後重試有價值的聯絡人，並用 退信郵箱檢查器 理解底層郵箱結果是臨時的還是永久否定。
營運政策
處理 Catch-All 聯絡人，而不丟掉每一條線索
分層工作流在保護發件人信譽的同時，保留有更強支持證據的地址。
- 1
記錄地址如何獲得
用戶在您自己表單裡輸入的 Catch-All 地址，比從姓名和域名產生的地址有更強支持證據。把來源出處與驗證結果放在一起，這樣兩列就不會得到相同的風險分。
驗證器事後無法恢復該出處。請把它作為 CRM 匯入和富化工作流中的一等欄位。
- 2
發送前按置信度分段
把正常、非 Catch-All 且被接受的地址走標準路徑。把有第一方證據的 Catch-All 地址放入謹慎分段，並抑制或人工複核沒有佐證、猜出來的 Catch-All 聯絡人。
對大檔案，郵箱列表清洗 會保留類別計數，讓團隊單獨路由 Catch-All 列，而不是把整份名單壓成有效和無效。
- 3
靠近活動日期時複核
公司遷移服務商或管理員調整收件人處理時，域名策略會變化。重要活動前重新驗證較舊的 Catch-All 紀錄，尤其當原始結果來自富化而不是直接互動時。
自動化系統可以呼叫 郵箱驗證 API，並把 Catch-All 標誌與總體狀態和 SMTP 原因分開儲存。
應避免的聲稱
Catch-All 檢測不是郵箱或身分證明
這個訊號之所以有價值，正因為它暴露不確定性，而不是把它藏起來。
被接受不表示猜到的那個人存在
Catch-All 伺服器可能接受任何看起來合理的本地部分。它不能確認員工姓名、職位、所有權，或郵件是否到達有人監控的收件箱。不要把 SMTP 接受當作富化找到了正確人選的證據。
Catch-All 並不總意味著無法送達
有些組織會有意把未知收件人路由到有人監控的郵箱。另一些先接受，再稍後拒絕或丟棄。域名行為提高不確定性；它不提供通用的退信預測。
把精確的 SMTP 結果和 Catch-All 訊號放在一起，下游用戶才能同時看到這兩個事實。
結果不能替代同意和抑制控制
技術上的接受並不授權外聯。無論域名是否 Catch-All，驗證之後仍要套用聯絡偏好、退訂、同意紀錄和貴團隊自己的發送政策。
解釋證據
保留協定結果及其不確定性
可稽核的 Catch-All 處理依賴的不只是一個是／否徽章。
正確使用 RFC 5321 回應類別
SMTP 區分臨時 4xx 回覆和永久 5xx 回覆。Catch-All 測試中的臨時回應應進入無法定論狀態，而不是永久無效桶。定義記錄在 RFC 5321。
把目標狀態和 Catch-All 狀態分開儲存
分開的欄位防止寬泛的域名策略覆蓋所請求收件人身上發生的事。它們也讓分析師比較直接表單提交、富化聯絡人和產生地址格式的結果。
保留時間戳，因為域名策略會變
Catch-All 結果是某一時刻的觀察。儲存它被測量的時間，並在過期分類會實質影響活動或產品決策時複核。
常見問題
1. 什麼是 Catch-all 郵箱域名？
Catch-all（接受全部）域名配置為接受該域名下任意本地部分的郵件——即使地址不屬於真實個人。SMTP 常返回“已接受”，看起來可投遞，但無法證明郵箱是真實員工收件箱。Catch-all 在小企業域名以及部分 Microsoft 365 / Google Workspace 配置中常見。
2. 為何 Catch-all 會破壞郵箱驗證？
多數 SMTP 驗證器根據伺服器是否對該地址接受 RCPT TO 推斷存在性。在 Catch-all 上，接受是弱證據。猜測 first.last@company.com 的銷售增強工具可能把虛構地址標為有效。Catch-all 驗證器暴露該不確定性，避免把每個被接受的猜測當作已驗證聯繫人。
3. 外呼中應如何對待 Catch-all 結果？
將 Catch-all 視為不確定可達性：策略允許時可用於低風險事務郵件；對冷序列與激進增強則有風險。優先二次確認（LinkedIn、表單填寫、已知模式）或抑制虛構本地部分。將 Catch-all 檢測與角色檢測、免費郵箱檢查結合，以提升 B2B 列表質量。
4. Catch-All 驗證器 vs 郵箱檢查器——有何區別？
郵箱檢查器展示完整多層結果，其中 Catch-all 是眾多標記之一。Catch-All 驗證器是專項工具：頁面標題、SEO 與結果面板聚焦 Catch-all 解讀。用於劇本與培訓時選專項頁；需要一次查看所有訊號時用郵箱檢查器。
5. Catch-all 驗證器免費嗎？
交互式檢查與其他完整工具共享公平使用的免費完整驗證配額：每個 IP 每滾動 24 小時 20 次。確認本頁行為後，可用郵箱列表清洗或 API 做大規模 CSV 檢測。
6. 你們會儲存我測試的郵箱嗎？
公開檢查會返回結果並執行防濫用限制。我們不會用您粘貼到此工具的地址構建營銷列表。
Catch-All 驗證器
從單次檢查擴展規模
登入後可使用批量列表清洗、更高用量與 API，驗證引擎相同。
24 小時 20 次免費 SMTP 檢查 · 免費層無需信用卡 · 與批量及 API 同一引擎
99.9%
準確率
Real-time
API 速度
$0.00014
每封郵件
100/day
永久免費