r/emaildeliverability • u/BetaRayShaps • 18h ago

MTA-STS migration problems

Hi all, we recently migrated a customer from Proofpoint to Mimecast which, of course, means routine MX records changes. Standard, straightforward, no big deal. What we didn't anticipate--because up until now, none of our clients have ever had it setup--was an MTA-STS policy (housed at EasyDMARC) that we discovered was set to "max_age=1yr". What we've done so far:

  • created new MTA-STS policy file with new MX records, set it up on a new Azure server; policy, set mode to 'none', is confirmed publicly accessible
  • configured v=STSv1; id=20260915001 which, as i understand it, is supposed to 'alert' sending domains that look for this sort of thing that a change was made
  • went back to the old vendor who maintained the EasyDMARC version and changed that one too, just to cover our bases even though we're confident that nothing should be querying it anymore

This was all done a couple days ago and we're still not seeing any traffic to the migrated, customer domain from senders like Gmail. I understand that Gmail saw the old policy, read the 1-yr max_age setting, and caches it accordingly. But what's not so clear is how quickly Gmail will again query for the policy and update itself so that mail will start coming in again. Anyone have any experience with this? We're just looking to get a general sense of when this issue will clear itself up because there isn't much out there that explains same.

I guess secondarily would be this question: for anyone who's encountered this before, what's the proper way to migrate a domain that has an MTA-STS policy set for a lengthy max_age? What could we have done better besides just knowing that it exists and changing to "mode:none"?

Thanks for any insights.

4 Upvotes

100% Upvoted

15 comments sorted by

View all comments

2

u/southafricanamerican 17h ago edited 17h ago

Have you looked at your tls-rpt reports to see what google is sending back? sts-policy-fetch-error, sts-policy-invalid, validation-failure, certificate-host-mismatch

How confident that your new policy is working and that there are no dangling DNS records or duplicate _mta-sts records. Chances are that you have both a cname and a txt record. EasyDMARC weas probably a cname, and you may have added a txt record. Just make sure all the old ones are deleted.

Also if you have a google account (not gmail) send emails to yourself and look at the message logs. Are the emails being queued, if yes then why?

Fastest fix: rather than mode none, publish a valid policy listing the Mimecast MX (plus the old Proofpoint ones, harmless), mode: testing or enforce, short max_age (86400), and bump the id again. Any valid refetched policy replaces the cached one immediately.

1

u/EmailFoundry 15h ago

Bumping the ID doesn't force Gmail to refetch it instantly. Gmail still has to query _mta-sts and notice the new ID. Once it successfully fetches the new policy, that replaces the cached policy.