設定 SPF 以識別自訂雲端網域的有效電子郵件來源

適用於: ✅ Built-in security features for all cloud mailboxes, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

提示

您是否知道您可以免費試用適用於 Office 365 的 Microsoft Defender 方案 2 中的功能？ 在 Microsoft Defender 入口網站試用中樞使用 90 天適用於 Office 365 的 Defender 試用版。瞭解誰可以在試用適用於 Office 365 的 Microsoft Defender 上註冊和試用條款。

SPF) (Sender Policy Framework 是一種電子郵件驗證方法，可協助驗證從 Microsoft 365 組織傳送的郵件，以防止詐騙寄件者用於商業電子郵件入侵 (BEC) 、勒索軟體和其他網路釣魚攻擊。

SPF 的主要目的是驗證網域的電子郵件來源。具體來說，SPF 使用 DNS 中的 TXT 記錄來識別網域的有效郵件來源。接收電子郵件系統會使用 SPF TXT 記錄來驗證來自郵件 SMTP 傳輸期間使用的寄件者位址的電子郵件 (稱為 MAIL FROM 位址、位址、 5321.MailFrom P1 寄件者或信封寄件者) ，是否來自該網域的已知指定郵件來源。

例如，如果您在 Microsoft 365 中的電子郵件網域是 contoso.com，您可以在 DNS 中為 contoso.com 網域建立 SPF TXT 記錄，以將 Microsoft 365 識別為來自 contoso.com 的授權郵件來源。目的地電子郵件系統會檢查 contoso.com 中的 SPF TXT 記錄，以判斷郵件是否來自 contoso.com 電子郵件的授權來源。

在開始之前，以下是您需要了解的有關 Microsoft 365 中基於您的電子郵件域的 SPF 的信息：

例如，如果您僅使用 MOERA) 域 (Microsoft Online Email Routing Address 進行電子郵件 (，則 contoso.onmicrosoft.com) ：您無需執行任何操作。 SPF TXT 記錄已為您設定。 Microsoft 擁有 onmicrosoft.com 網域，因此我們負責在該網域和子網域中建立和維護 DNS 記錄。如需 *.onmicrosoft.com 網域的詳細資訊，請參閱為什麼我有「onmicrosoft.com」網域？。
如果您使用一或多個自訂網域進行電子郵件 (例如，contoso.com) ：Microsoft 365 註冊程序已要求您在 DNS 中建立或修改自訂網域的 SPF TXT 記錄，才能將 Microsoft 365 識別為授權的郵件來源。但是，為了最大限度地保護電子郵件，您還有更多工作要做：
- 子網域考量事項：
  - 對於不受您直接控制 (電子郵件服務) 的電子郵件服務，我們建議您使用子網域 (例如 marketing.contoso.com) ，而不是您的主要電子郵件網域 (例如 contoso.com) 。您不希望從這些電子郵件服務傳送的郵件發生問題，影響您主要電子郵件網域中員工所傳送郵件的信譽。如需新增子網域的詳細資訊，請參閱我可以將自訂子網域或多個網域新增至 Microsoft 365 嗎？。
  - 您用來從 Microsoft 365 傳送電子郵件的每個子網域都需要自己的 SPF TXT 記錄。例如，contoso.com 的 SPF TXT 記錄不涵蓋 marketing.contoso.com;marketing.contoso.com 需要自己的 SPF TXT 記錄。
    
    提示
    
    DMARC 涵蓋未定義子網域的 Email 驗證保護。任何 (定義或未定義的子網域) 繼承父網域 (的 DMARC 設定，每個子網域) 都可以覆寫。如需詳細資訊，請參閱設定 DMARC 以驗證雲端寄件者的寄件者地址網域。
- 如果您擁有已註冊但未使用的網域：如果您擁有未用於電子郵件或任何內容的已註冊網域 (也稱為 駐留網域) ，請設定 SPF TXT 記錄，以指出任何電子郵件都不應來自這些網域，如本文稍後所述。
僅靠 SPF 是不夠的。為了為您的自訂網域提供最佳層級的電子郵件保護，您還需要將 DKIM 和 DMARC 設定為整體電子郵件驗證策略的一部分。如需詳細資訊，請參閱本文結尾的後續步驟一節。

重要事項

在複雜的組織中，難以識別網域的所有有效郵件來源，請務必在網域) 「不採取任何動作」模式下快速設定 DKIM 簽署和 DMARC (。 DMARC 報告服務對於識別網域的電子郵件來源和 SPF 故障非常有幫助。

本文的其餘部分說明您需要在 Microsoft 365 中為自訂網域建立的 SPF TXT 記錄。

提示

Microsoft 365 中沒有系統管理入口網站或 PowerShell Cmdlet 可供您管理網域中的 SPF 記錄。相反地，您可以在網域註冊商或 DNS 託管服務處建立 SPF TXT 記錄， (通常是相同的公司) 。

我們提供指示，以在許多網域註冊商建立 Microsoft 365 的網域擁有權證明 TXT 記錄。您可以使用這些指示作為建立 SPF TXT 記錄值的起點。如需詳細資訊，請參閱新增 DNS 記錄以連線您的網域。

如果您不熟悉 DNS 設定，請聯絡您的網域註冊商並尋求協助。

SPF TXT 記錄的語法

RFC 7208 中詳盡地描述了 SPF TXT 記錄。

Microsoft 365 中自訂網域的 SPF TXT 記錄基本語法為：

v=spf1 <valid mail sources> <enforcement rule>

或者：

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName1>... include:<DomainNameN>] <-all | ~all>

