My 36-Hour Email Black Hole (And What Google Taught Me About MTA-STS)

Pull up a chair, grab a fresh cup of coffee, and let me tell you about a fun little migration that gave me a few extra gray hairs this week.

If you’ve moved email platforms before, you know the dance. I’ve done plenty of these using imapsync, keeping passwords identical to make the transition as smooth as possible for the user. Usually, you check DNS, cross your fingers for clean vanity hostnames, update your MX, SPF, and DKIM records, and call it a day.

Except this time, I ran into a hidden tripwire: MTA-STS.

If you haven't run across it before, think of MTA-STS as a strict security guard for email servers. It forces sending servers to use a secure, encrypted connection to deliver mail to your domain, preventing bad actors from tampering with emails in transit. Great feature, right?

Well, this was my first time migrating a domain where MTA-STS was actively running. The client was using a third-party service to manage and monitor it. Once I spotted it, I jumped straight in: updated the policy file with the new mail servers, flipped the mode to testing, lowered the cache time (max_age), and waited for DNS propagation.

Everything looked rock solid. I fired off test emails from iCloud and Microsoft—both flew right through.

Then came Google.

Nothing sent from Gmail or Google Workspace arrived. No bounce-backs, no spam folder catches, zero log entries on our side. Just total silence.

Here’s the thing: when you change your MTA-STS policy, you update a tracking ID in your DNS. Senders like Google are supposed to see that changed ID, invalidate their cached copy of your old policy, and fetch the new one immediately.

Google didn't care. It ignored the new DNS ID entirely and kept trying to enforce the old policy against new mail servers.

After 24 hours down a rabbit hole of logs and header checks, I stumbled across a month-old Reddit thread. A fellow tech was describing my exact nightmare. His fix? He literally just had to sit on his hands and wait.

Sure enough, around the 36-hour mark, the dam broke. Google finally refreshed its cache, and every queued email from the last day and a half came flooding into the inbox. I fixed the outage by doing... absolutely nothing.

MTA-STS has been around since 2018, and moments like this remind me why a lot of organizations are still hesitant to adopt it. It's a fantastic security tool, but when major players like Google handle caching aggressively, one tiny mismatch can cut off your mail flow without warning.

The hard-won takeaway? Always check for MTA-STS before touching anything else. If it's active, switch the policy to testing mode at least 48 hours before you touch the MX records. Learn from my caffeine-fueled weekend so you don't have to live it!

Are you using MTA-STS on your domains and have you ever encounter an issue with MTA-STS?