共用方式為


使用 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 記錄中的原則識別碼。