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

SPF 紀錄產生器

這款免費 SPF 紀錄產生器可為您的網域建立有效的 v=spf1 TXT 紀錄。新增 IP 與供應商、選擇 SPF 政策,再複製 SPF 紀錄。無需註冊,一般 SPF 使用情境下不限次數。

產生您的 SPF 紀錄

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

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

SPF 紀錄產生器會產生什麼

SPF 紀錄是一筆 TXT 紀錄,列出獲准以您的網域作為信封寄件者寄信的所有來源。這款免費 SPF 紀錄產生器會將該清單轉為收件伺服器要求的精確語法,您不必親手編寫一年可能只用兩次的規則。

收件伺服器會在投遞時讀取 SPF 紀錄,將連線 IP 與紀錄比對,並套用您選擇的限定符。SPF 紀錄產生器會按慣用順序輸出各項機制,並確保紀錄不超過 10 次 DNS 查詢上限。

產生器輸出的 SPF 紀錄語法

了解產生器可輸出的每種 SPF 機制,以及各機制在 SPF 紀錄中授權的內容。

  • 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

如何選擇 all 限定符

最後一項 SPF 機制決定如何處理 SPF 紀錄未列出的所有來源。SPF 紀錄產生器無需註冊,您可在調整期間隨時重新建立紀錄。

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

常見供應商 include

若您透過這些供應商寄信,請將對應的 SPF include 貼到產生器中;每一項都會增加自身的 SPF 查詢次數。

  • 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

10 次查詢上限

SPF 評估期間,每項 include:、a、mx、ptr 和 exists: 機制都會消耗一次 DNS 查詢;RFC 7208 將總數限制為 10 次。超出後,收件伺服器會回傳 permerror,許多伺服器會將其視為完全沒有 SPF。我們的 SPF 紀錄產生器會維持扁平的 SPF 輸出,並在紀錄突破上限前發出警告。

SPF 搭配 DKIM 與 DMARC 效果最佳

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

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

紀錄表達的內容

SPF 紀錄產生器實際建立的內容

SPF 紀錄是一段 TXT 字串,列出獲准以您的網域作為信封寄件者寄信的所有來源。免費 SPF 紀錄產生器會將這項政策決定轉為正確語法,您不必記住整套規則。

紀錄是政策,不是過濾器

SPF 本身不會封鎖任何郵件。您發佈的紀錄會告訴收件伺服器哪些 IP 和供應商已獲授權,而郵件來自其他來源時,各收件方會自行決定如何處理。

因此,SPF 紀錄產生器會詢問兩件事:合法郵件來自哪裡,以及您希望多嚴格地處理未授權來源。

機制描述已獲授權的寄件者

ip4 和 ip6 用於授權您控制的特定位址或 CIDR 網段。include: 會委派給供應商自己的 SPF 紀錄,因此 Google、Microsoft、Mailchimp、SendGrid 和 Mailgun 變更基礎設施後仍能維持正確設定。

a 和 mx 會授權您網域自身 A 或 MX 紀錄指向的位址。SPF 紀錄產生器會按慣用順序輸出這些機制,讓常見情況更早完成評估。

all 限定符決定整項政策

-all 表示硬失敗:未列出的所有來源均未獲授權。~all 表示軟失敗,通常會被視為可疑,而非直接拒收。?all 表示中立,不執行任何限制。

免費 SPF 紀錄產生器若預設直接使用 -all,並不會幫到您。先發佈 ~all,觀察哪些郵件失敗,再收緊政策。產生器刻意提供全部三種選項。

10 次 DNS 查詢是硬性上限

每項 include:、a、mx、ptr 和 exists: 機制都會消耗一次 DNS 查詢,SPF 規範將評估上限設為 10 次。超出後,收件伺服器會回傳 permerror — 許多伺服器會將其視為完全沒有 SPF。

這是手寫紀錄悄然失效最常見的原因。SPF 紀錄產生器會維持扁平的輸出,並在紀錄長到可能引發問題前發出警告。

