📍 隆重推出 MapLeads:把 Google 地圖、Bing 地圖、Apple 地圖變成你的客戶名單。了解 MapLeads
免費工具

SPF 紀錄產生器

為您的網域建立有效的 SPF TXT 紀錄。新增 IP 位址、郵件伺服器與第三方寄件服務,即可取得要發佈的精確 DNS 值。

產生您的 SPF 紀錄

新增獲授權為此網域寄送郵件的 IPv4 或 IPv6 位址。

新增 Google Workspace 或 SendGrid 等第三方寄件服務。

什麼是 SPF 紀錄?為什麼重要?

SPF(Sender Policy Framework)紀錄是一筆 DNS TXT 紀錄,用來指定哪些郵件伺服器有權代表您的網域寄送電子郵件。當收件伺服器收到聲稱來自您網域的郵件時,會查詢您的 SPF 紀錄,確認寄件 IP 是否在清單中。若該 IP 未經授權,郵件可能被拒收或標為垃圾郵件。

SPF 是與 DKIM、DMARC 並列的三大電子郵件驗證基礎標準之一。沒有 SPF,任何人都能在信封寄件者欄位偽造您的網域,使您的網域成為釣魚與仿冒攻擊的目標。多數現代信箱供應商與企業郵件閘道會在接受郵件前檢查 SPF。

了解 SPF 紀錄語法

每筆 SPF 紀錄都以 v=spf1 開頭,用來宣告版本。之後加入列出授權寄件者的機制。紀錄以稱為 all 機制的限定符結尾。

  • ip4:x.x.x.x — 授權單一 IPv4 位址
  • ip4:x.x.x.x/24 — 授權一個 IPv4 CIDR 範圍
  • ip6:::1 — 授權一個 IPv6 位址
  • include:domain.com — 引用另一個網域的 SPF 紀錄(用於第三方寄件服務)
  • a — 授權該網域 A 紀錄的 IP
  • mx — 授權該網域 MX 紀錄的 IP

SPF 政策限定符說明

SPF 紀錄末尾的限定符,決定收件伺服器如何處理未經授權寄件者的郵件。

限定符行為
+all所有寄件者皆通過。切勿使用——這會使 SPF 完全失效。
~allSoftfail — 未經授權的郵件會被接受但加上標記。測試期間使用。
-allHard fail — 未經授權的郵件會被拒收。正式環境使用。
?allNeutral — 未聲明政策。很少有用。

常見的 SPF Include 指令

若您使用第三方電子郵件服務,需以 include: 指令加入其授權寄件網域。以下是最常用的項目:

  • Google Workspace: include:_spf.google.com
  • Microsoft 365: include:spf.protection.outlook.com
  • Mailchimp: include:servers.mcsv.net
  • SendGrid: include:sendgrid.net
  • Mailgun: include:mailgun.org

SPF 查詢上限與如何不超限

SPF 在評估時有 10 次 DNS 查詢的硬性上限。每個 include:、a 與 mx 機制都計為一次查詢。許多第三方 SPF 紀錄本身還會在內部觸發額外查詢。若您的紀錄總查詢超過 10 次,SPF 評估會回傳 PermError,並視為失敗。為維持在上限內,盡可能使用直接 IP 位址,並避免層層巢狀的 include。

SPF 搭配 DKIM 與 DMARC 效果最佳

單靠 SPF 只保護信封寄件者(Return-Path),不保護可見的 From 位址。若要完整防範仿冒,還需要 DKIM 為郵件簽章,以及 DMARC 將驗證結果與 From 標頭對齊。這三項標準共同構成 Gmail、Outlook 與 Yahoo Mail 所要求的電子郵件驗證基準。

設定 SPF 之後,也請確保您的名單是乾淨的。 電子郵件驗證 會在寄送前移除無效與高風險位址,有助壓低退信率,並保護您透過正確驗證建立的寄件者聲譽。您也可以透過 批量電子郵件驗證 批量驗證位址,或透過 電子郵件驗證 API直接整合進您的系統。

從實際寄件來源著手

SPF 紀錄產生器在建立正確政策前需要什麼

SPF 紀錄是信封寄件網域的授權清單。產生器可以格式化這份清單,但清單必須先完整盤點所有代表您網域寄信的系統。

新增機制前,先盤點所有寄件來源

列出您的工作區供應商、交易郵件服務、行銷平台、客服系統、CRM,以及任何在 MAIL FROM 或 HELO 中使用此網域的伺服器。漏列來源會造成誤判的 SPF 失敗;過時來源則會讓授權範圍過寬。

僅在該供應商確實為您寄信時,才使用其提供的 include 網域。不要複製其他公司的 SPF 紀錄,也不要只因機制看起來眼熟就加入。

在正確的寄件網域發佈一筆 SPF 政策

產生的值以 v=spf1 開頭,應放在一筆 DNS TXT 紀錄中。同一名稱下若有兩筆獨立的 v=spf1 紀錄,會造成永久評估錯誤;請將所有授權來源合併為單一政策。

SPF 是針對信封寄件網域評估,該網域可能是 return-path 子網域,而非可見的 From 網域。發佈前請先確認供應商實際使用的網域,不要假設應發在根網域。

機制與限定符

將產生的 SPF 紀錄視為一連串授權決策

每個機制回答郵件可從何處發出。最後的限定符說明收件方應如何分類未匹配任何機制的寄件者。

直接 IP 機制明確;include 則委外維護

ip4 與 ip6 授權指定位址或網段,無需額外 DNS 查詢。include 要求收件方評估另一個網域的 SPF 政策,讓供應商自行維護基礎架構,但會增加遞迴 DNS 負擔。

a 與 mx 機制授權從 DNS 解析出的位址。這樣很方便,但當這些紀錄服務於本無意寄信的系統時,政策範圍也會被擴大。

