Another variant of this is cached or preloaded security configurations. HSTS (which forces browsers to validate HTTPS when connecting) asks browsers to cache the configuration for a set "max-age". Some sites set huge values here, like Twitter's 20 year max-age[1]. There's also the preload lists [2] to consider. This creates a problem if you want to serve non-HTTPS/unencrypted HTTP on your new domain and the previous…
FWIW, you can invalidate MTA-STS cache by updating the DNS assertion record to a different 'id' value. This is how you indicate a policy has changed. So the sender is supposed to obey the normal DNS TTL caching period, and re-query the assertion record if TTL expired. It should re-fetch the MTA-STS policy if the 'id' value in the DNS assertion changed, or the max_age in the previously fetched policy has expired.
> RFC 8461 section 3.3: Conversely, if no "live" policy can be [...] fetched via HTTPS, but a valid (non-expired) policy exists in the sender's cache, the sender MUST apply that cached policy.
You'll also need to host a "none" policy doc. Full instructions are here: https://www.rfc-editor.org/rfc/rfc8461.html#section-8.3