設定SPF以識別 Microsoft 365 網域的有效電子郵件來源

提示

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

發件人原則架構 (SPF) 是 一種電子郵件驗證 方法，可協助驗證從 Microsoft 365 組織傳送的郵件，以防止商務電子郵件遭詐騙的發件者入侵 (BEC) 、勒索軟體和其他網路釣魚攻擊。

SPF 的主要目的是驗證網域的電子郵件來源。 具體而言，SPF 會使用 DNS 中的 TXT 記錄來識別網域的有效郵件來源。 接收電子郵件系統會使用 SPF TXT 記錄來確認郵件傳輸期間所使用寄件者地址的電子郵件 (稱為郵件發件者地址、 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：

  • 如果您只使用電子郵件 (的 Microsoft Online Email 路由位址 (MOERA) 網域，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記錄。

        提示

        Email DMARC 涵蓋未定義子域的驗證保護。 任何 (定義或未定義的子域) 繼承父域 (的 DMARC 設定，這些設定可在每個子域) 覆寫。 如需詳細資訊， 請參閱設定 DMARC 以驗證 Microsoft 365 中寄件者的寄件者發件者網域。

    • 如果您擁有已註冊但未使用的網域：如果您擁有未用於電子郵件或任何 (也稱為 已停 駐網域) 的已註冊網域，請設定 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 TX 記錄基本語法為：

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 記錄。 其他第三方電子郵件服務通常需要額外的 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 混合式部署) 。 某些第三方電子郵件服務可能也會使用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 資料夾，或傳遞至 [收件匣]，並將標識元新增至主旨或郵件本文。

      因為我們也建議 Microsoft 365 網域使用 DKIM 和 DMARC，所以 (硬性故障) 與 ~all (軟性失敗) 之間的-all差異會有效地消除， (DMARC 會將任一結果視為 SPF 失敗) 。 DMARC 會使用SPF來確認MAIL FROM和From位址中的網域對齊， 且 訊息來自From網域的有效來源。

    提示

    ?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 中使用 contoso.com 電子郵件，而 Microsoft 365 是來自 contoso.com 的唯一電子郵件來源。

    Microsoft 365 和 Microsoft 365 Government Community Cloud (GCC) 中 contoso.com 的 SPF TXT 記錄 ：

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

    Microsoft 365 Government Community Cloud High (GCC High) 和 Microsoft 365 美國國防部 (DoD) 中 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

  • 案例：您在 Microsoft 365 中使用 contoso.com 電子郵件，而且您已在 contoso.com 中設定 SPF TXT 記錄，其中包含來自網域的所有電子郵件來源。 您也擁有網域 contoso.net 和 contoso.org，但不會將它們用於電子郵件。 您要指定沒有人有權從 contoso.net 或 contoso.org 傳送電子郵件。

    適用於 contoso.net 的 SPF TXT 記錄：

    v=spf1 -all

    contoso.org 的 SPF TXT 記錄：

    v=spf1 -all

  • 案例：您在 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 記錄。

  • 少於 10 個 DNS 查閱：當目的地電子郵件系統查詢 SPF TXT 記錄中是否有 MAIL FROM 位址網域的有效來源時，查詢會掃描記錄中的 IP 位址和 include: 語句，直到訊息來源最終 (為止，IP 位址) 符合其中一個指定的來源。 如果 DNS 查閱 (的數目可能與 DNS 查詢 數目不同，) 大於 10，則訊息會失敗 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密封器。