使用 MTA-STS 增強郵件流程

發行項
08/10/2024

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 記錄應該包含 v=STSv1;直到支援 STSv2，以及原則的標識碼。對於網域擁有者和原則而言，標識符必須是唯一的，因為標識碼中的變更會向發件者發出需要重新擷取原則的訊號。標識元不需要是全域唯一的，別擔心其他網域擁有者的原則標識碼。在任何 MTA-STS 原則更新之後，您必須更新標識符，否則發件者會繼續使用網域的快取原則，直到快取原則的max_age到期為止。

設定唯一識別碼的可重複模式是使用 UTC 時間，如下所示：
id=<yyyymmddhh0000>Z;

下列 TXT 記錄是宣告支援 MTA-STS 的範例，標識碼設定於 2022 年 1 月 1 日上午 8 點 UTC 時間：

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

網域的 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 靜態 Web 應用程式

建立 Azure DevOps 組織，或使用已存在的組織。在此範例中，名為「ContosoCorporation」的組織將用來裝載 MTA-STS 原則。
在 [存放 > 庫檔案] 中，在您偏好的任何 IDE 中複製您的存放庫。在此範例中，會在 Visual Studio 中複製存放庫。
複製存放庫之後，請建立資料夾路徑 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 檔案以 強制執行模式。
    
    檔案只能包含如下列螢幕快照所示的內容：
- 檔案 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>
```
    檔案只能包含如下列螢幕快照所示的內容：
    
    建立資料夾路徑和檔案之後，別忘了認可變更，並將其推送至主要分支。
使用下列組態建立新的 Azure 靜態 Web 應用程式：
- 名稱：MTA-STS-StaticWebApp
- 計劃類型：Standard
- 部署詳細數據：Azure DevOps
- 組織：ContosoCorporation
- 專案：MTA-STS_Project
- 存放庫：MTA-STS_Project
- 分支：master
- 組建預設：Angular
- 應用程式位置：/home
完成靜態 Web 應用程式建立並布建資源之後，請移至 [概 觀 > 管理部署令牌]，然後複製令牌，以在下一個步驟中使用。
移至 [管線>][建立管線 > 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託管 > 變更 > 付費平行作業 ，以允許「付費平行作業」。
作業順利完成後，您可以移至 Azure Static Web App > Environment > Browser，透過 Azure 入口網站驗證部署。您必須看到 index.html 檔案的內容。
在 Azure 靜態 Web 應用程式>自定義網域新增中新增虛名網域>。您必須透過 DNS 提供者建立 CNAME 記錄 (例如 GoDaddy) ，以驗證區域是否屬於您。驗證完成後，Azure 會發出憑證，並自動將其系結至靜態 Web 應用程式。
驗證您的 MTA-STS 原則是否透過下列方式發佈： https://mta-sts.[您的網域]/.已知/mta-sts.txt。
透過您的 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 記錄。
一旦 TXT 記錄可在 DNS 中使用，請驗證您的 MTA-STS 設定。成功驗證組態之後，請更新 mta-sts.txt 檔案以 強制執行原則模式，然後更新 TXT 記錄中的原則識別碼。

選項 2：Azure 函式

使用下列組態建立新的 Azure 函式應用程式：
- 函式應用程式名稱：[做為您的選擇]
- 發佈：程序代碼
- 運行時間堆疊：.NET
- 版本：6
- 操作系統：Windows
- 計劃類型：[做為您的選擇]
將您的自定義網域新增至函式應用程式。您必須建立 CNAME 記錄，以驗證網域是否屬於您。
系結您的「mta-sts」。[您的網域]“ 至函式應用程式。
在 [應用程式檔案] 中，將下列延伸模組新增至函式應用程式的host.json，以消除 routePrefix。若要從函式 URL 移除 /api，必須新增此專案。
```
"extensions": {
  "http": {
    "routePrefix": ""
  }
}
```
在函式應用程式中，移至 [>函式建立] 並設定下列參數：

注意事項

雖然此範例透過入口網站描述函式開發，但您可以自由使用 VS Code 或您偏好的任何其他工具。
- 開發環境：[如您所選擇，此範例將使用「在入口網站中開發」]
- 選取範本：HTTP 觸發程式
- 新增函式：[做為您的選擇]
- 授權層級：匿名
建立函式之後，請開啟 [程序代碼 + 測試 ]，並在 C# 中開發簡單的異步 HTTP 回應，這會是您的 MTA-STS 原則。下列範例指出 Exchange Online 預期會收到電子郵件：

注意事項

建議您一開始將原則模式設定為測試。然後，在設定結束時和驗證原則是否如預期般運作之後，更新 mta-sts.txt 檔案以 強制執行模式。
在 Integration > HTTP (req) 中，將觸發程式編輯為下列值：
- 路由範本：.well-known/mta-sts.txt
- 選取的 HTTP 方法：GET
驗證您的 MTA-STS 原則是透過下列方式發佈： https://mta-sts.[您的網域]/.已知/mta-sts.txt。
以下列格式透過 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 記錄。
一旦 TXT 記錄可在 DNS 中使用，請驗證您的 MTA-STS 設定。成功驗證組態之後，請更新 mta-sts.txt 檔案以 強制執行原則模式，然後更新 TXT 記錄中的原則識別碼。