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