@Rafał Fitt RE: well, third party validators - they are never good enough for any MS support ticket: I can see in practice it'd simplify things with Support if we have an official validator, so we're looking into this now.
rhupf RE actions required by admin to enable or not: I can see how this might be confusing. For outbound no admin action is required - by default we'll now check for a destination domain's MTA-STS policy and adhere to its conditions. For inbound, an admin need not do anything within Exchange Online, but to enable MTA-STS checks for your domains you'll have to update your DNS records with a TXT record for MTA-STS, create the policy and host it in your web infrastructure.
TIS_llama and FuriousHaggis RE a monitored location to host the policy file: The MTA-STS RFC 8461 says
MTA-STS policies are distributed via HTTPS from a "well-known"
[RFC5785] path served within the Policy Domain, and their presence
and current version are indicated by a TXT record at the Policy
Domain.
The imperative for it to be "within the Policy Domain" typically suggests it be hosted in your web infrastructure. So while I agree it's a great idea that we'll look into, we'll have to make sure we can do it "within the Policy Domain" securely somehow when your web infrastructure is hosted elsewhere or when you have no web infrastructure for the domain.
LundfeJE for MX records pointing to another gateway not Exchange Online: Your policy should use the MX record that points to that email gateway and not the MX record for Exchange Online, even if your domain is hosted by M365.
Anders5656 RE use wildcard or use the domain-key (e.g. use *.mail.protection.outlook.com or contoso-com.mail.protection.outlook.com): Don't use the domain-key, use the wildcard. Certificate validation will fail if you specify the domain-key.
Arttu_Arstila RE typo in TLS-RPT TXT record: Great catch, thank you! I'll get that changed ASAP to: _smtp._tls.example.com. 3600 IN TXT v=TLSRPTv1;rua=mailto:reports@example.com