all 限定符是政策邊界,不是送達率開關

~all 將未匹配來源標為 softfail,-all 則標為 fail。這兩種指令都不會強制每個收件方投遞或拒收郵件;收件方會結合 SPF、DKIM、DMARC、聲譽、內容與本地政策一併判斷。

不要發佈 +all。它會授權網際網路上的所有來源,使 SPF 紀錄應提供的保護完全失效。

安全發佈

如何使用此免費 SPF 紀錄產生器,且不中斷合法郵件

將產生視為草稿步驟。驗證與觀察才算完成變更。

  1. 1

    依寄件來源盤點產生一筆紀錄

    加入每個必要的 IP 位址與供應商 include,移除重複項,上線時選擇較謹慎的限定符,並複製完整 TXT 值,不要帶入智慧引號或換行。

  2. 2

    在 DNS 發佈並等待適用的 TTL

    在信封寄件網域建立或取代 TXT 紀錄。各 DNS 控制台顯示主機名稱的方式不同,請確認供應商要的是 @、裸網域,還是僅子網域標籤。

  3. 3

    執行 SPF 檢查器並檢視實際郵件標頭

    使用 SPF 檢查器 確認公開 DNS 回傳一筆可解析的政策。接著透過每個合法平台寄信,並在收緊限定符之前檢查 Authentication-Results。

  4. 4

    新增或停用寄件來源時重新檢查

    SPF 是營運設定,不是設完就忘的徽章。當供應商、退回路徑、IP 範圍或郵件架構變更時,請更新紀錄,並移除不再需要的授權。

產生器無法證明的事

SPF 紀錄產生器只格式化政策,不會驗證整套寄件系統

請清楚這些界線,避免把語法正確的紀錄誤當成完整的電子郵件驗證。

產生的紀錄不會自動通過檢查

此工具無法得知是否已揭露所有來源、巢狀 include 是否仍有效,或紀錄是否發佈在實際郵件使用的身分上。仍需進行公開 DNS 與郵件標頭測試。

SPF 評估有 10 次查詢上限

include、a、mx、exists、redirect 及其遞迴相依都會消耗 DNS 查詢。看起來很短的政策,在評估巢狀供應商紀錄後仍可能超限並回傳 permerror。

SPF 不會為郵件內容簽章,也無法單獨保護可見的 From 網域

轉寄也可能破壞 SPF,因為連線 IP 會改變。請加入 DKIM 以簽署郵件,並加入 DMARC 以處理可見網域對齊與收件方政策。

驗證無法清理收件者名單

完美的 SPF 結果無法說明收件信箱是否存在。寄送前請使用 電子郵件驗證器,將寄件者驗證與收件者驗證分開。

權威參考

SPF 語法與評估來自 RFC 7208

本產生器遵循 SPF 標準用語,並將相關檢查放在獨立工具中。

RFC 7208 定義 SPF 第 1 版

IETF 的 RFC 7208 定義了 TXT 發佈、機制、修飾符、限定符、遞迴評估與處理上限。當供應商說明與一般設定建議衝突時,以標準為準。

常見問題

1. SPF 的全名是什麼?為什麼重要?

SPF 全名為 Sender Policy Framework。這是一種以 DNS 為基礎的電子郵件驗證方法,讓網域擁有者指定哪些郵件伺服器可代表其寄信。沒有 SPF,任何伺服器都能聲稱來自您的網域寄信,釣魚攻擊變得輕而易舉。ISP 與垃圾郵件過濾器會將 SPF 結果作為決定是否投遞郵件的主要信任訊號。

2. 如何發佈 SPF 紀錄?

使用此工具產生 SPF 紀錄,然後登入您的 DNS 供應商,在網域根(通常以 @ 或裸網域表示)新增一筆 TXT 紀錄,並填入產生的值。變更通常在 30 分鐘內傳播,全球最多可能需要 48 小時。

3. ~all 與 -all 有何差異?

~all(softfail)告訴收件伺服器,來自未列出 IP 的郵件可疑但仍應接受。-all(hardfail)指示伺服器拒收或重罰未列出的寄件者。首次設定 SPF 時使用 ~all,確認所有寄件服務都已列入後,再改為 -all。

4. 同一個網域可以有多筆 SPF 紀錄嗎?

不行。一個網域必須恰好有一筆 SPF 紀錄。若同一網域存在兩筆以 v=spf1 開頭的 TXT 紀錄,SPF 評估會產生永久錯誤,導致所有郵件無法通過 SPF 檢查。請將所有機制合併為單一紀錄。

5. 一筆 SPF 紀錄允許多少次 DNS 查詢?

SPF 將每次評估中會查詢 DNS 的機制(include、a、mx、ptr、exists)總數限制為 10 次。超過此上限會產生 permerror。請仔細計算 include 數量——許多供應商會串連多層巢狀 include,每一層都計入您的上限。

6. 單靠 SPF 能防止電子郵件仿冒嗎?

SPF 只驗證信封寄件者(MAIL FROM)位址,不驗證顯示給收件者的可見 From 標頭。即使 SPF 通過,攻擊者仍可偽造 From 標頭。若要徹底防止收件匣中可見的網域仿冒,需要同時與 SPF、DKIM 對齊的 DMARC 政策。

下一步

驗證並清理您的電子郵件名單

完善的驗證紀錄可保護您的網域。BillionVerify 以 99.9% 準確度的電子郵件驗證,維持名單健康。

每月 600 點免費積分,登入再送 20 點/天 · 99.9% SMTP 準確率 · 即時 API 存取 · 無需信用卡

99.9%
準確率
Real-time
API 速度
$0.00014
每封郵件
600/mo
永久免費