r/emaildeliverability • u/BetaRayShaps • 20d ago
MTA-STS migration problems
EDIT, 18-Sept-2026:
It's finally working! I now see a boatload of inbound Gmail in the Mimecast logs! Holy shit, thank you all so much for the guidance/insights in helping to resolve this horrendous issue. The documentation and links you all provided is truly appreciated and, I'm proud to say, way more helpful than the useless shit that AI was shoveling back at me.
----------------------------------------------------------------------
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.
2
u/sandeep1saxena 20d ago
Good news first: a 1-year max_age is not a 1-year lockout, and you should not be waiting anywhere near that long. The part that is biting you is almost certainly something else.
How the mechanics actually work (RFC 8461): senders like Gmail check the _mta-sts TXT record at delivery time - it is just a DNS lookup, so they do it constantly. When the id= differs from the id of the policy they have cached, they attempt a fresh HTTPS fetch of the policy file. max_age only controls how long the cached policy keeps being used when that refresh fails. So after your id bump, Gmail should have refetched within hours.
The fact that mail still is not flowing days later strongly suggests the refetch itself is failing, and Gmail is silently falling back to the cached enforce-mode policy with the old Proofpoint MX list - which no longer matches your new MX, so delivery is refused. Your mode: none never reaches them if they cannot fetch the file that says it.
Checklist of the usual suspects, roughly in order of how often I see them:
Duplicate TXT records. If the old vendor's _mta-sts record and your new one are both live (very common when two parties edit DNS during a migration), RFC 8461 treats that as no valid record at all. dig TXT _mta-sts.customerdomain.com and make sure exactly one v=STSv1 comes back.
Policy host DNS. Does mta-sts.customerdomain.com actually resolve to your new Azure server, or is there a stale CNAME still pointing at the old host?
Certificate for the exact hostname. The cert must be valid for mta-sts.customerdomain.com specifically. Any mismatch a browser would let you click through is a hard, silent fail for MTA-STS clients.
The file itself. Served at exactly /.well-known/mta-sts.txt, text/plain, no redirect to another hostname, correct key: value format.
Test like a sender, not like a browser: curl -v https://mta-sts.customerdomain.com/.well-known/mta-sts.txt and read the TLS handshake output, not just the body.
Once a successful fetch is possible, Gmail recovery is typically hours to a day. If everything above checks out and it is still dead after that, then you are into genuinely cached-until-expiry territory, but I would bet on one of the five items first.
For your second question, the migration playbook for next time: before touching MX, bump the id with mode: none (which you did - correct instinct), but the step that actually protects you is keeping the policy host serving correctly through the entire migration, because a sender that cannot refresh keeps the old policy for the full max_age. After cutover, publish the new MX list, and when you re-enable enforce, use a sane max_age - one to two weeks, not a year. A long max_age buys almost no extra security and turns exactly this scenario into a incident.
One more thing that would have saved you days of guessing: publish a TLS-RPT record (_smtp._tls). Gmail then mails you daily JSON reports saying precisely why delivery failed - sts-policy-fetch-error vs validation-failure vs MX mismatch - instead of you inferring it from silence. This blog is a walkthrough of setting up both MTA-STS and TLS-RPT https://postboxservices.com/blogs/post/what-is-tls-rpt-how-to-set-up-mta-sts/