新增機制前,先盤點所有寄件來源
列出您的工作區供應商、交易郵件服務、行銷平台、客服系統、CRM,以及任何在 MAIL FROM 或 HELO 中使用此網域的伺服器。漏列來源會造成誤判的 SPF 失敗;過時來源則會讓授權範圍過寬。
僅在該供應商確實為您寄信時,才使用其提供的 include 網域。不要複製其他公司的 SPF 紀錄,也不要只因機制看起來眼熟就加入。
為您的網域建立有效的 SPF TXT 紀錄。新增 IP 位址、郵件伺服器與第三方寄件服務,即可取得要發佈的精確 DNS 值。
新增獲授權為此網域寄送郵件的 IPv4 或 IPv6 位址。
新增 Google Workspace 或 SendGrid 等第三方寄件服務。
SPF(Sender Policy Framework)紀錄是一筆 DNS TXT 紀錄,用來指定哪些郵件伺服器有權代表您的網域寄送電子郵件。當收件伺服器收到聲稱來自您網域的郵件時,會查詢您的 SPF 紀錄,確認寄件 IP 是否在清單中。若該 IP 未經授權,郵件可能被拒收或標為垃圾郵件。
SPF 是與 DKIM、DMARC 並列的三大電子郵件驗證基礎標準之一。沒有 SPF,任何人都能在信封寄件者欄位偽造您的網域,使您的網域成為釣魚與仿冒攻擊的目標。多數現代信箱供應商與企業郵件閘道會在接受郵件前檢查 SPF。
每筆 SPF 紀錄都以 v=spf1 開頭,用來宣告版本。之後加入列出授權寄件者的機制。紀錄以稱為 all 機制的限定符結尾。
SPF 紀錄末尾的限定符,決定收件伺服器如何處理未經授權寄件者的郵件。
| 限定符 | 行為 |
|---|---|
| +all | 所有寄件者皆通過。切勿使用——這會使 SPF 完全失效。 |
| ~all | Softfail — 未經授權的郵件會被接受但加上標記。測試期間使用。 |
| -all | Hard fail — 未經授權的郵件會被拒收。正式環境使用。 |
| ?all | Neutral — 未聲明政策。很少有用。 |
若您使用第三方電子郵件服務,需以 include: 指令加入其授權寄件網域。以下是最常用的項目:
SPF 在評估時有 10 次 DNS 查詢的硬性上限。每個 include:、a 與 mx 機制都計為一次查詢。許多第三方 SPF 紀錄本身還會在內部觸發額外查詢。若您的紀錄總查詢超過 10 次,SPF 評估會回傳 PermError,並視為失敗。為維持在上限內,盡可能使用直接 IP 位址,並避免層層巢狀的 include。
單靠 SPF 只保護信封寄件者(Return-Path),不保護可見的 From 位址。若要完整防範仿冒,還需要 DKIM 為郵件簽章,以及 DMARC 將驗證結果與 From 標頭對齊。這三項標準共同構成 Gmail、Outlook 與 Yahoo Mail 所要求的電子郵件驗證基準。
設定 SPF 之後,也請確保您的名單是乾淨的。 電子郵件驗證 會在寄送前移除無效與高風險位址,有助壓低退信率,並保護您透過正確驗證建立的寄件者聲譽。您也可以透過 批量電子郵件驗證 批量驗證位址,或透過 電子郵件驗證 API直接整合進您的系統。
從實際寄件來源著手
SPF 紀錄是信封寄件網域的授權清單。產生器可以格式化這份清單,但清單必須先完整盤點所有代表您網域寄信的系統。
列出您的工作區供應商、交易郵件服務、行銷平台、客服系統、CRM,以及任何在 MAIL FROM 或 HELO 中使用此網域的伺服器。漏列來源會造成誤判的 SPF 失敗;過時來源則會讓授權範圍過寬。
僅在該供應商確實為您寄信時,才使用其提供的 include 網域。不要複製其他公司的 SPF 紀錄,也不要只因機制看起來眼熟就加入。
產生的值以 v=spf1 開頭,應放在一筆 DNS TXT 紀錄中。同一名稱下若有兩筆獨立的 v=spf1 紀錄,會造成永久評估錯誤;請將所有授權來源合併為單一政策。
SPF 是針對信封寄件網域評估,該網域可能是 return-path 子網域,而非可見的 From 網域。發佈前請先確認供應商實際使用的網域,不要假設應發在根網域。
機制與限定符
每個機制回答郵件可從何處發出。最後的限定符說明收件方應如何分類未匹配任何機制的寄件者。
ip4 與 ip6 授權指定位址或網段,無需額外 DNS 查詢。include 要求收件方評估另一個網域的 SPF 政策,讓供應商自行維護基礎架構,但會增加遞迴 DNS 負擔。
a 與 mx 機制授權從 DNS 解析出的位址。這樣很方便,但當這些紀錄服務於本無意寄信的系統時,政策範圍也會被擴大。
~all 將未匹配來源標為 softfail,-all 則標為 fail。這兩種指令都不會強制每個收件方投遞或拒收郵件;收件方會結合 SPF、DKIM、DMARC、聲譽、內容與本地政策一併判斷。
不要發佈 +all。它會授權網際網路上的所有來源,使 SPF 紀錄應提供的保護完全失效。
安全發佈
將產生視為草稿步驟。驗證與觀察才算完成變更。
加入每個必要的 IP 位址與供應商 include,移除重複項,上線時選擇較謹慎的限定符,並複製完整 TXT 值,不要帶入智慧引號或換行。
在信封寄件網域建立或取代 TXT 紀錄。各 DNS 控制台顯示主機名稱的方式不同,請確認供應商要的是 @、裸網域,還是僅子網域標籤。
使用 SPF 檢查器 確認公開 DNS 回傳一筆可解析的政策。接著透過每個合法平台寄信,並在收緊限定符之前檢查 Authentication-Results。
SPF 是營運設定,不是設完就忘的徽章。當供應商、退回路徑、IP 範圍或郵件架構變更時,請更新紀錄,並移除不再需要的授權。
產生器無法證明的事
請清楚這些界線,避免把語法正確的紀錄誤當成完整的電子郵件驗證。
此工具無法得知是否已揭露所有來源、巢狀 include 是否仍有效,或紀錄是否發佈在實際郵件使用的身分上。仍需進行公開 DNS 與郵件標頭測試。
include、a、mx、exists、redirect 及其遞迴相依都會消耗 DNS 查詢。看起來很短的政策,在評估巢狀供應商紀錄後仍可能超限並回傳 permerror。
完美的 SPF 結果無法說明收件信箱是否存在。寄送前請使用 電子郵件驗證器,將寄件者驗證與收件者驗證分開。
權威參考
本產生器遵循 SPF 標準用語,並將相關檢查放在獨立工具中。
IETF 的 RFC 7208 定義了 TXT 發佈、機制、修飾符、限定符、遞迴評估與處理上限。當供應商說明與一般設定建議衝突時,以標準為準。
使用 SPF 紀錄檢查器 檢查線上政策,使用 DKIM 紀錄產生器 發佈簽署金鑰,並使用 DMARC 紀錄產生器 加入對齊與回報。
依證據類型選擇下一個工具:收件者、探索、DNS 與基礎架構,或寄件工作流程。
免費工具
檢查並驗證任何網域的 SPF 記錄。查看完整 SPF 記錄、機制拆解,以及設定是否正確。免費、無需註冊。
網域或基礎架構證據——非信箱存在證明。
免費工具
為您的網域與選擇器建立正確的 DKIM DNS 紀錄格式。免費工具,協助準備郵件驗證所需的 TXT 主機名稱與值。
網域或基礎架構證據——非信箱存在證明。
免費工具
建立含政策、對齊與報告選項的 DMARC DNS TXT 記錄。免費網域電子郵件驗證產生器。
網域或基礎架構證據——非信箱存在證明。
免費工具
查詢任何網域的 A、AAAA、MX、TXT、NS 或 CNAME 記錄。即時 DNS 查詢,立即出結果。免費,無需註冊。
網域或基礎架構證據——非信箱存在證明。
郵件工具
對真實郵件樣本執行送達率測試。檢視 SPF、DKIM、DMARC、DNS、黑名單、垃圾郵件過濾、郵件頭與內容證據。
寄件者或訊息診斷——非地址探索。
郵箱驗證工具
用免費郵箱驗證器檢查地址是否有效:涵蓋語法、MX、SMTP 郵箱、一次性、角色與 Catch-All 檢查。
收件者證據——非寄件者或 DNS 設定。
SPF 全名為 Sender Policy Framework。這是一種以 DNS 為基礎的電子郵件驗證方法,讓網域擁有者指定哪些郵件伺服器可代表其寄信。沒有 SPF,任何伺服器都能聲稱來自您的網域寄信,釣魚攻擊變得輕而易舉。ISP 與垃圾郵件過濾器會將 SPF 結果作為決定是否投遞郵件的主要信任訊號。
使用此工具產生 SPF 紀錄,然後登入您的 DNS 供應商,在網域根(通常以 @ 或裸網域表示)新增一筆 TXT 紀錄,並填入產生的值。變更通常在 30 分鐘內傳播,全球最多可能需要 48 小時。
~all(softfail)告訴收件伺服器,來自未列出 IP 的郵件可疑但仍應接受。-all(hardfail)指示伺服器拒收或重罰未列出的寄件者。首次設定 SPF 時使用 ~all,確認所有寄件服務都已列入後,再改為 -all。
不行。一個網域必須恰好有一筆 SPF 紀錄。若同一網域存在兩筆以 v=spf1 開頭的 TXT 紀錄,SPF 評估會產生永久錯誤,導致所有郵件無法通過 SPF 檢查。請將所有機制合併為單一紀錄。
SPF 將每次評估中會查詢 DNS 的機制(include、a、mx、ptr、exists)總數限制為 10 次。超過此上限會產生 permerror。請仔細計算 include 數量——許多供應商會串連多層巢狀 include,每一層都計入您的上限。
SPF 只驗證信封寄件者(MAIL FROM)位址,不驗證顯示給收件者的可見 From 標頭。即使 SPF 通過,攻擊者仍可偽造 From 標頭。若要徹底防止收件匣中可見的網域仿冒,需要同時與 SPF、DKIM 對齊的 DMARC 政策。