例如：

v=spf1 ip4:192.168.0.10 ip4:192.168.0.12 include:spf.protection.outlook.com -all

v=spf1 將 TXT 記錄識別為 SPF TXT 記錄。
有效的郵件來源：為網域指定有效的郵件來源。使用網域、 IP 位址或兩者：
- 網域： include: 值會指定其他服務或網域作為原始網域郵件的有效來源。這些值最終會導致使用 DNS 查找的 IP 地址。
  
  大部分的 Microsoft 365 組織都需要 include:spf.protection.outlook.com 網域的 SPF TXT 記錄。其他非 Microsoft 電子郵件服務通常需要額外的 include: 值，才能將服務識別為原始網域的有效電子郵件來源。
- IP 位址：IP 位址值包含下列兩個元素：
  - 值 ip4: 或 ip6: 來識別 IP 位址的類型。
  - 來源電子郵件系統的可公開解析 IP 位址。例如：
    - 例如，個別 IP 位址 (192.168.0.10) 。
    - 使用無類別 Inter-Domain 路由 (CIDR) 表示法 (的 IP 位址範圍，例如 192.168.0.1/26) 。確保範圍不會太大或太小。
  在 Microsoft 365 中，只有當您有從 Microsoft 365 網域傳送郵件的內部部署電子郵件伺服器時，您通常才會在 SPF TXT 記錄中使用 IP 位址 (例如，Exchange Server混合式部署) 。某些非 Microsoft 電子郵件服務也可能使用 IP 位址範圍，而不是 include: SPF TXT 記錄中的值。
強制執行規則：告知目的地電子郵件系統如何處理來自網域 SPF TXT 記錄中未指定之來源的郵件。有效值為：
- -all (硬失敗) ：SPF TXT 記錄中未指定的來源未獲授權傳送網域的郵件，因此應拒絕郵件。郵件的實際情況取決於目的地電子郵件系統，但郵件通常會被丟棄。
  
  對於 Microsoft 365 網域，我們建議 -all (硬失敗) ，因為我們也建議網域使用 DKIM 和 DMARC。 DMARC 原則會指定如何處理未通過 SPF 或 DKIM 的郵件，而 DMARC 報告可讓您驗證結果。
  
  提示
  
  如前所述，配置了 DMARC 報告服務的 DMARC 極大地有助於識別域的電子郵件來源和 SPF 故障。
- ~all (軟失敗) ：SPF TXT 記錄中未指定的來源可能未獲授權傳送網域的郵件，因此應該接受但標示郵件。郵件的實際情況取決於目的地電子郵件系統。例如，郵件可能會被隔離為垃圾郵件、傳遞至 [垃圾郵件Email] 資料夾，或傳遞至 [收件匣]，並將識別碼新增至 [主旨] 或 [郵件內文]。
  
  注意事項
  
  DMARC 將 -all (硬故障) 和 ~all (軟故障) 視為 SPF 故障。但是，如果郵件不包含 DKIM 簽名，則 SPF ~all 失敗實際上會忽略 DMARC 政策。建議 -all DMARC 在郵件也缺少 DKIM 簽章時，可以對未通過 SPF 的郵件採取行動。
- ?all (中立) ：建議對來自不明來源的郵件不採取具體行動。此值用於測試，我們不建議在生產環境中使用此值。

要記住的要點：

DNS 中每個定義的網域或子網域都需要一個 SPF TXT 記錄，而且每個網域或子網域只允許一個 SPF 記錄。 未定義子網域的 Email 驗證保護最好由 DMARC 處理。
您無法修改 *.onmicrosoft.com 網域的現有 SPF TXT 記錄。
當目的地電子郵件系統檢查 SPF 記錄中的有效電子郵件來源時，如果檢查需要太多 DNS 查詢，則 SPF 驗證會失敗。如需詳細資訊，請參閱本文稍後的 SPF TXT 記錄疑難排解一節。

Microsoft 365 中自訂網域的 SPF TXT 記錄

提示

如本文先前所述，您可以在網域的網域註冊商處建立網域或子網域的 SPF TXT 記錄。 Microsoft 365 中沒有可用的 SPF TXT 記錄設定。

案例：僅限 Microsoft 365 電子郵件

您在 Microsoft 365 中使用 contoso.com 進行電子郵件，而 Microsoft 365 是來自 contoso.com 的唯一電子郵件來源

