Catch-all 不等於有效。
當網域被設定為 catch-all 時，它接受所有入站訊息，不論特定信箱是否存在。驗證工具無法越過網域層面的接受，去確認 john.smith@company.com 是否真的屬於某人。網域接受了，但信箱可能不存在。
這就是將 catch-all 結果視同已確認有效地址的核心問題。你的訊息被接受了，但這不意味著它被投遞給了真實的人。在許多情況下，網域採用 catch-all 配置正是因為它無法維護自身信箱的準確清單，寄到不存在地址的訊息會被靜默丟棄。
相反的錯誤是將每個 catch-all 結果視為垃圾並全部移除。這樣會丟棄一個有意義的細分群組。許多 catch-all 網域確實包含真實的、可投遞的地址。正確的方法既不是盲目接受所有 catch-all 記錄，也不是全部丟棄，而是將它們分離到一個有自己的量和風險規則的受控細分群組中。
冷郵件驗證框架
本頁面介紹單一發件工具或工作流程。完整框架說明從名單來源到驗證、分組，再匯入發件工具的完整路徑。
Catch-all 驗證能告訴你什麼，不能告訴你什麼。
| 訊號 | 含義 | 無法告知 |
|---|---|---|
| 確認為 catch-all | 網域接受所有郵件 | 具體信箱是否存在 |
| 無 MX 失敗 | 網域有正常的郵件基礎設施 | 收件人地址是否對應真實的人 |
| 無硬拒絕 | 伺服器未拒絕連接 | 訊息是否被投遞或靜默丟棄 |
| 無一次性標記 | 網域不是已知的臨時郵件服務 | 信箱是否被監控或活躍 |
Catch-all 結果佔據有效和無效之間的風險帶。它們不等同於已確認有效，也不等同於已確認無效。它們需要獨立的路由決策，而非二元的保留或移除判斷。
三種常見的 catch-all 錯誤。
大多數團隊在驗證輸出中遇到 catch-all 結果時，會落入以下三種模式之一：
將 catch-all 視為有效。 團隊將所有 catch-all 記錄與已確認有效地址一起匯入主要活動。當這些記錄產生退信或低互動時，團隊責怪寄件人或文案，而非匯入時做出的名單品質決策。
將 catch-all 視為無效。 團隊在匯入前丟棄所有 catch-all 記錄。在某些行業（醫療、金融、中型 B2B 公司），catch-all 配置很常見，被丟棄的記錄可能代表真實的聯絡人。團隊在沒有政策依據的情況下失去了可觸達的潛客。
完全忽略 catch-all。 團隊根本不按 catch-all 狀態過濾。Catch-all 記錄在未宣告的情況下與已確認有效地址混入主要活動。退信模式變得更難診斷，因為名單從一開始就不乾淨。
標準的 catch-all 工作流程。
基於政策的方法在任何記錄進入寄件人之前，將 catch-all 分離到自己的細分群組。該細分群組有不同的規則：較低的量、更密切的監控，以及關於它是否屬於當前活動或等待佇列的明確決策。
透過 BillionVerify 執行名單
→ 有效記錄 → 主要活動細分群組
→ 無效、高風險、一次性 → 抑制名單
→ Catch-all 記錄 → 獨立細分群組
→ 套用量上限（低於主要活動）
→ 密切監控回覆率和退信訊號
→ 不與已確認有效記錄混合
→ 第一次發送結果後重新評估
→ 基於角色 → 獨立訊息軌道
→ 未知 → 審查佇列
Catch-all 細分群組不是棄置堆，而是受監控的細分群組。部分 catch-all 記錄會產生回覆，其他的會退信或沒有互動。向 catch-all 細分群組的第一次小量發送，能提供關於該網域實際行為的真實訊號，這是僅憑驗證無法獲得的資訊。
匯入前路由每個結果。
| BillionVerify 結果 | 匯入前行動 |
|---|---|
| 有效 | 匯入主要活動名單 |
| 無效 | 不匯入 — 加入抑制文件 |
| Catch-all | 獨立細分群組，降低量，不與有效記錄混合 |
| 基於角色 | 獨立活動，共用收件箱訊息 |
| 未知 | 人工審查 — 排除主要活動 |
| 高風險或一次性 | 不匯入 |
其他套用類似決策的工作流程。
預熱前先驗證郵件
了解為什麼名單驗證必須在預熱之前進行，而不是之後。
匯入前名單清洗
在任何名單進入發件工具或 CRM 之前，套用統一的清洗規則。
冷郵件退信率控制
在名單層面控制退信率，在發件工具介入之前。
預熱 vs 郵件驗證
了解預熱解決哪類問題，驗證解決哪類問題。
內建驗證 vs 第三方驗證
比較發件工具原生驗證與專用發送前品質門控的差異。
Folderly + BillionVerify 工作流程
在 Folderly 送達率優化前驗證名單，乾淨的資料讓預熱更有效。
Mailforge + BillionVerify 工作流程
在 Mailforge 基礎設施執行活動前，新增發送前的驗證步驟。
Catch-all 政策常見問題。
我應該向 catch-all 地址發送嗎？
應該，但要降低量並獨立追蹤。在大多數 B2B 外展情境中，丟棄所有 catch-all 記錄過於保守。正確的方法是分離它們，謹慎發送，並用第一次發送結果來決定是繼續還是抑制該網域。
Catch-all 細分群組的量應該低多少？
起點是將第一次發送的 catch-all 細分群組量上限設為主要活動量的三分之一左右。如果回覆率與主要細分群組相當，且退信訊號極少，你可以在後續發送中提高量。如果出現退信，抑制那些特定記錄並重新評估剩餘網域。
我可以將 catch-all 地址與已確認有效記錄在同一活動中混合嗎？
不行。在同一活動中混合 catch-all 和有效記錄，使績效診斷更加困難。如果活動表現不佳或產生意外退信，你無法區分名單品質問題、文案問題、鎖定問題還是寄件人問題。獨立細分群組能給你清晰的資料以採取行動。
如果我的名單大部分都是 catch-all 怎麼辦？
這在某些中型公司將 catch-all 作為預設郵件伺服器設定的行業中很常見。如果你的名單主要是 catch-all，將該細分群組作為主要工作名單，並在擴大規模前透過小批次發送驗證各網域的行為。使用早期發送的回覆和退信結果，逐步建立網域層級的抑制和包含名單。
Catch-all 狀態會隨時間改變嗎？
會。六個月前是 catch-all 的網域可能已更改其配置。重新驗證任何閒置超過 60 至 90 天的名單。Catch-all 行為是伺服器端配置，可以在不通知寄件人的情況下啟用或停用。