一个 MTA-STS mx 行描述允许的接收主机名。它既不是MX DNS记录，也不是创建路由的指令。发送者仍然通过DNS获取接收路由并将策略应用于候选MX主机。
比较主机名，而不是地址
假设DNS通告mx1.provider.example和mx2.provider.example 。 mx1 的精确策略模式也不允许 mx2，即使两个名称解析为同一地址也是如此。相反，允许主机名并不会使它后面的每个服务器地址都可以运行。将DNS路由数据和传输测试与名称比较分开保留。
每个图案使用一条 mx 线。策略模式可以是完全指定的名称或作为整个最左侧标签的通配符。国际化名称必须使用其 A 标签表示形式。避免将电子邮件地址、IP 文字或提供商控制台标签输入到MX模式列表中。
了解单标签通配符
根据RFC 8461第 4.1 节，*。 example.net匹配mail.example.net 。它与example.net或foo.bar.example.net不匹配。部分标签，例如 mail*。 example.net不是允许的通配符形式。选择*。因此， example.net将允许的集合扩展到单标签子代，而不授权任意深度的每个后代。
将该范围与实际接收基础设施联系起来。广泛的提供商通配符在受支持的迁移过程中可能很方便，但并不是最安全的策略。验证提供商当前记录的要求和实际MX答案，而不是根据其品牌名称发明通配符。
通过名称比较
这些综合示例直接应用RFC 8461第 4.1 节。它们是手工比较，而不是执行的网络测试或完整的策略验证器。
- 图案 *。 example.net ，候选mail.example.net ：匹配。替换整个最左边的标签会留下所需的example.net后缀。
- 图案 *。 example.net ，候选example.net ：不匹配。候选人没有额外的最左边标签。
- 图案 *。 example.net ，候选foo.bar.example.net ：不匹配。删除最左边的标签会留下bar.example.net ，而不是example.net 。
- 精确模式mx1.provider.example ，候选mx2.provider.example ：不匹配，即使它们的 IP 地址碰巧相同。
- 图案邮件*。 example.net ：无效的通配符形式，因此不要将其视为允许的模式。
比较使用规范化的 ASCII 名称。生产实现还需要完整的解析、国际化名称处理、策略检索和TLS验证。不需要配套脚本来理解这些情况。
验证其余连接
一旦候选者与模式匹配，接收服务器仍然需要 STARTTLS 以及与候选主机名匹配的有效、可信、未过期的证书。证书必须在其 subjectAltName 中包含匹配的 DNS-ID。证书通配符和策略通配符占用不同的文档，必须单独检查。不相关的证书无法通过许可的 mx 行来挽救。
在更改期间，将每个当前和计划的MX与之前的和新的策略进行比较。这捕获了当前策略允许新添加的主机但仍执行先前策略的发件人不允许的重要情况。在策略缓存老化或刷新时，保持旧的允许路由正常运行。
政策模式很重要： MTA 遵守有效的强制策略不得交付给未通过MX匹配、证书验证或STARTTLS要求的候选者。在测试中，尽管验证失败，交付仍可能继续进行。这些检查并不能证明每个发送方都实现了MTA-STS 。
使用移民检查卡
- 列出每个当前和计划的DNS MX主机名，包括备份。
- 将每种政策模式与旧的和拟议的政策模式进行比较；相反，不要比较 IP 地址。
- 对于每个允许的候选者，独立检查STARTTLS和证书链、有效期和主机名。
- 在更改_mta-sts TXT策略标识符之前发布新的 HTTPS 策略正文。
- 当发件人发现更改时，保留旧策略兼容的传送；考虑DNS TTL 和缓存策略生命周期。
- 在扩大策略范围或移动流量之前记录未知或失败的检查。