← everything

They suspended my account, took my email server down with it, then told me to read the email they sent me

2026-08-04 · Account suspension

On August 4th, 2026, AWS suspended one of my accounts. That account ran my mail server.

The mailbox AWS used to notify me went dark with it.

Then AWS told me what to do about it. By email. To the mailbox they had just taken offline.

The part that should not be possible

Read the sequence slowly, because it is genuinely circular:

  1. AWS suspends the account.
  2. The suspension takes down the mail server.
  3. AWS sends notice of the suspension by email.
  4. The notice explains that to reactivate, I should read the email they sent.
  5. I cannot read email. They are the reason I cannot read email.

This is not an edge case anyone failed to anticipate. It is the single most predictable failure mode of "notify the customer by email" and it took me about four seconds to hit it.

There was no way out from the inside

The obvious move is to fix the billing problem. I could not:

  • I could not add another payment method. The account is suspended, so the billing console will not take one.
  • I could not upgrade my support plan. Buying support requires an account that is not suspended. The thing that would let me talk to a human was gated behind the thing that was broken.
  • Support answered in eighteen minutes, and could not tell me why. I opened a case at 18:10. The first reply came at 18:28. Over the next three days they wrote nine times. Not one of those messages said what I had done.

So the escalation path was: pay us to talk to us, except you cannot pay us, because we suspended you, and we told you about it somewhere you cannot look.

Update, August 8th. On August 5th I opened a second case asking one question: why was the account suspended, and what does AWS believe I did? As of today it has no reply and has not been assigned to anyone. The account was restored after 25 hours. I still have not been told why it was suspended, or why it was restored.

To be accurate about what did and did not happen: AWS support was responsive. They replied quickly, repeatedly, and by every appearance in good faith. This is not a complaint about response times, and paying for a support plan is what buys faster answers — that is the deal and I understand it. The complaint is that across two cases and twenty-four messages, nine of them from AWS, not one says what I did.

Update, August 11th. AWS answered the second case, six days after it was opened. The reply was boilerplate: it framed the suspension as an automated account-security check, said the uploaded documents had been accepted, and said the account was back in good standing. It answered neither question actually asked — why the account was suspended, or whether AWS accessed data during the 25 hours it was held. I replied the same day, in writing, restating both and adding a third: whether AWS took snapshots of that data, and under what part of the shared responsibility model that would be permitted. As of this update, every company I run is off AWS for anything but sandbox use — essential data no longer goes there.

What actually saved it: I own my DNS

Recovery took about 20 minutes, and AWS had nothing to do with it.

The MX records live in Cloudflare, under an API token I control. Repointing them is a scripted operation I can run myself, at 2am, on a weekend, without opening a ticket or waiting for anyone's approval. So I stood up a new mail server on GCP and repointed.

Here is the state mid-incident, measured rather than assumed:

CheckResult
Mail route affectedMX records pointed at the suspended account
MX for the affected mail10 mail.[redacted]
That host resolves toa new IP, outside AWS
whois on that IPGoogle LLC — the rebuild, already live
TCP/25Open: 220 mail.[redacted] ESMTP
RCPT TO:<me@[redacted]>250 2.1.5 recipient ok

That last line is the one that mattered. Twenty minutes after the suspension, inbound mail was being accepted again. No mail was lost.

Not because of a backup. Not because of a runbook. Not because of a support contract. Because the DNS was mine.

The lesson, stated plainly

Own your DNS, or you do not own your recovery.

Three things follow from that, and all three are worth acting on before you need them:

  • Never let the mailbox that receives provider notices depend on that provider. AWS's suspension notice was undeliverable by construction. Yours will be too, if your mail lives where your account lives.
  • A support plan is not a recovery path. When the account dies, your ability to buy support dies with it. Budget zero minutes of recovery time for vendor response, because zero is what you are going to get.
  • Own the switch you need in an outage. This recovery worked because DNS was outside the suspended account, under credentials I could still use.

To be completely fair to AWS

I want to be precise, because precision is the whole point of this site.

I do not know why the account was suspended, and AWS never told me in a channel I could actually read. It may well have been something legitimate. That is not the complaint.

The complaint is that there was no path back. Not a slow path. Not an expensive path. No path. Every door out of the problem was locked behind the problem itself — and the key was mailed to a house they had just demolished.

Post your story