Microsoft 365 和 Microsoft 365 政府社群雲端 (GCC) 中 contoso.com 的 SPF TXT 記錄 ：
```
v=spf1 include:spf.protection.outlook.com -all
```
Microsoft 365 政府社區、雲高 (GCC 高) 和 Microsoft 365 國防部 (國防部) 中 contoso.com 的 SPF TXT 記錄 ：
```
v=spf1 include:spf.protection.office365.us -all
```
由世紀互聯提供的 Microsoft 365 年 contoso.com 的 SPF TXT 記錄：
```
v=spf1 include:spf.protection.partner.outlook.cn -all
```

案例：駐留網域

您擁有 contoso.net 和 contoso.org 網域，但不會將它們用於電子郵件。您想要指定沒有人有權從 contoso.net 或 contoso.org 傳送電子郵件。

contoso.net 的 SPF TXT 記錄：
```
v=spf1 -all
```
contoso.org 的 SPF TXT 記錄：
```
v=spf1 -all
```

注意事項

如本文前面所述，每個子域都需要自己的 SPF TXT 記錄。對於駐留網域，幾乎不可能猜測可能需要哪些子網域。如果網域註冊商支援萬用字元記錄，您可以使用下列語法來指定沒有人有權從駐留網域的任何子網域傳送電子郵件：

Hostname： _*.contoso.net 或 _*.contoso.org
TXT 值： v=spf1 -all

案例：具有內部部署電子郵件和非 Microsoft 電子郵件服務的 Microsoft 365 電子郵件

您在 Microsoft 365 中使用電子郵件 contoso.com。您計劃從下列來源傳送郵件：

外部電子郵件地址為 192.168.0.10 的內部部署電子郵件伺服器。由於您可以直接控制此電子郵件來源，因此我們認為可以將伺服器用於 contoso.com 網域中的寄件者。
Adatum 大量郵件服務。由於您無法直接控制此電子郵件來源，因此建議您使用子網域，以便為此目的建立 marketing.contoso.com。根據 Adatum 服務檔，您必須新增至 include:servers.adatum.com 網域的 SPF TXT 記錄。

contoso.com 的 SPF TXT 記錄：
```
v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all
```
marketing.contoso.com 的 SPF TXT 記錄：
```
v=spf1 include:servers.adatum.com include:spf.protection.outlook.com -all
```

疑難排解 SPF TXT 記錄

每個網域或子網域一個 SPF 記錄：相同網域或子網域的多個 SPF TXT 記錄會導致 DNS 查詢迴圈，導致 SPF 失敗，因此每個網域或子網域只能使用一個 SPF 記錄。
TTL) (存留時間 ：我們建議 SPF TXT 記錄的最小 TTL 值為 3600 秒 (一小時) ，以避免 DNS 查找逾時。
少於 10 次 DNS 查詢：當目的地電子郵件系統查詢 SPF TXT 記錄以取得 MAIL FROM 位址網域的有效來源時，查詢會掃描記錄中的 IP 位址和 include: 陳述式，直到郵件來源最終 (IP 位址) 符合其中一個指定的來源。如果 DNS 查詢 (數可能與) 的 DNS 查詢數不同，則訊息會失敗 SPF，並出現永久錯誤 (也稱為 permerror) 。目的地電子郵件系統會拒絕未送達報告中的郵件 (也稱為 NDR 或 退回郵件) ，並出現下列其中一個錯誤：
- 郵件超過躍點計數。
- 郵件需要太多查閱。
在 SPF TXT 記錄中，個別 IP 位址或 IP 位址範圍不會導致 DNS 查閱。每個 include: 陳述式至少需要一個 DNS 查閱，如果值指向巢狀資源，則 include: 可能需要更多查閱。換句話說，少於 10 include: 個陳述式並不能保證少於 10 個 DNS 查詢。

另請記住：目的地電子郵件系統會從左到右評估 SPF TXT 記錄中的來源。當驗證訊息來源時，評估會停止，且不會再檢查任何來源。因此，SPF TXT 記錄可能包含足夠的資訊，導致超過 10 次 DNS 查詢，但某些目的地對某些郵件來源的驗證在記錄中不夠深入，無法導致錯誤。

除了維護主要電子郵件網域的信譽之外，不超過 DNS 查詢次數是將子網域用於您無法控制的其他電子郵件服務的另一個原因。

您可以使用免費的線上工具來查看網域的 SPF TXT 記錄和其他 DNS 記錄。有些工具甚至會計算您的 SPF TXT 記錄所需的 DNS 記錄查找次數。

後續步驟

如 SPF、DKIM 和 DMARC 如何共同運作來驗證電子郵件訊息寄件者中所述，SPF 本身不足以防止詐騙 Microsoft 365 網域。您還需要配置 DKIM 和 DMARC 以獲得最佳保護。如需詳細指示，請參閱：

對於進入 Microsoft 365 的郵件，如果您使用在傳遞至組織之前修改傳輸中郵件的服務，您可能也需要設定受信任的 ARC 密封器。如需詳細資訊，請參閱設定受信任的 ARC 密封器。

意見反應

此頁面對您有幫助嗎？

Last updated on 2025-09-19