Implementing Inbound SMTP DANE with DNSSEC for Exchange Online Mail Flow

bogdanst95 Thanks for the question!

- Would the hosts for this use case from now on change to the respective <subdomain>.mx.microsoft?

Ian: Yes!

- For the already configured domains before July 2024, after going through the DNSSEC-enablement wizard, would both .mail.protection.outlook.com and .mx.microsoft work or would it be a complete migration to another server, removing completely the .mail.protection.outlook.com?

Ian: We will be deleting the mail.protection.outlook.com A record. We haven't seen customer demand for 2 MX records for the same Accepted Domain and therefore don't want to maintain an A record that is not being used. 

More pragmatic, if before sending to an inbound connector was through .mail.protection.outlook.com, would it mean that after the migration the new host to send to would be the .mx.microsoft one?

Ian: Yes, after the migration and MX record change the new host would be the contoso-com.<subdomain>.mx.microsoft one.

2. Related to the same scenario of a Smart Host, with emails being routed out with the outbound connector and then received back on the inbound, how would the new changes influence this flow? 3rd party Gateways are specified as a limitation, but in this case, my question relates to 3rd party SMTP relays.

Ian: Great question! For relay scenarios where the customer's MX still points to ExO, our current plan is to support the flow and customers will be able to use the wizard to migrate their MX record. The 3rd party relay needs to do a DNS lookup and use the new MX/A record hostname -> contoso-com.<subdomain>.mx.microsoft. If the 3rd party relay doesn't support DNSSEC/DANE and the ExO customer migrates to DNSSEC, there will be no impact to mail flow but the flow will not be secured by DNSSEC/DANE as the protocols require both parties to support it, otherwise the email will be sent but validations just won't occur.