Live Direct Marketing
首頁 → 部落格 → 郵件到達率

手把手完成 SPF、DKIM、DMARC 設定，讓 B2B 開發信穩定進收件匣

2026年7月12日 · 8 分鐘閱讀 · 指南: 郵件到達率

許多業務團隊把心力都花在開發信的文案與名單，卻忽略了網域本身有沒有通過 SPF、DKIM、DMARC 驗證——這往往是決定開發信落入收件匣還是垃圾郵件匣的第一道關卡。本文示範如何為寄送冷開發信的網域完整完成 spf dkim dmarc 設定，並說明如何一步步收緊 DMARC 政策，才不會因為送達率低而白白浪費精準名單。

重點整理
  • SPF、DKIM、DMARC 三項驗證缺一不可，三者共同組成收件方判斷寄件網域是否可信的依據
  • DMARC 應該從 p=none 開始觀察報表，逐步收緊到 quarantine、reject，不要一次到位
  • 轉寄信件、多組寄件工具、追蹤連結子網域都可能讓 SPF/DKIM 對齊失敗，需要逐一檢查
  • Gmail、Outlook 等主要信箱服務商已將完整驗證紀錄視為寄件網域可信度的基本門檻
  • 設定完成後仍要定期做 spf dkim dmarc 設定確認，而不是設完就不管

為什麼精準開發信也逃不過 SPF、DKIM、DMARC 這一關

B2B 冷開發信講求精準——鎖定特定產業、特定職位的窗口，每天只寄出少量、高度個人化的信件，理論上跟大量垃圾郵件完全是兩回事。但 Gmail、Outlook、Yahoo 這類主要信箱服務商在判斷一封信要不要進垃圾郵件匣時，並不會先讀內容，而是先檢查寄件網域有沒有通過 SPF、DKIM、DMARC 驗證。就算內容寫得再客製化，只要網域驗證沒做好，系統照樣把信攔在收件匣外。

台灣多數中小企業的網域原本是用來收發日常業務信件的，DNS 紀錄很少特別為開發信優化過。一旦開始用同一個網域大量寄送開發信，收件方的過濾器會更嚴格地檢視這個網域過去有沒有被明確授權寄信、簽章是否正確、政策是否對齊——這正是 SPF、DKIM、DMARC 三者要解決的問題。

SPF 設定：先把授權寄件來源講清楚

SPF（Sender Policy Framework）是一筆 TXT 紀錄，列出哪些伺服器、哪些服務有權以你的網域名義寄信。設定重點是網域只能有一筆 SPF 紀錄，如果同時使用 Google Workspace、開發信平台（例如 LDM）、行銷工具寄信，必須把所有來源合併進同一筆紀錄，而不是各自新增一筆——多筆 SPF 紀錄會直接讓驗證失效。

實務作法是先列出所有會用這個網域寄信的服務，逐一取得官方提供的 include 語法，組成一筆完整紀錄，結尾先用 ~all（軟性失敗，建議觀察期使用），穩定後再視情況改成 -all（嚴格拒絕未授權來源）。

範例

凱信國際的網域 kaishin-intl.com.tw 若同時用 Google Workspace 收發信、LDM 平台寄開發信，SPF 紀錄會是：v=spf1 include:_spf.google.com include:mail.ldm.tw ~all，代表這兩個來源都被授權以此網域寄信，其餘一律視為未經授權。

DKIM 設定：讓每封信都帶有可驗證的簽章

DKIM（DomainKeys Identified Mail）是用一組加密金鑰對每封寄出的信做數位簽章，公鑰發布在 DNS 的 TXT 紀錄裡（格式通常是 selector._domainkey.你的網域），私鑰留在寄件伺服器端簽署信件。收件方收到信之後，用公鑰驗證簽章是否吻合，藉此確認信件沒有被竄改，也確實是這個網域授權寄出的。

在 Google Workspace 管理後台或開發信平台裡開啟 DKIM 簽署功能，系統會產生一組專屬的 selector 與公鑰，把公鑰貼進 DNS 之後回到後台按下啟用即可。同一個網域如果用多個工具寄信，建議每個工具各自使用獨立的 selector，方便日後追查是哪個來源出問題。

DMARC 設定：把 SPF 與 DKIM 綁在一起，逐步收緊政策

