SPF 記錄完整指南：原理、配置語法、驗證與反垃圾郵件最佳實踐

SPF (Sender Policy Framework) 是基於 DNS TXT 記錄的郵件發送方授權機制，旨在解決「發件人地址偽造」這一垃圾郵件核心難題。正確部署 SPF 能顯著提升域名郵件信譽，降低進垃圾箱概率。

工作原理

1. 發件服務器發送郵件，聲稱發件域為 example.com。
2. 收件服務器查詢 example.com 的 DNS TXT 記錄獲取 SPF 策略。
3. 對比發件服務器 IP 是否包含在 SPF 授權列表中。
4. 匹配 → Pass (加分)；不匹配 → Fail/SoftFail (扣分/拒收)。
5. 結合 DKIM、DMARC、內容過濾綜合判定最終投遞動作。

SPF 記錄語法速查

v=spf1 [mechanisms] [modifiers] [all]

限定詞 (Qualifiers)

• + Pass (預設，可省略)
• - Fail (明確拒絕，建議生產環境最終用 -all)
• ~ SoftFail (疑似偽造，標記但不拒，調試期適用)
• ? Neutral (不表態)

實戰配置範例

企業自建郵件服務器 + 第三方營銷平台

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.mandrillapp.com -all

• 授權企業出口 IP 段
• 引入 Google Workspace 與 Mandrill 發信授權
• -all 明確拒絕其他來源

純第三方發信 (無自建服務器)

v=spf1 include:_spf.google.com include:sendgrid.net -all

驗證與排查工具

• nslookup -type=txt example.com：查看原始記錄
• dig txt example.com：Linux 下更詳細
• MXToolbox SPF Lookup：圖形化分析語法、巢狀 include 深度、IP 覆蓋
• 郵件原始碼檢視：檢查 Received-SPF: pass / Authentication-Results: spf=pass

常見坑點與最佳實踐

1. DNS 查詢限制 10 次：include/redirect/a/mx/ptr/exists 總和不得超過 10 次，否則 PermError。合併 IP 段、扁平化 include 可規避。
2. 字符串長度 ≤ 255 字節：單條 TXT 記錄超長需拆分多條 (續傳)，但仍受 10 次查詢限制。
3. 子域名需單獨部署：mail.example.com 不會自動繼承 example.com 的 SPF，必須在子域添加 TXT 記錄。
4. 從 ~all 過渡到 -all：新部署先用 ~all 觀察 1-2 週，確認無誤報後改 -all。
5. 配合 DKIM + DMARC：SPF 僅驗證信封發件人 (Return-Path)，DKIM 簽署信件內容，DMARC 統一策略與報告，三位一體才是完整防偽鏈。