如何正確設定 DKIM 與 SPF

如果你的陌生開發信總是掉進垃圾郵件匣、莫名其妙被退信，或是被 Google 和 Microsoft 標記，那你首先要解決的不是文案問題，而是信任問題。學會如何正確設定 DKIM 與 SPF，是提升送達率最快的方法之一，因為它能告訴收件匣服務商：這封郵件確實是由你的網域授權寄出的。

對於任何會寄送開發活動的企業來說，這不是可有可無的技術雜務，而是營收基礎架構的一部分。如果你用自訂網域來進行開發，在放大寄信量、測試活動或評估成效之前，就必須先把 SPF 和 DKIM 設定好。

如何設定 DKIM 與 SPF，不必搞得太複雜

SPF 和 DKIM 的工作相關，但並不相同。

SPF，全名 Sender Policy Framework，用來告訴收件伺服器，哪些郵件伺服器可以代表你的網域寄送電子郵件。你可以把它想成公布在 DNS 記錄裡的一份「核准寄件者名單」。

DKIM，全名 DomainKeys Identified Mail，會為你寄出的電子郵件加上一個加密簽章。這個簽章可以證明郵件是由你的網域授權寄出，而且在傳送過程中沒有被竄改。

如果沒有 SPF，收件匣服務商就比較難相信你的寄信伺服器是合法的。如果沒有 DKIM，它們就缺少證據證明郵件本身是真實的。你需要兩者同時運作。多數情況下，你最終也會想要設定 DMARC，但 SPF 和 DKIM 才是第一步。

開始設定之前

你需要能進入兩個地方：網域的 DNS 設定，以及你的電子郵件寄送平台。DNS 通常是透過你的網域註冊商或主機供應商來管理。你的寄送平台可能是 Google Workspace、Microsoft 365、你的陌生開發信軟體、你的 SMTP 供應商，或是專門的寄信服務。

實際的操作畫面會因平台而異，但流程通常都一樣。電子郵件供應商會給你要新增的 DNS 記錄，你把它們發布到網域設定裡，然後確認它們已經生效。

如果你是從獨立的網域或子網域來寄送開發信，這通常是更聰明的做法。當你的活動品質下滑，或寄信量成長得太快時，它能保護你主網域的信譽。很多寄件者直到成效下降才想到這件事，到那時他們已經是在修復損害，而不是預防損害了。

步驟 1：新增 SPF 記錄

你的 SPF 記錄是 DNS 中的一筆 TXT 記錄。它以 v=spf1 開頭，並列出獲准代表你網域寄信的服務。

一個簡單的範例大概長這樣：

v=spf1 include:_spf.google.com ~all

這個範例告訴收件匣服務商，Google 可以代表你的網域寄送電子郵件。如果你還使用其他平台，例如開發工具或交易型郵件服務，也可能需要把該服務一併加進去。

SPF 的關鍵在於，一個網域只能有一筆 SPF 記錄。不是兩筆，也不是每個工具各一筆，而是一筆包含所有授權寄件者的記錄。

這正是許多企業在不知不覺中搞砸送達率的地方。他們在串接新平台時，會再新增第二筆 SPF TXT 記錄。DNS 會接受它，但收件郵件伺服器可能會把這組 SPF 設定視為無效。解決方法是把所有授權寄件者合併成單一一筆 SPF 記錄。

你還需要留意結尾的標籤。~all 是軟性失敗（soft fail），常見於初期的設定。-all 則是硬性失敗（hard fail），更為嚴格。該用哪一個，取決於你有多確定已經涵蓋了所有合法的寄信來源。如果你太急著改用 -all，又漏掉了某個寄件來源，合法郵件就可能驗證失敗。

步驟 2：新增 DKIM 記錄

DKIM 同樣是透過 DNS 新增，但依供應商不同，通常會使用一筆或多筆 CNAME 或 TXT 記錄。

你的電子郵件平台會產生一組 DKIM 選擇器（selector）和一把公開金鑰。你要把這些資訊原封不動地加到 DNS 裡。接著，你的寄送平台會在背後使用對應的私密金鑰，替寄出的郵件簽章。

DKIM 記錄看起來往往比 SPF 更技術性，但真正的規則很簡單：一字不差地複製。少一個字元、斷行，或是主機名稱錯誤，都可能導致驗證失敗。

有些供應商會要你發布像這樣的主機值：

selector1._domainkey.yourdomain.com

然後再附上他們提供的對應 TXT 值或 CNAME 目標。

這筆記錄傳播完成後，你的供應商應該就能驗證它。驗證通過後，透過該供應商寄出的郵件就會帶有與你網域綁定的 DKIM 簽章。