解讀您的紀錄

產生的 SPF 紀錄各部分代表什麼

輸出結果很短,可以從頭讀到尾。了解每個標記的作用,日後編輯時才不會破壞郵件投遞。

v=spf1 — 版本標記

每筆 SPF 紀錄都以它開頭;沒有它的 TXT 紀錄根本不算 SPF 紀錄。每個網域只能有一筆 SPF 紀錄;發佈兩筆會產生 permerror,而不會自動合併。

若 SPF 紀錄產生器的輸出要取代現有紀錄,請手動合併其中的機制,不要同時發佈兩筆紀錄。

include: — 委派給供應商

include:_spf.google.com 會匯入 Google 目前授權的所有來源。您會自動承接其變更,同時這些 DNS 查詢也會占用您的 10 次查詢額度。

只 include 確實以您的網域寄信的供應商。每個未使用的 include 都是在白白消耗查詢額度。

ip4 / ip6 — 您自己的基礎設施

將這些機制用於您自行運行的郵件伺服器。它們不消耗 DNS 查詢,因此在寄件來源較多時,是維持在上限內成本最低的方式。

支援 CIDR 表示法,因此整個網段可寫成一項機制,不必逐一列出位址。

~all 或 -all — 如何處理其他來源

最後一項機制是收件方最常依據的規則。先使用 ~all,確認所有合法來源都已列出;連續一週的報告都無異常後,再改為 -all。

若網域仍有被遺忘的寄件者,直接使用 -all 是遺失真實郵件最快的方式。

發佈紀錄

從免費 SPF 紀錄產生器到線上 DNS 紀錄

只需四個步驟,而大多數人會在第三步過早停止。

  1. 1

    產生前列出所有寄件者

    行銷平台、交易郵件供應商、CRM、客服系統、開票系統,以及多年無人維護的辦公室郵件伺服器。任何以您的網域寄信的系統都應寫入紀錄。

    請在取得完整清單後再執行免費 SPF 紀錄產生器。只依半份清單產生的紀錄會讓另一半失效。

  2. 2

    在網域根目錄發佈一筆 TXT 紀錄

    主機填寫 @ 或裸網域,類型選擇 TXT,值填寫產生的字串。傳播通常只需幾分鐘,偶爾需要一小時。

    不要將它發佈為 SPF 類型的紀錄 — 該紀錄類型早已棄用,收件伺服器會忽略它。

  3. 3

    驗證實際解析結果

    DNS 供應商會以出人意料的方式換行、拆分和截斷較長的 TXT 值。傳播完成後,請使用 SPF 檢查器,因為免費 SPF 紀錄產生器的輸出與 DNS 實際提供的字串不一定相同。

    紀錄在 DNS 控制台中看似正確、實際解析卻錯誤,是一種常見故障;只有主動查詢才能發現。

  4. 4

    確認無誤後再收緊政策

    連續一週沒有合法郵件失敗後,將 ~all 改為 -all 並重新發佈。此時 SPF 才真正開始保護網域。

    每當新增或移除寄件供應商時,請重新執行 SPF 紀錄產生器,不要直接在 DNS 控制台中編輯線上字串。

限制

SPF 無法做到什麼

SPF 是三種寄件者驗證紀錄之一。誤以為它能代替另外兩種紀錄,正是多數設定錯誤的起點。

郵件轉寄會導致 SPF 失效

郵件轉寄後,信封寄件者仍是您的網域,但投遞 IP 會變成轉寄方的位址。因此,即使郵件完全合法,SPF 也會依規則判定失敗。

這正是 DKIM 存在的原因,也是 DMARC 會接受 SPF 或 DKIM 任一項對齊並通過的原因。

SPF 不檢查可見的 From 位址

SPF 授權的是收件者看不到的信封寄件者。郵件可以通過 SPF,同時顯示任意 From 位址。

只有 DMARC 能將可見網域與已驗證網域連結。單獨使用 SPF 無法阻止使用者能察覺的仿冒。

