冷開發信送達的關鍵：搞懂 SPF、DKIM、DMARC 三道驗證關卡
很多團隊搜尋spf dkim dmarc是什麼，是因為冷開發信寄出去卻進了垃圾信匣，文案再用心也沒人看到。這篇文章從SPF、DKIM、DMARC的差異談起，說明三者各自負責什麼、該怎麼設定與檢測，幫助準備啟動targeted B2B冷開發信的團隊，在放量寄送前先把寄件基礎設施打穩。
- SPF決定誰有資格代表網域寄信，DKIM用簽章證明信件沒被竄改，DMARC把兩者結果變成處置政策與回報機制。
- DMARC建議分階段從p=none觀察，逐步收緊到p=quarantine再到p=reject，避免誤擋自家合法信件。
- 三項驗證同時到位，冷開發信進收件匣的比例會明顯高於只設定其中一項。
- 上線寄送前務必用線上工具做一次spf dkim dmarc test，換寄信平台或設定完成後也要定期複查。
- 在台灣執行B2B冷開發信，仍需符合個人資料保護法對蒐集、處理與利用個資的基本要求。
為什麼冷開發信這麼看重郵件驗證
當業務團隊決定啟動冷開發信計畫，鎖定特定產業、特定職稱的窗口逐一寄送客製化信件時，第一個容易被忽略的環節不是文案，而是寄件網域本身有沒有被Gmail、Outlook、Yahoo奇摩等收件伺服器信任。收件伺服器在判斷一封信要進收件匣還是垃圾信匣之前，會先檢查寄件人是否通過驗證，內容再好、開頭個人化做得再細，驗證沒過關同樣會被攔下。
很多剛開始規劃寄送基礎設施的團隊會搜尋spf dkim dmarc是什麼，想知道三者差在哪裡。簡單說，這三者不是三選一的競爭關係，而是一層一層疊加的信任機制：SPF決定「誰有資格代表這個網域寄信」，DKIM用簽章證明「信件內容在傳輸過程沒被竄改」，DMARC則把前兩者的檢查結果整合成一套政策，並回報給網域管理者。
SPF：誰有權從你的網域寄信
SPF（Sender Policy Framework）是一筆公開在網域DNS上的TXT紀錄，列出哪些IP位址或寄信服務有權代表這個網域寄出郵件。收件伺服器收到信件後，會去查詢寄件網域的SPF紀錄，比對實際寄信的IP是否在授權清單內，不在清單內的信件就可能被標記為偽造或直接拒收。
對冷開發信團隊來說，SPF最常出問題的地方是授權範圍沒盤點完整：公司同時用Google Workspace收發內部信、又用另一套平台批量寄冷開發信時，兩邊的寄信服務都要各自加進同一筆SPF紀錄，用include語法串接，而不是各自建一筆新紀錄互相覆蓋。SPF也有DNS查詢次數上限，include疊太多層會直接讓整筆紀錄失效，這是設定時最容易忽略的地雷。
- 盤點所有會用這個網域寄信的服務，包含公司信箱、CRM、冷開發信平台
- 在網域DNS新增一筆TXT紀錄，格式以v=spf1開頭
- 用include語法把各服務的SPF紀錄串進去，而非各自新建
- 確認DNS查詢次數不超過十次，避免整筆紀錄失效
- 記得SPF只驗證信封寄件人，不驗證使用者看到的From欄位，需搭配DKIM才完整
假設台灣智造股份有限公司同時用Google Workspace寄內部信、用LDM的寄送平台寄冷開發信，SPF紀錄會寫成類似v=spf1 include:_spf.google.com include:_spf.ldm-platform.com ~all的格式，把兩個來源都用include語法串進同一筆紀錄，而不是各自新建一筆。
DKIM：用簽章證明信件沒被竄改
DKIM（DomainKeys Identified Mail）用非對稱加密的方式，替每一封寄出的信加上一組數位簽章，簽章的私鑰放在寄信伺服器，公鑰則公布在網域DNS的TXT紀錄裡。收件伺服器收到信後用公鑰驗證簽章，只要信件內容或標頭在傳輸途中被竄改，驗證就會失敗，這也是DKIM比SPF更能防止內容被冒用的原因。
實務上，每個寄信服務會用不同的selector產生各自的金鑰組，所以公司如果同時用Google Workspace寄內部信、用另一套系統寄冷開發信，DNS上會出現多筆DKIM紀錄，例如google._domainkey與寄送平台指定的selector，彼此互不影響，只要每一組都正確發布公鑰即可。
DMARC：把SPF與DKIM的結果變成政策
DMARC不是取代SPF或DKIM，而是規定收件伺服器在SPF、DKIM驗證失敗時該怎麼處理，並且要求驗證通過的識別必須跟使用者看到的From網域對齊，這一點正是SPF、DKIM各自單獨檢查時做不到的。DMARC紀錄同樣發布在DNS的TXT紀錄，可以指定三種政策：p=none只觀察不攔截、p=quarantine把可疑信件丟進垃圾信匣、p=reject直接拒收。
對於準備啟動大量冷開發信的網域，建議分階段導入：先以none政策觀察一段時間的驗證報表，確認公司所有合法寄信來源都通過後，再逐步收緊到quarantine、最後到reject。貿然一開始就設reject，很容易誤傷還沒被盤點到的合法寄信服務。
以上時程為根據targeted B2B冷開發信寄送實務整理的參考區間，並非固定標準，實際天數應依寄信來源複雜度調整。
SPF、DKIM、DMARC差異速查與對送達率的影響
把三者攤開來看，其實可以用「誰能寄」「有沒有被改」「沒通過怎麼辦」三句話，回答很多人在意的spf dkim dmarc difference與difference between spf dkim dmarc到底是什麼：SPF管的是寄信來源授權，DKIM管的是內容完整性，DMARC管的是失敗後的處置與回報。三者都設定齊全，收件伺服器才有足夠依據判斷這封信是網域擁有者本人授權寄出，而不是被冒用網域發送的垃圾郵件。
從實務觀察，只做SPF而沒有DKIM、DMARC的寄件網域，進主要收件匣的比例明顯偏低；三項都設定齊全、且DMARC對齊通過後，收件匣送達率會有清楚的提升，這也是LDM在替客戶建置冷開發信基礎設施時，一定會先確認這三層都到位才開始放量寄送的原因。
數字為根據targeted B2B冷開發信寄送實務整理的參考區間，並非固定研究數據，實際比例因產業與名單品質而異。
常見設定錯誤與spf dkim dmarc test檢測方法
最常見的錯誤有三種：第一是SPF紀錄疊太多include超過DNS查詢上限、整筆紀錄失效卻沒人發現；第二是新增冷開發信平台時只在該平台後台按下「已驗證」，卻忘記同時檢查DKIM selector有沒有真的發布到DNS；第三是急著把DMARC政策一次拉到reject，結果把公司自己內部系統寄出的信也一起擋掉。
設定完成後，建議用spf dkim dmarc check tool做一次完整檢測，市面上常見的線上工具都能同時檢查SPF、DKIM、DMARC三筆紀錄是否正確發布並互相對齊，也可以直接寄一封測試信到工具提供的信箱地址做spf dkim dmarc test，幾秒鐘就能看到三項驗證各自的通過與失敗結果。
- SPF紀錄的include層數是否超過DNS查詢上限
- 每個實際在用的寄信服務是否都有對應的DKIM selector公鑰
- DMARC政策是否從none階段觀察報表後才逐步收緊
- 新增或更換冷開發信平台時是否同步更新SPF與DKIM設定
- 定期用線上工具重新檢測，而不是設定完就不再檢查
LDM如何協助企業建置寄送基礎設施
LDM在替客戶建置targeted B2B冷開發信基礎設施時，會先確認寄件網域的SPF、DKIM、DMARC三層是否齊全對齊，再決定每日寄送量與暖機節奏，而不是先衝量再回頭補驗證，因為收件伺服器一旦把某個網域標記為低信譽，要重新建立信任往往比一開始就設定正確花更多時間。
另外，LDM會建議客戶為冷開發信使用獨立的寄件子網域，例如把主網域留給公司內部與客服信件，另外用一個子網域專門處理business development往來，這樣即使冷開發信的寄送節奏比較積極，也不會影響到主網域在客戶心中已經累積的信譽。
常見問題
SPF、DKIM、DMARC是什麼？三者一定要同時設定嗎？
SPF管誰有權寄信、DKIM用簽章證明內容沒被竄改、DMARC把兩者結果變成處置政策與回報。只設定其中一項只做了一半，收件伺服器沒有足夠依據判斷這封信是合法寄出，建議三者同時設定並互相對齊。
spf dkim dmarc test要怎麼做？
可以用線上檢測工具寄一封測試信，或直接查詢DNS的TXT紀錄，確認SPF、DKIM、DMARC三筆紀錄都正確發布。建議上線寄送前、以及每次更換或新增寄信平台後都做一次。
DMARC一定要設成p=reject嗎？
不一定，尤其是剛開始導入時。建議先用p=none觀察一段時間的驗證報表，確認所有合法來源都通過後再逐步收緊，貿然一開始就設reject容易誤擋自家還沒盤點到的寄信服務。
換了新的冷開發信平台，SPF和DKIM要重新設定嗎？
要。每個新的寄信服務都需要各自的SPF include與DKIM selector，忘記在DNS更新這些設定，是換平台後送達率下滑最常見的原因之一。
在台灣做B2B冷開發信，會不會違反個人資料保護法？
只要蒐集與使用聯絡資訊符合特定目的、以商務聯繫為必要範圍，並提供明確的退訂或拒絕聯繫方式，一般商務性質的冷開發信本身不等於違法，但仍建議建立合規的名單來源與退訂流程，降低爭議風險。
SPF、DKIM、DMARC分別用哪種DNS紀錄類型？
三者都是透過DNS的TXT紀錄發布，差別在主機名稱與內容格式：SPF放在網域本身，DKIM放在selector加上_domainkey的子網域，DMARC放在_dmarc子網域，三筆紀錄各自獨立，缺一都會讓驗證不完整。