使用 MTA-STS 增強郵件流程

  • 發行項

SMTP MTA 嚴格傳輸安全性 (MTA-STS) 標準的支援已新增到 Exchange Online。 標準是為了確保 TLS 一律用於電子郵件伺服器之間的連線。 它也提供傳送伺服器的方式，以驗證接收伺服器是否具有信任的憑證。 如果未提供 TLS 或憑證無效，寄件者會拒絕傳遞郵件。 這些新檢查可改善 SMTP 的整體安全性，並防範中間人攻擊。

MTA-STS 可以分成兩種案例: 輸入和輸出保護。 輸入保護涵蓋使用 MTA-STS Exchange Online 裝載的網域保護。 輸出保護涵蓋將電子郵件傳送至受 MTA-STS 保護的網域時，Exchange Online 所執行的 MTA-STS 驗證。

提示

如果您不是 E5 客戶，請使用 90 天的 Microsoft Purview 解決方案試用版來探索其他 Purview 功能如何協助貴組織管理數據安全性與合規性需求。 立即從 Microsoft Purview 合規性入口網站 試用中樞開始。 瞭解 有關註冊和試用版條款的詳細數據。

輸出保護

從 Exchange Online 傳送至受 MTA-STS 保護收件者的所有輸出訊息，都會使用 MTA-STS 標準所設定的這些額外安全性檢查進行驗證。 系統管理員不需要執行任何動作即可套用它。 我們的輸出執行會透過收件者網域擁有者的 MTA-STS 原則，尊重其願望。 MTA-STS 是 Exchange Online 安全性基礎結構的一部分，因此一律會像其他核心 SMTP 功能) 一樣開啟 (。

輸出 MTA-STS 可能會根據目的地網域的 MTA-STS 驗證結果，防止傳送電子郵件。 如果網域不安全，且 MTA-STS 原則設定為 [強制]，則 NDR 可能會傳回給傳送者，並包含下列其中一個錯誤碼：

錯誤碼 描述 可能的原因 其他資訊
5.4.8 '{domain}' 的 MX 主機 MTA-STS 驗證失敗 目的地 MX 主機不是每個網域 STS 原則的預期主機。 此錯誤通常表示目的地網域的 MTA-STS 原則未包含 MX 主機的問題。 如需 MTA-STS 的詳細資訊，請參閱 https://datatracker.ietf.org/doc/html/rfc8461。
5.7.5 遠程憑證的 MTA-STS 驗證失敗。 原因： {validityStatus} 目的地郵件伺服器的憑證必須鏈結至受信任的跟證書授權單位，而通用名稱或主體別名必須包含 STS 原則中主機名的專案。 此錯誤通常表示目的地郵件伺服器的憑證有問題。 如需 MTA-STS 的詳細資訊，請參閱 https://datatracker.ietf.org/doc/html/rfc8461。

輸入保護

如果網域擁有者的 MX 記錄指向 Exchange Online，則網域擁有者可以採取動作來保護使用 MTA-STS 送到其網域的電子郵件。 如果您的 MX 記錄指向中繼第三方服務，您將需要他們是否符合 MTA-STS 需求，然後遵循其指示。

一旦為網域設定 MTA-STS，任何從支援 MTA-STS 的寄件者所送出的郵件都會執行標準配置驗證，以確保安全連線。 如果您收到來自不支援 MTA-STS 的寄件者所傳送的電子郵件，電子郵件仍然會傳遞，而不需要額外保護。 同樣地，如果您尚未使用 MTA-STS，但寄件者支援 MTA-STS，則郵件不會中斷。 郵件無法傳遞的唯一案例是當雙方使用 MTA-STS 和 MTA-STS 驗證失敗時。

如何採用 MTA-STS

MTA-STS 允許網域宣告 TLS 的支援，並傳達 MX 記錄和目的地憑證。 它也會指出如果發生問題，傳送伺服器必須執行什麼動作。 此通訊是透過 DNS TXT 記錄和發佈為 HTTPS 網頁的原則檔案的組合來完成。 受 HTTPS 保護的安全性原則引進了攻擊者必須克服的另一個安全性保護。

網域的 MTA-STS TXT 記錄會向寄件者指出 MTA-STS 支援，之後寄件者會擷取網域的 HTTPS 型 MTA-STS 原則。 下列 TXT 記錄是宣告支援 MTA-STS 的範例:

_mta-sts.contoso.com. 3600 IN TXT v=STSv1; id=20220101000000Z;

網域的 MTA-STS 原則必須位於網域的 Web 基礎結構所託管的預先定義 URL。 URL 語法為 https://mta-sts.<domain name>/.well-known/mta-sts.txt。 例如，在 https://mta-sts.microsoft.com/.well-known/mta-sts.txt 找到 Microsoft.com 的原則。

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 604800

任何 MX 記錄直接指向 Exchange Online 的客戶，都可以在自己的原則中指定中顯示https://mta-sts.microsoft.com/.well-known/mta-sts.txt的相同值。 原則中的唯一必要資訊是指向 Exchange Online (.mail.protection.outlook.com) *的 MX 記錄，而且所有 Exchange Online 客戶都會共用相同的憑證。 Exchange Online 只允許一個組織接收指定網域的電子郵件，讓使用通配符不會降低安全性;不過，其他電子郵件服務可能不行。 您可以在 測試 模式中發佈原則，以確保在將原則變更為 強制 模式之前有效。 協力廠商驗證工具可以檢查您的設定。

這些原則不是 Exchange Online 可以代表客戶裝載的原則;因此，客戶必須使用他們偏好的服務來設定其網域的 STS 原則。 Azure 服務可以輕鬆地用於原則裝載，本文稍後會有設定逐步解說。 此原則必須受 HTTPS 保護，並擁有子網域 mta-sts.<domain name> 的憑證。

一旦建立 DNS TXT 記錄，且原則檔案可在必要的 HTTPS URL 取得，網域就會受到 MTA-STS 的保護。 如需 MTA-STS 的詳細數據，請參閱 RFC 8461。

使用 Azure 服務設定輸入 MTA-STS

注意事項

這些組態流程的開發，可協助 Microsoft Exchange Online 客戶使用 Azure 資源裝載其 MTA-STS 原則。 此設定流程假設您是瞭解 MTA-STS 運作方式及其需求的 Exchange Online 客戶。 如需本主題以外通訊協議的詳細資訊，請 參閱RFC8461。

有兩個 Azure 資源可用來裝載 MTA-STS 原則：Azure 靜態 Web 應用程式和 Azure Functions。 雖然本文說明如何使用這兩個資源來部署原則，但建議的方法是 Azure 靜態 Web 應用程式 ，因為它是專為裝載 STS 原則等靜態頁面所設計，而 Azure 則會提供現成的 MTA-STS 網頁 TLS 憑證來簡化設定，而不需要進行更多設定。 如果您無法使用 Azure 靜態 Web 應用程式，您也可以使用 Azure Functions 將原則裝載為無伺服器程式代碼。 此方法不是慣用的方法，因為 Azure Functions 是專為其他案例設計的功能，而且不會自動發出 TLS 憑證，不同於 Azure Static Web Apps。 因此，針對 MTA-STS 使用 Azure Functions 需要您發出自己的 “mta-sts.[您的網域]」憑證，並將其系結至函式。

不論您採用哪種方法，我們鼓勵您驗證您的原則是否已正確設定，以及回應時間是否可接受 – 每個 RFC 指引的逾時為 60 秒。

這些設定流程僅提供 Azure 功能的技術資訊，可用來裝載 MTA-STS 原則，而不會提供任何有關 Azure 功能收費或成本的資訊。 如果您想要知道 Azure 功能的成本，請使用 Azure 定價計算機。

  1. 建立 Azure DevOps 組織，或使用已存在的組織。 在此範例中，名為 「ContosoCorporation」 的組織將用來裝載 MTA-STS 原則。

    顯示 [專案] 索引標籤的螢幕快照。

  2. 在 [存放 > 庫檔案] 中，在您偏好的任何 IDE 中複製您的存放庫。 在此範例中，會在 Visual Studio 中複製存放庫。

    顯示複製到 Visual Studio 程式代碼範例的螢幕快照。

  3. 複製存放庫之後，請建立資料夾路徑 home\.well-known\。 然後，建立下列檔案：

    • 檔案 1：home.well-known\mta-sts.txt

    注意事項

    此設定只允許 Exchange Online 代表您的網域接收訊息。 如果您使用多個電子郵件提供者，您也需要參考其他提供者網域的 MX 主機。 通配符或 『*』 不能作為所有 MTA-STS 案例中的 MX 前置詞;下列設定僅適用於 Exchange Online，且不得作為設定 MTA-STS 的一般指引。

    1. 將下列文字輸入 mta-sts.txt 檔案中：

         version: STSv1
   mode: testing
   mx: *.mail.protection.outlook.com
   max_age: 604800

      注意事項

      建議您一開始將原則模式設定為 測試。 然後，在設定結束時和驗證原則是否如預期般運作之後，更新 mta-sts.txt 檔案以 強制執行模式。

      檔案只能包含如下列螢幕快照所示的內容：

      顯示 File1 內容的螢幕快照。

    • 檔案 2：home\index.html

    1. index.html建立檔案並將下列程式代碼輸入其中：

          <!DOCTYPE html>
    <html lang="en">

    <head>
    <meta charset="UTF-8">
    <title>MTA-STS</title>
    </head>

    <body>
    <h1>MTA-STS Static Website index</h1>
    </body>

    </html>

    檔案只能包含如下列螢幕快照所示的內容：

    顯示 File2 內容的螢幕快照。

    建立資料夾路徑和檔案之後，別忘了認可變更，並將其推送至主要分支。

  4. 使用下列組態建立新的 Azure 靜態 Web 應用程式：

    • 名稱：MTA-STS-StaticWebApp
    • 計劃類型：標準
    • 部署詳細數據：Azure DevOps
    • 組織：ContosoCorporation
    • 專案：MTA-STS_Project
    • 存放庫：MTA-STS_Project
    • 分支：master
    • 建置預設：Angular
    • 應用程式位置：/home

    顯示新建立的 Azure 靜態 Web 應用程式及其信息的螢幕快照。

  5. 完成靜態 Web 應用程式建立並布建資源之後，請移至 [概 觀 > 管理部署令牌]，然後複製令牌，以在下一個步驟中使用。

  6. 移至 [管線>] Azure Repos Git > MTA-STS_Project建立管線>，然後執行下列子工作：

    1. 移至 [變數 > ] [新增變數] ，然後輸入下列內容：

      1. 名稱：令牌
      2. 值： (貼上您先前複製的令牌，請在步驟 5)

    2. 儲存變數之後，返回 檢閱您的管線 YAML 並貼上下列 yml，儲存並執行它：

          trigger:
    - main

    pool:
    vmImage: ubuntu-latest

    steps:
    - checkout: self
    submodules: true
    - task: AzureStaticWebApp@0
    inputs:
     app_location: '/home'
     azure_static_web_apps_api_token: $(token)

      在 Azure DevOps 中，如果您在部署期間遇到 「未購買或授與任何託管平行處理原則」錯誤，請透過此 表單 要求，或透過 組織設定 > 平行作業 > 實作設定 Microsoft 託管 > 變更 > 付費平行作業 ，以允許「付費平行作業」。

  7. 作業順利完成後，您可以移至 Azure Static Web App > Environment > Browser，透過 Azure 入口網站 驗證部署。 您必須看到 index.html 檔案的內容。

  8. 在 Azure 靜態 Web 應用程式>自定義網域新增中新增虛名網域>。 您必須透過 DNS 提供者建立 CNAME 記錄 (例如 GoDaddy) ，以驗證區域是否屬於您。 驗證完成後，Azure 會發出憑證，並自動將其系結至靜態 Web 應用程式。

  9. 驗證您的 MTA-STS 原則是否透過下列方式發佈： https://mta-sts.[您的網域]/.已知/mta-sts.txt。

  10. 透過您的 DNS 提供者建立 MTA-STS TXT DNS 記錄。 格式為：

        Hostname: _mta-sts.<domain name>
    TTL: 3600 (recommended)
    Type: TXT
    Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;

    注意事項

    您可以在 如何採用 MTA-STS 中找到範例 MTA-STS TXT 記錄。

  11. 一旦 TXT 記錄可在 DNS 中使用，請驗證您的 MTA-STS 設定。 成功驗證組態之後，請更新 mta-sts.txt 檔案以 強制執行原則模式，然後更新 TXT 記錄中的原則識別碼。

選項 2：Azure 函式

  1. 使用下列組態建立新的 Azure 函式應用程式：

    • 函式應用程式名稱：[做為您的選擇]
    • 發佈：程序代碼
    • 運行時間堆疊：.NET
    • 版本：6
    • 操作系統：Windows
    • 計劃類型：[做為您的選擇]

    顯示新 Azure 函式應用程式設定的螢幕快照。

  2. 將您的自定義網域新增至函式應用程式。 您必須建立 CNAME 記錄，以驗證網域是否屬於您。

    顯示要新增至函式應用程式之自定義網域的螢幕快照。

  3. 系結您的 「mta-sts」。[您的網域]“ 至函式應用程式。

    此螢幕快照顯示將網域系結至函式應用程式的程式。

  4. 在 [應用程式檔案] 中，將下列延伸模組新增至函式應用程式的host.json，以消除 routePrefix。 若要從函式 URL 移除 /api，必須新增此專案。

        "extensions": {
"http": {
  "routePrefix": ""
  }
}

    顯示要新增至應用程式檔案之擴充功能的螢幕快照。

  5. 在函式應用程式中，移至 [>函式建立] 並設定下列參數：

    注意事項

    雖然此範例透過入口網站描述函式開發，但您可以自由使用 VS Code 或您偏好的任何其他工具。

    • 開發環境：[如您所選擇，此範例將使用「在入口網站中開發」]
    • 選取範本：HTTP 觸發程式
    • 新增函式：[做為您的選擇]
    • 授權層級：匿名

    顯示 [建立函式] 頁面的螢幕快照。

  6. 建立函式之後，請開啟 [程序代碼 + 測試 ]，並在 C# 中開發簡單的異步 HTTP 回應，這會是您的 MTA-STS 原則。 下列範例指出 Exchange Online 預期會收到電子郵件：

    注意事項

    建議您一開始將原則模式設定為 測試。 然後，在設定結束時和驗證原則是否如預期般運作之後，更新 mta-sts.txt 檔案以 強制執行模式。

    顯示所開發 mta-sts 原則的螢幕快照。

  7. 在 Integration > HTTP (req) 中，將觸發程式編輯為下列值：

    • 路由範本：.well-known/mta-sts.txt
    • 選取的 HTTP 方法：GET

    顯示 [編輯觸發程式] 頁面的螢幕快照。

  8. 驗證您的 MTA-STS 原則是透過下列方式發佈： https://mta-sts.[您的網域]/.已知/mta-sts.txt。

  9. 以下列格式透過 DNS 提供者建立 MTA-STS TXT DNS 記錄：

       Hostname: _mta-sts.<domain name>
   TTL: 3600 (recommended)
   Type: TXT
   Text: v=STSv1; id=<ID unique for your domain’s STS policy>Z;

    注意事項

    您可以在 如何採用 MTA-STS 中找到範例 MTA-STS TXT 記錄。

  10. 一旦 TXT 記錄可在 DNS 中使用，請驗證您的 MTA-STS 設定。 成功驗證組態之後，請更新 mta-sts.txt 檔案以 強制執行原則模式，然後更新 TXT 記錄中的原則識別碼。