DMARC（Domain-based Message Authentication, Reporting and Conformance）本身不是另一種驗證方式，而是一份政策，規定當一封信的 SPF 或 DKIM 驗證失敗、或是與 From 欄位網域沒有對齊時，收件方該放行、隔離到垃圾郵件匣、還是直接拒收，同時把結果彙整成報表寄回給你。做 dmarc 設定的重點，不是一次到位設成最嚴格，而是先觀察再收緊。

建議流程是先以 p=none 上線，只收報表不做任何攔截，觀察兩週左右，確認所有合法寄件來源都通過對齊；接著改成 p=quarantine，讓沒對齊的信被導向垃圾郵件匣；最後在確定沒有誤殺合法郵件的情況下，才調整為 p=reject。

最容易踩的地雷

SPF、DKIM、DMARC 各自獨立設定看起來不難，但三者要同時對齊、又要涵蓋所有寄件來源，實務上很容易漏東漏西，尤其是網域除了寄開發信、還有其他業務系統在用的時候。

LDM 怎麼確保每個寄件網域都準備好

LDM 在每個網域正式開始寄送開發信之前，會先做一輪 spf dmarc dkim 設定檢查：確認 SPF 紀錄只有一筆且涵蓋所有寄件來源、DKIM 簽章正確發布、DMARC 政策依觀察期逐步收緊，同時搭配網域暖身機制，讓每天寄送量緩慢上升，而不是一開始就用新網域大量寄信。

完整的驗證紀錄只是送達的地基，LDM 平台會持續監控每個寄件網域的收件匣到達率、退信率與垃圾郵件回報，一旦數據異常就會提前示警，而不是等業務發現名單毫無回應才回頭檢查網域設定。

常見問題

一個網域一定要同時設定 SPF、DKIM、DMARC 嗎？

是的。三者分工不同——SPF 授權寄件來源、DKIM 驗證信件完整性、DMARC 決定驗證失敗時如何處理並綁定對齊規則，只做其中一兩項，收件方仍可能把信判定為風險較高而丟進垃圾郵件匣，尤其 Gmail、Outlook 這類主要信箱服務商現在都會同時檢查三者。

spf dkim dmarc 設定完成後多久生效，怎麼確認？

DNS 紀錄通常幾分鐘到數小時內就會傳播完成，但保守建議等 24 到 48 小時再做 spf dkim dmarc 設定確認，用 dig txt 或線上檢測工具查詢紀錄，並實際寄一封測試信檢查信件標頭裡的 SPF、DKIM、DMARC 結果是否都顯示通過。

DMARC 政策要一開始就設成 reject 嗎？

不建議。一開始就用 p=reject 很容易因為漏掉某個寄件來源而誤擋合法郵件，包括內部系統通知信。正確做法是先用 p=none 收集報表觀察，確認所有來源都對齊後，再逐步收緊到 quarantine、最後才是 reject。

用 Google Workspace 寄開發信，gmail spf dkim dmarc 設定要注意什麼？

在 Google 管理控制台的「應用程式」→「Gmail」→「驗證」裡開啟 DKIM 簽署並取得公鑰，貼進 DNS；SPF 紀錄要加入 include:_spf.google.com；同時建議在 Postmaster Tools 綁定網域，追蹤 Gmail 端看到的網域信譽與垃圾郵件回報率，即時發現驗證或信譽出問題。

開發信平台用的子網域也要重新設定驗證嗎？

要。子網域（例如追蹤連結或寄件用的子網域）在 DNS 上被視為獨立實體，需要各自設定 SPF 與 DKIM，並確認 DMARC 對齊規則涵蓋子網域，否則主網域驗證再完整，子網域寄出的信一樣可能被判定為未通過驗證。

用公司聯絡人 email 寄開發信，個資法有什麼限制？

依個人資料保護法第20條，即使是合法蒐集的業務聯絡人資料，用於行銷（包含開發信）時仍須提供當事人表示拒絕接受行銷的方式，一旦對方表示拒絕，就必須立即停止利用其個人資料寄送行銷內容；實務上建議每封開發信都附上明確的取消訂閱或拒絕聯繫方式，並確實執行退訂需求。

重要：這不是大量群發，也不是垃圾郵件。 我們採取精準外聯：每封訊息都基於正當商業理由，寄給特定公司的特定負責人，每日寄送量少，並針對收件人進行個人化。每封郵件都標明寄件人並提供一鍵取消訂閱；取消訂閱與封鎖名單將無一例外地套用於所有後續活動。

想把這套方法用在你的客戶開發上嗎？

在開始之前，我們會說明這套做法如何套用到你的市場區隔與產品。

與我們聯繫

更多相關主題: 郵件到達率