SPF 不驗證收件者

發佈一筆完美的紀錄,並不能說明您寄信的電子郵件地址是否存在。寄件者驗證與收件者驗證是兩個不同的問題。

若要驗證收件者,請使用 電子郵件驗證器 或在行銷活動前進行批量驗證,並將兩者視為同一寄件流程中彼此獨立的環節。

SPF 無法修復寄件者信譽

正確的 SPF 紀錄是良好投遞率的必要條件,而不是成因。內容、投訴率和退信率仍會決定郵件能否進入收件匣。

先確保紀錄正確,再處理其他問題。

參考資料與後續步驟

規範與相關工具

SPF 由 IETF 定義,而這款 SPF 紀錄產生器周邊的工具可完成它無法執行的檢查。

RFC 7208 定義語法

IETF 的 RFC 7208 定義 SPF、相關機制、限定符,以及這款 SPF 紀錄產生器會協助您遵守的 10 次查詢評估上限。

發佈紀錄不要求閱讀該規範,但遇到限定符含義的爭議時,它能給出最終答案。

檢查您發佈的紀錄

發佈後,使用 SPF 檢查器 解析線上紀錄,並回報查詢次數、語法錯誤和實際生效的政策。

在這裡產生,再到那裡驗證 — 兩者搭配可發現產生器無法看到的 DNS 控制台格式問題。

完成整套驗證設定

SPF 只是完整驗證體系的三分之一。 DMARC 產生器 和 DKIM 工具負責網域對齊與郵件簽章。

網域設定 SPF 但未設定 DMARC 時,雖然已通過驗證,可見的 From 欄位仍可能遭到仿冒。

常見問題

1. 免費 SPF 紀錄產生器真的免費嗎?

是的 — 這款 SPF 紀錄產生器無需註冊、無需帳戶,也不限制建立 SPF 紀錄的數量。SPF 邏輯完全在頁面內執行,不會儲存您的網域或 SPF 設定資訊。

2. SPF 紀錄產生器產生的紀錄應發佈到哪裡?

請將它作為 TXT 紀錄發佈在網域根目錄:主機填寫 @ 或裸網域,類型選擇 TXT,值填寫產生的字串。請勿使用已棄用的 SPF 紀錄類型 — 收件伺服器會忽略它。傳播通常只需幾分鐘。

3. 可以設定兩筆 SPF 紀錄嗎?

不可以。每個網域只能有一筆 SPF 紀錄。發佈兩筆紀錄會產生 permerror,收件伺服器不會自動合併。若已有紀錄,請將其中的機制合併到 SPF 紀錄產生器的輸入中,不要發佈第二筆。

4. 應該使用 ~all 還是 -all?

先使用 ~all。它會將未授權郵件標為可疑,但不會拒收,讓您有一週時間找出被遺漏的寄件來源。確認所有合法郵件都未失敗後,再改為 -all。免費 SPF 紀錄產生器若預設直接使用 -all,可能讓您失去真實郵件。

5. 紀錄發佈後可能因什麼失效?

主要有兩種情況:持續新增供應商 include,導致 DNS 查詢超過 10 次;或 DNS 控制台拆分、截斷過長的 TXT 值。供應商變更後,請重新執行免費 SPF 紀錄產生器,再用 SPF 檢查器驗證線上紀錄。

6. SPF 紀錄能阻止仿冒嗎?

單靠 SPF 不能。SPF 授權的是無人可見的信封寄件者。只有 DMARC 能將可見的 From 網域與已驗證網域連結,因此應將 SPF 視為三個步驟中的第一步:SPF、DKIM、DMARC。

SPF 紀錄產生器

立即建立您的 SPF 紀錄

SPF 紀錄產生器無需註冊 — 建立並發佈 SPF 紀錄,接著驗證線上紀錄,並檢查您實際要寄信的電子郵件地址。

SPF 紀錄產生器無需註冊 · 99.9% SMTP 準確率 · 即時 API 存取 · 無需信用卡

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