冷郵件的 Catch-All 政策

Catch-all 不等於有效。

當網域被設定為 catch-all 時，它接受所有入站訊息，不論特定信箱是否存在。驗證工具無法越過網域層面的接受，去確認 john.smith@company.com 是否真的屬於某人。網域接受了，但信箱可能不存在。

這就是將 catch-all 結果視同已確認有效地址的核心問題。你的訊息被接受了，但這不意味著它被投遞給了真實的人。在許多情況下，網域採用 catch-all 配置正是因為它無法維護自身信箱的準確清單，寄到不存在地址的訊息會被靜默丟棄。

相反的錯誤是將每個 catch-all 結果視為垃圾並全部移除。這樣會丟棄一個有意義的細分群組。許多 catch-all 網域確實包含真實的、可投遞的地址。正確的方法既不是盲目接受所有 catch-all 記錄，也不是全部丟棄，而是將它們分離到一個有自己的量和風險規則的受控細分群組中。

Catch-all 驗證能告訴你什麼，不能告訴你什麼。

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 分離到自己的細分群組。該細分群組有不同的規則：較低的量、更密切的監控，以及關於它是否屬於當前活動或等待佇列的明確決策。

Catch-all 細分群組不是棄置堆，而是受監控的細分群組。部分 catch-all 記錄會產生回覆，其他的會退信或沒有互動。向 catch-all 細分群組的第一次小量發送，能提供關於該網域實際行為的真實訊號，這是僅憑驗證無法獲得的資訊。

匯入前路由每個結果。

其他套用類似決策的工作流程。

Catch-all 政策常見問題。

我應該向 catch-all 地址發送嗎？

應該，但要降低量並獨立追蹤。在大多數 B2B 外展情境中，丟棄所有 catch-all 記錄過於保守。正確的方法是分離它們，謹慎發送，並用第一次發送結果來決定是繼續還是抑制該網域。

Catch-all 細分群組的量應該低多少？

起點是將第一次發送的 catch-all 細分群組量上限設為主要活動量的三分之一左右。如果回覆率與主要細分群組相當，且退信訊號極少，你可以在後續發送中提高量。如果出現退信，抑制那些特定記錄並重新評估剩餘網域。

我可以將 catch-all 地址與已確認有效記錄在同一活動中混合嗎？

不行。在同一活動中混合 catch-all 和有效記錄，使績效診斷更加困難。如果活動表現不佳或產生意外退信，你無法區分名單品質問題、文案問題、鎖定問題還是寄件人問題。獨立細分群組能給你清晰的資料以採取行動。