使用 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 验证 根据域的 STS 策略,目标 MX 主机不是预期的主机。 此错误通常表示目标域的 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 允许域声明对 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。 例如,Microsoft.com 的策略位于:https://mta-sts.microsoft.com/.well-known/mta-sts.txt

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) 且所有Exchange Online客户共享同一证书的 MX 记录。 Exchange Online仅允许一个组织接收给定域的电子邮件,以便使用通配符不会削弱安全性;但是,其他电子邮件服务可能并非如此。 可以在 测试 模式下发布策略,以确保在将策略更改为 强制 模式之前有效。 有第三方验证工具可以检查配置。

这些策略不是Exchange Online可以代表客户托管的;因此,客户必须使用他们喜欢的服务配置其域的 STS 策略。 Azure 服务可以轻松用于策略托管,本文稍后会介绍配置演练。 该策略需要由 HTTPS 保护,其中包含子域 mta-sts.<domain name> 的证书。

创建 DNS TXT 记录并在所需的 HTTPS URL 处提供策略文件后,域将受到 MTA-STS 的保护。 RFC 8461 中提供了有关 MTA-STS 的详细信息。

使用 Azure 服务配置入站 MTA-STS

注意

这些配置流旨在帮助Microsoft Exchange Online客户使用 Azure 资源托管其 MTA-STS 策略。 此配置流假定你是了解 MTA-STS 工作原理及其要求Exchange Online客户。 有关本主题以外的协议的详细信息,请参阅 RFC8461

有两个 Azure 资源可用于托管 MTA-STS 策略:Azure Static Web AppAzure Functions。 尽管本文介绍了如何使用这两种资源部署策略,但建议的方法是 Azure 静态 Web 应用 ,因为它用于托管静态页面(如 STS 策略),Azure 通过为 MTA-STS 网页提供现成的 TLS 证书来简化配置,而无需进行更多配置。 如果无法使用 Azure Static Web App,还可以使用 Azure Functions 将策略托管为无服务器代码。 此方法不是首选方法,因为 Azure Functions 是专为其他方案设计的一项功能,它不会自动颁发 TLS 证书,这与Azure Static Web Apps不同。 因此,将 Azure Functions用于 MTA-STS 需要发出自己的“mta-sts”。[你的域]“证书并将其绑定到 函数。

无论采用哪种方法,我们都鼓励验证策略是否已正确配置,以及响应时间是否可接受 - 每个 RFC 指南的超时为 60 秒。

这些配置流旨在仅提供有关可用于托管 MTA-STS 策略的 Azure 功能的技术信息,不提供有关 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 内容的屏幕截图。

    创建文件夹路径和文件后,请不要忘记提交更改并将其推送到 main 分支。

  4. 使用以下配置创建新的 Azure Static Web 应用:

    • 名称:MTA-STS-StaticWebApp
    • 计划类型:标准
    • 部署详细信息:Azure DevOps
    • 组织:ContosoCorporation
    • 项目:MTA-STS_Project
    • 存储库:MTA-STS_Project
    • 分支:master
    • 生成预设:Angular
    • 应用位置:/home

    显示新创建的 Azure Static Web 应用及其信息的屏幕截图。

  5. 完成静态 Web 应用创建并预配资源后,请转到 “概述 > 管理部署令牌”;然后复制令牌,因为该令牌将在下一步中使用。

  6. 转到“管道>创建管道>”Azure Repos Git > MTA-STS_Project,并执行以下子任务:

    1. 转到 “变量 > ”“新建变量” 并键入以下内容:

      1. 名称:token
      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 门户转到 Azure Static Web App > Environment > Browser 来验证部署。 必须看到 index.html 文件的内容。

  8. Azure Static Web App > 自定义域中添加虚域>。 需要通过 DNS 提供程序创建 CNAME 记录, (例如 GoDaddy) 来验证区域是否属于你。 验证完成后,Azure 将颁发证书并将其自动绑定到静态 Web 应用。

  9. 验证 MTA-STS 策略是否通过[ https://mta-sts.您的域]/.well-known/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. 在 DNS 中提供 TXT 记录后,请验证 MTA-STS 配置。 成功验证配置后,请更新 mta-sts.txt 文件,以便 强制实施策略模式;然后在 TXT 记录中更新策略 ID。

选项 2:Azure 函数

  1. 使用以下配置创建新的 Azure 函数应用:

    • 函数应用名称:[根据需要]
    • 发布:代码
    • 运行时堆栈:.NET
    • 版本:6
    • 操作系统:Windows
    • 计划类型:[根据你的选择]

    显示新 Azure 函数应用的配置的屏幕截图。

  2. 将自定义域添加到函数应用。 需要创建 CNAME 记录来验证域是否属于你。

    显示要添加到函数应用的自定义域的屏幕截图。

  3. 绑定“mta-sts”。[域]“到函数应用。

    显示将域绑定到函数应用的过程的屏幕截图。

  4. “应用文件”中,将以下扩展添加到函数应用的 host.json 中,以消除 routePrefix。 若要从函数 URL 中删除 /api,必须进行此添加。

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

    显示要添加到应用文件的扩展的屏幕截图。

  5. 在函数应用中,转到 Functions > 创建 并配置以下参数:

    注意

    尽管此示例通过门户描述了函数开发,但你可以自由使用 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.[你的域]/.well-known/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. 在 DNS 中提供 TXT 记录后,请验证 MTA-STS 配置。 成功验证配置后,更新 mta-sts.txt 文件以 强制实施策略模式;然后在 TXT 记录中更新策略 ID。