Documentary review: 8 November 2026. No MX host, certificate, policy endpoint or sending implementation was tested. The route matrix and migration example below are proposed operational evidence, not observations of a customer domain.
Model one receiving domain with every intended route
A receiving domain can publish MX records pointing to more than one mail provider. Its MTA-STS policy must describe the acceptable MX hostnames for that domain's delivery path, not merely the brand used for most mailboxes. A policy that covers the primary provider but excludes the backup can appear healthy until a failure makes the backup necessary.
Start with the receiving domain and its complete authoritative MX set. Record preferences, target hostnames, service owners and whether each target is primary, backup or temporary migration capacity. Keep MX data separate from the policy's mx entries: DNS supplies the candidate route, while the policy validates whether a candidate is acceptable. A policy entry does not add a new MX destination or change its preference. MTA-STS discovery and validation
Identify any administratively configured smart host as a separate case. RFC 8461 treats that smart host's domain as the policy domain for compliant senders using the configured relay. Do not infer that the recipient domain's policy controls every internal relay hop or every service's onward routing.
Match hostnames precisely across providers
Each permitted MX pattern belongs on its own mx line in the HTTPS policy. Use actual hostnames or supported wildcard patterns, not IP addresses, provider marketing names or mailbox domains chosen by appearance. Internationalized names use their ASCII A-label representation. Confirm the provider's intended MX targets from current configuration evidence before publishing the list. Policy format
A policy wildcard matches only the entire leftmost label. For example, *.mail.example matches mx1.mail.example, but not mail.example or mx1.region.mail.example. It is not a general recursive suffix permission. A broad-looking pattern can therefore both authorize more hosts than intended and fail to match a deeper hostname that an operator expected it to cover. Write out the expected matches in the review worksheet. MX host matching
Prefer exact patterns where the host list is stable and manageable. If a provider requires a wildcard because its documented MX fleet changes, record that rationale and the scope it authorizes. Do not add a catch-all merely to remove a validation warning. The team should know which hosts become acceptable and who is responsible for the receiving service behind them.
Check transport and certificates for each candidate
A hostname match is only one validation step. Under an enforce policy, a compliant sender must not deliver to a candidate that fails MX matching, certificate validation or STARTTLS support. The receiving MTA's certificate must be unexpired, chain to a trusted root and contain a matching DNS identity for the MX hostname. The policy website's certificate is a different certificate with a different hostname obligation. MTA certificate validation and policy application
Collect transport evidence for every intended candidate, including rarely used backup infrastructure. Record which hostname and address were tested, when the test occurred, whether STARTTLS was offered and what certificate identities were presented. A successful test of one provider's primary host cannot establish the second provider's readiness. Any testing of third-party infrastructure must remain within an approved operational scope.
Ask each provider about changes to its MX names and certificate lifecycle. The organization's policy owner needs a way to learn when a supplier changes a receiving endpoint. A policy that was accurate at launch can later exclude an authorized route, while a certificate problem can break a route without any DNS change.
Preserve ordinary MX traversal and backup behavior
MTA-STS does not replace SMTP candidate traversal with a new provider-selection algorithm. RFC 8461 warns implementers against prefiltering candidates in ways that change the usual traversal logic and recommends treating invalid candidates as unreachable while following ordinary traversal. For domain operators, the practical lesson is to test the backup route explicitly rather than assuming routine traffic exercises it. Preserving MX candidate traversal
A backup provider can remain untested for long periods because successful primary delivery means senders never reach it. TLS reports with no failures therefore do not establish that every candidate works. Reports describe participating senders' observed delivery attempts, not an exhaustive inspection of the domain's possible routes. SMTP TLS reporting
Keep provider readiness and policy readiness as separate acceptance decisions. The backup might be listed correctly but lack a valid certificate, or it might have sound TLS while being omitted from the policy. Those defects require different owners and different corrective changes. Before permanently failing delivery because of an enforce policy, a compliant sender must check DNS for an updated policy; RFC 8461 also recommends treating these failures as transient and retrying later. This does not guarantee a particular retry schedule.
Stage changes with old policy caches in mind
During a provider migration, some senders may still apply a previously fetched policy. Updating the DNS MX set to a new provider before cached policies permit it can delay mail from compliant senders. Plan an overlap in which the old and new intended routes remain acceptable and operational while policy updates become discoverable and caches are considered.
RFC 8461 recommends updating the HTTPS policy body before changing the discovery TXT record's id. That order avoids signaling a new policy while the endpoint still serves the old content. DNS TTL and policy max_age are separate clocks; a new id does not synchronously replace every cached policy. Preserve a history of served policies and their lifetimes when planning route removal. Policy updates and caching
Testing mode can expose policy failures through TLS-RPT without enforcing MTA-STS rejection of those failures. It is useful for a controlled rollout, but it is not proof that the domain is protected as though enforce were active. Decide when to enforce using actual route evidence and accountable approval, not merely the passage of a fixed number of days.
Multiple-provider acceptance worksheet
Maintain one domain-level record with a row for each MX candidate and a separate policy history.
- Receiving domain ___; authoritative MX set and preferences ___; observation timestamp ___.
- Candidate hostname ___; provider/account owner ___; primary/backup/migration role ___; current business dependency ___.
- Pattern match: proposed mx value ___; exact expected match ___; unintended wildcard scope reviewed ___.
- Transport: approved test reference ___; STARTTLS ___; certificate hostname/chain/expiry evidence ___; unresolved condition ___.
- Policy host: exact HTTPS endpoint ___; valid response and content ___; discovery id ___; mode ___; max_age ___.
- Transition: old policy versions and last-served times ___; overlapping route support ___; DNS TTL assumptions ___; removal approval ___.
- Observation: TLS-RPT results and coverage limits ___; controlled primary/backup checks ___; accountable final sign-off ___.
Blank fields are holds. A candidate should not be treated as ready merely because its supplier is familiar or its MX preference is low.
Fictional example: the backup omitted from enforcement
This scenario is fictional. example.com uses mx1.primary.example as its preferred route and mx1.backup.example as a fallback. Its enforce policy lists only the primary hostname. Routine traffic succeeds, so the omission is not noticed until a primary outage makes the fallback relevant.
The proposed diagnosis compares the full MX set with the policy and separately checks the backup's STARTTLS and certificate evidence. The owner prepares a policy covering the authorized backup, publishes that body before a new discovery id and accounts for senders still using cached policy. The team does not claim immediate recovery for every sender or change MX preference simply to bypass enforcement.
The durable fix is an evidence-backed route matrix owned across both suppliers. No live results are claimed here. Independent review, actual DNS and transport checks, visual review and owner release remain pending before publication.