Mailforge 配置基礎設施，不審核聯絡人名單。
Mailforge 管理發送層：配置網域和信箱、處理暖機、跨活動輪換發送身份。它建立和維護冷郵件活動所需的基礎設施。
Mailforge 不做的是檢查你的活動將要鎖定的電子郵件地址是否真實存在或應該被聯絡。那個決策發生在名單層面，在任何記錄進入 Mailforge 管理的發送基礎設施之前。
這是同一冷郵件工作流程中兩項截然不同的責任。Mailforge 擁有發送層，BillionVerify 擁有名單層。兩者互不替代，兩者都是冷郵件基礎設施投資能產生一致、可預測的活動結果所必需的。
冷郵件驗證框架
本頁面介紹單一發件工具或工作流程。完整框架說明從名單來源到驗證、分組，再匯入發件工具的完整路徑。
Mailforge 管理什麼，以及它不管理什麼。
| Mailforge 處理 | Mailforge 不處理 |
|---|---|
| 為冷郵件配置網域和信箱 | 檢查個別電子郵件地址是否可投遞 |
| 為新發送基礎設施提供暖機序列 | 從聯絡人名單中移除無效、catch-all 或基於角色的記錄 |
| 跨多個網域和信箱輪換發送 | 在記錄進入發送系統前依風險分類聯絡記錄 |
| 收件箱投放基礎設施管理 | 為退信或取消訂閱的聯絡人維護抑制文件 |
| 技術發送設置和 DNS 配置 | 匯入前的名單資格審查決策 |
Mailforge 是基礎設施工具。它提供的價值（健康的發送網域、已暖機的信箱、保護個別收件箱健康的輪換）取決於那些網域和信箱用來觸達的聯絡資料品質。
低品質的名單不會停留在名單層面。它流向 Mailforge 建立的基礎設施下游。來自無效地址的退信訊號，降低了暖機努力建立的網域聲譽。來自基於角色收件箱的投訴，削弱了輪換中信箱的發送健康。
為什麼沒有名單品質的基礎設施投資是被浪費的。
透過 Mailforge 建立冷郵件基礎設施需要時間和持續的管理。網域暖機通常需要 4 到 8 週，網域才能準備好進行全量活動。跨多個信箱設置輪換、配置 DNS 記錄和建立乾淨的發送模式，代表著真正的營運投資。
當進入基礎設施的聯絡人名單沒有經過審核時，這種投資就被削弱了。3,000 個聯絡人名單中幾百個無效記錄，就能產生足以損害新暖機網域的硬退信。花了六週暖機的網域，如果名單品質從未得到解決，可能在單個活動中看到收件箱投放率下降。
基礎設施是穩健的，名單才是變量。驗證在名單到達基礎設施之前解決那個變量。
組合工作流程：先驗證，再透過 Mailforge 發送。
從資料庫、CRM 或豐富化工具取得名單
→ 在任何匯入前透過 BillionVerify 執行
→ 移除無效、高風險和一次性記錄
→ 將 catch-all 分類到低量發送軌道
→ 將基於角色的記錄移到獨立的訊息軌道
→ 將未知記錄保留待人工審查
→ 只將有效記錄匯入發送平台
→ 跨 Mailforge 配置的基礎設施分發聯絡人
→ 依發送網域和信箱監控活動結果
→ 重複使用前 60 至 90 天後重新驗證任何名單
每份名單在 Mailforge 層的上游驗證一次。從那一點起，Mailforge 處理發送的機制。名單決策和基礎設施決策是分開的，每個都應有明確的負責人。
在進入 Mailforge 配置基礎設施前路由每個結果。
| BillionVerify 結果 | 透過 Mailforge 發送前行動 |
|---|---|
| 有效 | 匯入活動聯絡人名單 |
| 無效 | 不匯入 — 退信損害 Mailforge 建立的網域聲譽 |
| Catch-all | 獨立的低量細分群組，每個網域密切監控 |
| 基於角色 | 獨立訊息軌道 — 低互動傷害收件箱投放訊號 |
| 未知 | 待人工審查 — 做出路由決策前排除 |
| 高風險或一次性 | 不匯入 |
其他套用類似決策的工作流程。
預熱前先驗證郵件
了解為什麼名單驗證必須在預熱之前進行，而不是之後。
匯入前名單清洗
在任何名單進入發件工具或 CRM 之前，套用統一的清洗規則。
冷郵件的 Catch-All 策略
在 catch-all 結果進入冷郵件活動前，制定路由策略。
冷郵件退信率控制
在名單層面控制退信率，在發件工具介入之前。
預熱 vs 郵件驗證
了解預熱解決哪類問題，驗證解決哪類問題。
內建驗證 vs 第三方驗證
比較發件工具原生驗證與專用發送前品質門控的差異。
Folderly + BillionVerify 工作流程
在 Folderly 送達率優化前驗證名單，乾淨的資料讓預熱更有效。
Mailforge 和 BillionVerify 工作流程常見問題。
如果 Mailforge 暖機我的發送網域，我還需要名單驗證嗎？
是的。暖機透過建立正面發送訊號的歷史來建立網域聲譽。來自無效記錄的退信產生的負面訊號，與暖機進展相悖。即使暖機良好的網域也會受到硬退信的聲譽降級影響。驗證確保進入已暖機基礎設施的地址不會產生削弱暖機投資的退信訊號。
名單驗證需要直接與 Mailforge 整合嗎？
不需要。最常見的方法是匯出聯絡人名單，透過 BillionVerify 執行，然後只將有效細分群組匯入連接到 Mailforge 基礎設施的活動平台。驗證發生在發送系統之外。BillionVerify 和 Mailforge 之間不需要整合，價值在於匯入前的決策，而非工具之間的連接。
我可以透過 Mailforge 向 catch-all 地址發送嗎？
可以，但應將它們視為獨立的低量細分群組。Catch-all 地址帶有不確定的投遞風險，網域接受郵件，但特定信箱可能不存在。向 catch-all 地址發送較低量並監控每個發送網域的結果，有助於識別哪些網域投遞成功，哪些產生靜默失敗或延遲退信。不要將 catch-all 記錄與已確認有效地址混在同一活動輪換中。
如果我透過 Mailforge 向無效地址發送，網域聲譽會怎樣？
來自無效地址的硬退信，產生收件箱服務商與發送網域關聯的負面退信訊號。持續的退信訊號隨時間降低網域聲譽，降低收件箱投放率，最終導致過濾或封鎖。Mailforge 可以管理網域輪換以分散風險，但它無法消除來自無效記錄的退信損害。唯一的預防措施是在發送前移除無效記錄。
我應該重新驗證在 Mailforge 管理活動中造成退信問題的名單嗎？
應該，同時也要審查哪些發送網域承受了最高的退信量。聯絡人名單應重新驗證，無效記錄加入永久抑制文件，catch-all 記錄在重複使用前審查網域層面的模式。在重新準備好進行下一次高量活動之前，累積了較高退信率的網域可能需要額外的類暖機乾淨發送。