An MTA-STS mx line describes an allowed receiving hostname. It is neither an MX DNS record nor an instruction that creates routing. Senders still obtain the receiving route through DNS and apply the policy to candidate MX hosts.
Compare hostnames, not addresses
Suppose DNS advertises mx1.provider.example and mx2.provider.example. An exact policy pattern for mx1 does not also permit mx2, even if both names resolve to the same address. Conversely, allowing a hostname does not make every server address behind it operational. Retain DNS route data and transport tests separately from the name comparison.
Use one mx line per pattern. Policy patterns can be fully specified names or a wildcard that is the entire leftmost label. Internationalized names must use their A-label representation. Avoid feeding email addresses, IP literals or provider console labels into the MX pattern list.
Understand the one-label wildcard
Under RFC 8461 section 4.1, *.example.net matches mail.example.net. It does not match example.net or foo.bar.example.net. A partial label such as mail*.example.net is not the allowed wildcard form. Choosing *.example.net therefore expands the allowed set to one-label children without authorizing every descendant at arbitrary depth.
Keep that scope tied to actual receiving infrastructure. A broad provider wildcard can be convenient during a supported migration but is not automatically the safest policy. Verify the provider's current documented requirements and the actual MX answers rather than inventing a wildcard from its brand name.
Walk through the name comparison
These synthetic examples apply RFC 8461 section 4.1 directly. They are hand-worked comparisons, not executed network tests or a complete policy validator.
- Pattern *.example.net, candidate mail.example.net: match. Replacing the entire leftmost label leaves the required example.net suffix.
- Pattern *.example.net, candidate example.net: no match. The candidate has no additional leftmost label.
- Pattern *.example.net, candidate foo.bar.example.net: no match. Removing its leftmost label leaves bar.example.net, not example.net.
- Exact pattern mx1.provider.example, candidate mx2.provider.example: no match, even if their IP addresses happen to be equal.
- Pattern mail*.example.net: invalid wildcard form, so do not treat it as a permitted pattern.
The comparisons use normalized ASCII names. A production implementation also needs complete parsing, internationalized-name handling, policy retrieval and TLS validation. No companion script is required to understand these cases.
Validate the rest of the connection
Once a candidate matches a pattern, the receiving server still needs STARTTLS and a valid, trusted, unexpired certificate matching that candidate hostname. The certificate must contain a matching DNS-ID in its subjectAltName. A certificate wildcard and a policy wildcard occupy different documents and must be checked independently. An unrelated certificate cannot be rescued by a permissive mx line.
During changes, compare every current and planned MX against both the previous and new policy. This catches the important case where the current policy permits a newly added host but senders still enforcing the previous policy do not. Keep old allowed routes functioning while policy caches age or refresh.
Policy mode matters: an MTA honoring a valid enforce policy must not deliver to a candidate that fails MX matching, certificate validation or STARTTLS requirements. Under testing, delivery may proceed despite validation failures. These checks do not prove that every sender implements MTA-STS.
Use a migration check card
- List every current and planned DNS MX hostname, including backups.
- Compare each with the old and proposed policy patterns; do not compare IP addresses instead.
- For each permitted candidate, independently check STARTTLS and certificate chain, validity period and hostname.
- Publish the new HTTPS policy body before changing the _mta-sts TXT policy identifier.
- Preserve old-policy-compatible delivery while senders discover the change; account for DNS TTL and cached policy lifetime.
- Record unknowns or failed checks before expanding policy scope or moving traffic.