SPF

SPF記錄解釋

一條TXT記錄定義了誰可以作為您發送。

[快速解答]

SPF記錄是網域中的單一TXT記錄,以v=spf1,使用include:, ip4: 和ip6:,等機制列出授權寄件人,並以 all 限定詞結尾。範例: v=spf1 include:_spf.google.com ip4:203.0.113.10 -all 。

主要事實

  • ›機制:ip4、ip6、a、mx、include、exists;修飾符:重定向。
  • ›限定符:+ 通過、~ softfail 、- 失敗、?中性的。
  • ›將DNS查找次數控制在 10 次以內,每個字串的字元數控制在 255 個以內。
  • ›避免 ptr 和+all 。

由EmailAuth研究團隊審核

SPF記錄是單一DNS TXT記錄,其中列出了授權為您的網域發送電子郵件的每個伺服器和服務。它以版本標記v=spf1,包含一系列定義授權來源的機制,並以未列出的任何內容設定預設答案的 all 機制結束。接收郵件伺服器讀取此記錄來決定是否允許連線伺服器作為您的網域傳送郵件。

SPF記錄範例

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

機制解釋

每種機制都描述了一種授權發送者的方法。接收者從左到右評估它們,並在第一個匹配處停止。某些機制會觸發DNS查找併計入RFC 7208設定的 10 次查找限制。

  • include:提取另一個網域的SPF記錄,這對於_spf.google.com等供應商來說很常見,並算作尋找。
  • ip4:授權特定的IPv4位址或範圍,無需DNS查找成本。
  • ip6:授權特定的IPv6位址或範圍,無DNS查找成本。
  • a:對域A記錄中的IP進行授權,並算作一次查找。
  • mx:對網域的MX記錄中的郵件伺服器進行授權,並算作尋找。
  • all:最後的-all ,決定未列出的來源會發生什麼事。

硬失敗與softfail : -all和~all

所有前面的限定符會改變您的記錄的嚴格程度。使用-all (hardfail) 告訴接收者任何未列出的伺服器均未獲得授權,並且應拒絕該訊息或將其視為失敗。使用~all ( softfail ) 表示未列出的伺服器可能未授權,但應接受並標記,這在測試時很有用。一旦您確信每個合法寄件者都被包括在內,硬失敗就是更強大的立場。避免+all ,這會授權每個人並達不到目的。

測試時出現軟故障

從~all開始觀察結果而不阻止郵件,然後在確認每個寄件者後轉到-all 。

一筆記錄,看你的查找

一個網域必須恰好發布一筆SPF記錄。兩個SPF TXT記錄會導致permerror 。當您新增供應商時,每個供應商都會擴展到進一步的查找,並且流行的服務會快速堆積。當您進行 10 次查找時,合法郵件的記錄會默默失敗。 EmailAuth SmartSPF將您的包含鏈扁平化為一項最佳化記錄,並自動同步Microsoft 365 、 Google Workspace 、 Salesforce和SendGrid的供應商 IP 範圍。免費的網域掃描顯示您目前的機制和查找計數。將SPF與DKIM和DMARC配對,這樣即使在轉寄郵件時也能保持對齊。

常見問題

SPF記錄中的-all和~all有什麼差別?

-all是一個硬故障,告訴接收者拒絕或失敗記錄中未列出的任何伺服器。 ~all是一個softfail ,它接受未列出的發件人,但將其標記為可疑。測試時使用~all ,一旦包含了每個合法寄件人,就使用-all 。

我可以有多個SPF記錄嗎?

不可以。一個網域必須恰好發布一筆SPF TXT記錄。兩個或多個SPF記錄會導致permerror並中斷身份驗證。將所有來源合併到以v=spf1.

ip4 和 ip6 機制是否計入 10 次查找限制?

不會。 ip4和ip6直接授權位址,不需要DNS解析,因此不消耗查找。 include、a、mx、ptr 和exists 等機制確實計入 10 的限制。

include機制有什麼作用?

包含機制會匯入另一個網域的SPF記錄,這就是您授權給Google Workspace或SendGrid等第三方寄件者的方式。每個包含至少算一次DNS查找,並且其中的任何嵌套包含都會添加更多。

如何查看我的SPF記錄?

使用SPF檢查器。它會取得記錄、擴展每個包含項並根據 10 次限制對DNS查找進行計數。

如何合併SPF記錄?

將兩個記錄的機制合併為一個v=spf1記錄,並在末尾保留一個 all。

我應該使用~all還是-all ?

在確認每個寄件者時使用~all ,然後-all 。當DMARC處於p=reject,任一方法都有效,因為DMARC做出最終決定。

[ SPF 指導 ]

知識庫的一部分SPF · 55 指南

企業出處

為什麼頂級金融機構和政府 退役了他們的電子郵件安全儀表板。

傳統的電子郵件驗證平台會向您出售儀表板並要求您的工程師來完成這項工作。在高風險環境中,手動監督意味著延遲執行、配置漂移和不受監控的影子域。

EmailAuth是代理電子郵件來源平台。 我們的代理人強制執行 p=reject,保持第三方寄件者一致並將您的網域移至完整狀態 RFC 9989 合規性、新的DMARC標準,以及人機互動審核能力。

政府 大型企業 一級金融機構

SaaS · 專用租賃 · 氣隙本地部署 · BYOK 加密

請參閱您自己的網域上的EmailAuth

開始為期 14 天的概念驗證。我们绘制每个发件人的地图,量化您的暴露程度,并为您提供全面执行的安全途径。