如果你同時從多家供應商寄信，可能會有多個 DKIM 選擇器。這很正常。與 SPF 不同，DKIM 可以支援多筆記錄，因為每個選擇器都是各自獨立的。

步驟 3：寄出大量郵件前，先驗證兩種記錄

不要因為按下了儲存，就以為 DNS 變更已經生效。DNS 傳播可能需要幾分鐘，有時甚至更久。多數寄送平台都提供驗證按鈕或狀態檢查，請務必使用。

你也應該寄測試郵件到自己掌控的帳號，例如 Gmail 或 Outlook，並檢查郵件標頭或驗證結果。你要看到的是 SPF pass 和 DKIM pass。

如果一個通過、另一個失敗，代表你只完成了部分驗證，並沒有完整設定好。這樣的表現可能還是比完全不驗證要好，但不是開發活動應有的標準。

傷害送達率的常見錯誤

最大的錯誤，就是把 SPF 和 DKIM 當成打勾了事的例行公事。事實並非如此。錯誤的設定，傷害幾乎不亞於完全沒設定，因為它會造成不一致的驗證結果。

一個常見的問題是使用了錯誤的寄信網域。你看得到的寄件者（From）地址，必須與你驗證過的網域一致。如果你的平台用某個網域簽章，但郵件卻宣稱來自另一個網域，信任很快就會瓦解。

另一個問題是忘了轉寄會影響 SPF。由於 SPF 檢查的是寄信伺服器的傳送路徑，即使原始寄件者是合法的，轉寄的郵件也可能無法通過 SPF。在這種情況下，DKIM 的韌性更強，因為它驗證的是內容上的簽章。這也是 DKIM 如此重要的原因之一。

還有記錄攤平（flattening）和 SPF 查詢次數上限的問題。SPF 只允許有限次數的 DNS 查詢。如果你從太多工具堆疊了太多 include，就可能超過上限而導致失敗。對於工具堆疊雜亂的企業來說，這點很重要。有時候答案是整理清理，而不是再打一個補丁。

這會如何影響陌生開發的成效

如果你寄的是銷售信，驗證會直接影響收件匣的送達位置，而不只是合規問題。再好的方案，只要信件根本沒被看到，就毫無意義。

郵件服務商會把驗證當作多項信任訊號之一。它救不了錯誤的鎖定對象、薄弱的文案，或是莽撞的寄信模式。但沒有它，即使是設計良好的活動，一開始也已經落於劣勢。

如果你是大規模寄信給新的潛在客戶，這點尤其明顯。陌生開發本來就比與既有客戶的往來受到更多檢視。你需要的是用技術設定來減少阻力，而不是製造更多阻力。

這就是為什麼執行開發活動的企業，思考的範圍不能只停留在寄信軟體。整個系統都很重要：網域設定、信箱健康度、DNS 記錄、寄信量的逐步提升、名單品質，以及訊息的相關性。工具可以加快執行速度，但沒有任何工具能跑贏一個已經壞掉的網域信譽。

你還需要 DMARC 嗎？

通常需要。但要有正確的預期。

DMARC 建立在 SPF 和 DKIM 之上。它告訴收件匣服務商，當驗證失敗時該怎麼處理，也讓你能看到報告。如果沒有先設定好 SPF 和 DKIM，DMARC 幾乎沒有可以運作的基礎。

對許多企業來說，聰明的順序是先 SPF、再 DKIM、最後 DMARC。如果你操之過急，直接跳到採用拒絕政策（reject）的 DMARC，而底層設定又有誤，就可能擋掉合法郵件。請先從監控開始，確認一致性（alignment），再逐步收緊政策。

適用於多數企業的實用設定標準

如果你想要一個可靠的基準，就為開發信使用專用的寄信網域或子網域，發布一筆乾淨的 SPF 記錄，在寄送平台啟用 DKIM，驗證兩者，並在活動上線前先測試。等基礎穩定之後，再加入 DMARC。

這個做法能讓你掌握主導權。它保護你的核心品牌網域，讓問題排查更容易，也為放大開發規模鋪出一條更乾淨的路。

對於非技術背景的團隊來說，好消息是這通常只需要設定一次，不是每天的工作。一旦正確完成，你就可以把注意力放回真正推動銷售管道的事情上：鎖定對的潛在客戶、寫出更好的方案，以及有紀律地寄信。

如果你是認真把電子郵件當作銷售管道，就不要把驗證當成事後補救。一次設定好、確實驗證，讓你的活動有公平的機會進入收件匣。