冷開發信上線前的 Email Deliverability 檢查清單：SPF、DKIM、DMARC 全檢查
冷開發信只要進了垃圾郵件匣，再精準的名單與文案都白費工夫。這份 email deliverability checklist 整理出正式上線前必須完成的技術檢查——從 SPF、DKIM、DMARC 的 dmarc check，到網域暖身排程與退信監控門檻——讓 targeted B2B 開發信一開始就走在對的軌道上。
- 上線前務必完成一次完整的 email deliverability checklist，涵蓋 DNS 驗證、暖身排程與退信監控三大重點
- SPF、DKIM、DMARC 缺一都會拉低到達率，建議定期用 dmarc checker 做 dmarc check
- 新網域或子網域需要 3–4 週暖身期，寄送量應循序漸進
- 硬退信率超過 2%–3%、客訴率超過 0.1% 就是停損訊號
- 在台灣，cold email 的蒐集與行銷使用皆受個資法第19條、第20條規範，退出機制不能只是形式
為什麼上線前一定要做 Email Deliverability Checklist
冷開發信的文案再精準，只要進了垃圾郵件匣，SDR 團隊的努力就等於白費。Gmail、Outlook、Yahoo 與中華電信信箱都用演算法即時評估寄件網域的信譽，新網域或剛加入大量寄送行為的舊網域，在演算法眼中都是高風險對象。這正是為什麼正式發送前，必須先完成一輪完整的 email deliverability checklist——把 DNS 驗證、暖身排程與退信監控都逐項確認過，而不是等到到達率掉到谷底才回頭補救。
健康的 targeted B2B cold email 專案，回覆率通常落在 3%–8%，退信率應控制在 2%–3% 以下，客訴（標記垃圾郵件）比例則要低於 0.1%。這些數字不是憑空訂出來的門檻，而是 ISP 決定要不要把信件放進收件匣的實際依據。只要有一項技術設定出錯，即使內容再個人化，信件也可能被批次丟進垃圾郵件匣，甚至讓整個公司網域的商業信譽受損——包括平常用來寄合約、寄發票的正式信箱。
DNS 驗證：SPF、DKIM、DMARC 逐項確認
SPF、DKIM、DMARC 三組紀錄合稱寄件方驗證機制，也是任何 email deliverability check 的第一關。SPF 記錄哪些伺服器有權以你的網域寄信；DKIM 用加密簽章證明信件內容沒有被竄改；DMARC 則告訴收件伺服器，如果 SPF 或 DKIM 驗證失敗該怎麼處理，並把驗證結果回報給你。三者缺一，到達率都會被打折扣。
建議至少每季用 dmarc checker 工具做一次 dmarc check，同時搭配完整的 spf dkim dmarc check，確認以下項目沒有遺漏。
- SPF 記錄涵蓋所有實際寄件來源（LDM 平台伺服器、Google Workspace、行銷自動化工具），且 DNS 查詢次數未超過 10 次上限
- DKIM 金鑰至少 2048 bit，selector 與實際寄送平台一致，且已在 DNS 正確發佈
- DMARC 紀錄存在，上線初期先設 p=none 觀察，穩定後再調整為 p=quarantine
- DMARC 的 rua 報告信箱有人固定查看，用來抓出偽冒或設定錯誤
- 追蹤連結與客製化寄送網域（tracking domain）也要與寄件網域對齊，避免 DMARC alignment 失敗
數字為 LDM 在協助企業上線前檢查時觀察到的比例區間，僅供參考，非正式統計研究。
網域與 IP 暖身：暖身排程與每日寄送量
就算 SPF、DKIM、DMARC 全部設定正確，一個全新網域或子網域如果第一天就寄出兩百封 cold email，仍然會被 ISP 視為異常行為。暖身（warm-up）的邏輯很單純：讓寄送量隨著時間緩步增加，讓 ISP 的演算法逐步累積這個網域「值得信任」的證據。對台灣 B2B 精準開發信來說，這件事其實比多數人想像的容易，因為原本就不追求大量寄送，暖身曲線可以走得穩健。
實務上建議用專門的子網域（例如 mail.公司網域.com）寄送 cold email，跟公司日常用來收發合約、發票的主網域分開。這樣即使暖身期間出現波動，也不會拖累到公司真正重要的商業信箱。
暖身曲線依網域歷史與產業而異，此為 LDM 執行 targeted B2B 專案時常見的區間，僅供參考。
以一間虛構的台北 SaaS 新創「程諾科技」為例：他們用 outreach.chengnuo.com 這個新子網域寄送 cold email，第一週每天僅寄 20 封給精準篩選過的五金製造業採購主管，並觀察每一批的開信率與退信率；確認退信率低於 2% 後，第二週才提高到 40 封，第四週穩定在每天 150 封的目標量，全程沒有觸發任何 ISP 的信譽保護機制。
退信與客訴監控：即時追蹤與停損門檻
上線之後，checklist 的工作沒有結束，而是換成即時監控。退信要分成硬退信（信箱不存在、網域錯誤）與軟退信（信箱滿了、暫時性阻擋），硬退信比例一旦超過 2%–3%，就該立刻暫停該批名單重新清洗，而不是等到整個網域信譽被拖垮才處理。客訴率（收件人按下「標記垃圾郵件」）則要控制在 0.1% 以下，Gmail 與 Yahoo 這幾年都把這個門檻執行得更嚴格。
退出機制也是監控的一部分，而且在台灣有明確的法律依據。依個資法第20條第2項，非公務機關利用個人資料行銷時，當事人一旦表示拒絕接受行銷，蒐集方就必須立即停止利用該筆資料行銷；第3項並要求首次行銷時，就要告知當事人有拒絕接受行銷的權利，並提供免費、簡便的拒絕方式。實務上，這代表每一封 cold email 都要放清楚的取消訂閱或回覆退出的方式，而且退出名單要即時同步進 CRM，不能只是形式上放個連結卻沒有真的處理。
- 硬退信率即時監控，單一批次超過 3% 立即暫停
- 客訴率控制在 0.1% 以下，接近門檻時降低單日寄送量
- 定期用種子帳號（seed list）測試 Gmail、Outlook、Yahoo、中華電信信箱的實際到達情況
- 黑名單監控（例如 Spamhaus）納入例行檢查，避免網域被列入卻沒人發現
- 退出（opt-out）名單即時同步 CRM，符合個資法第20條的通知與停止利用義務
上線前最容易忽略的錯誤
多數 deliverability 問題不是因為技術太複雜，而是流程上漏掉了某個步驟。
- 沿用舊網域重新寄送，卻沒先確認它是否曾被列入黑名單或有過不良寄送紀錄
- 跳過暖身，直接用目標寄送量開跑，尤其是換了新的 ESP 或平台之後
- cold email 跟日常商業信件共用同一個主網域，讓兩種完全不同的寄送模式互相干擾信譽
- DMARC 設成 p=none 之後就沒人再看 rua 報告，錯過異常訊號
- follow-up 節奏設計成固定天數自動連發，忽略對方是否已讀或已回覆，拉高客訴率
- 認為做過一次 email deliverability checklist 就一勞永逸，沒有排定季度覆核
LDM 如何把這份檢查清單變成日常流程
LDM 在每個 targeted B2B 專案上線前，都會先跑一次完整的 email deliverability check：確認 SPF、DKIM、DMARC 設定、規劃專屬子網域與暖身排程、並在 CRM 裡建立退信與客訴的即時儀表板，而不是把這些檢查留給客戶自己事後補救。
上線之後，系統持續追蹤每一批名單的退信率、客訴率與回覆率，一旦超過門檻就自動降速或暫停，同時把退出請求即時同步，對應個資法對行銷退出機制的要求。目標是讓業務團隊專心經營對的人、對的公司，而不用擔心信件連收件匣都進不去。
常見問題
什麼是 email deliverability checklist？
它是一份在正式發送 cold email 前，用來逐項確認技術與流程是否到位的清單，內容涵蓋 SPF、DKIM、DMARC 等 DNS 驗證、網域暖身排程，以及退信與客訴監控機制。目的是在信件大量寄出之前，先排除會讓 ISP 判定為垃圾郵件的技術風險。
dmarc checker 和 spf dkim dmarc check 工具怎麼用？
把寄件網域輸入 dmarc checker，工具會讀取 DNS 上的 DMARC 紀錄並顯示目前的 policy（none／quarantine／reject）與報告信箱設定；完整的 spf dkim dmarc check 通常還會一併驗證 SPF 語法是否超過查詢次數上限，以及 DKIM selector 是否正確發佈。建議上線前跑一次，之後每季再覆核。
網域暖身要花多久時間？
一般子網域從個位數寄送量暖身到目標量，大約需要 3–4 週；網域越新、產業寄送規範越嚴格（如金融、醫療），暖身期可以拉得更長。台灣 targeted B2B 專案因為原本寄送量就不大，暖身通常比大量行銷信件更快穩定。
退信率多少算健康？
硬退信率建議控制在 2% 以下，超過 3% 就代表名單品質有問題，應該立刻停下來清洗；客訴率則應維持在 0.1% 以下。這兩個數字一旦亮紅燈，代表的是網域信譽正在被消耗，拖越久修復成本越高。
在台灣寄 cold email 會受個資法規範嗎？
會。企業聯絡人的姓名、職稱、公司信箱屬於個資法所稱之個人資料，蒐集時需符合第19條的特定目的與法定要件（例如取自企業官網、名片等一般可得來源）；用於行銷時，第20條也要求首次寄送就告知拒絕行銷的權利，並在對方表示拒絕後立即停止利用。
可以用公司主網域直接寄 cold email 嗎？
技術上可以，但不建議。cold email 的寄送模式（同一時間對外部陌生對象大量寄送）跟日常商業信件差異很大，一旦踩到 ISP 的信譽保護機制，可能連帶影響到主網域的合約、發票等重要信件的到達率。用專屬子網域隔開風險，是比較穩健的作法。