Implementing Inbound SMTP DANE with DNSSEC for Exchange Online Mail Flow

michaelkennedy - thanks for the comment! Below are my replies.

For people who have configured an MTA-STS policy using the legacy domain, will they need to change their policy?

Ian: Yes, and this will be documented as well as included in the DNSSEC-migration wizard.

If so, will the onboarding wizard check if the domain has configured an MTA-STS policy with the legacy domain?

Ian: Yep! And at several points during the wizard, we will validate the policy is healthy before moving forward. This is necessary to prevent mail flow disruptions (for example, if a customer adds the new MX while the policy is set to enforce and doesn't add the new MX host to the policy, the new MX might be picked up/used for traffic but would fail MTA STS validation).

Will the <subdomain>.mx.microsoft subdomain be the same for all accepted domains configured on a tenant?

Ian: No. We didn't see a functional need, customers didn't seem vocal beyond "it'd be nice", and by not doing this we are able to manage capacity much more efficiently.

I'm fairly sure that the current certificate with a SAN of *.mx.microsoft will not be valid for a domain like contoso-com.1j2b-v1.mx.microsoft. Should we expect the certificate to have a tremendous number of new wildcard SANs?

Ian: Updating that your concern was correct! *.mx.microsoft does not cover the subdomains for the SAN. We will be adding 25 SANs for the zones, this number will grow in 5-10 years from now.