I am an ex AWS Community Builder. I had the badge, the Slack channel access, and the mild compulsion to explain to strangers that yes, actually, WorkMail was fine.
And it was fine, which is the tragedy, that isn't Stockholm syndrome talking. The pitch was narrow and it landed, at least for me: native Outlook support and Exchange-shaped behavior — calendars, free/busy, mobile sync that just worked — without buying into the entire Microsoft 365 apparatus and the licensing spreadsheet that comes with it. Four dollars a user. Fifty gigs. Data in a region I picked, encrypted with a KMS key I held. If you needed Outlook on the desk but did not need Teams, WorkMail was the only managed email service I ever used that appeared to grasp that a person might want just email.
Then, on the last day of March, AWS put it on the list.
Not a list. The list. Fourteen services and features got sunset or shoved into maintenance mode in a single availability update, and WorkMail went out alongside RDS Custom for Oracle, the WorkSpaces Thin Client, and something called the AWS Service Management Connector, which I had to read three times to satisfy myself it wasn't placeholder text somebody forgot to replace. In the words of Corey Quinn, "getting the Old Yeller treatment in one blog post is a bold move" — his read, in Last Week in AWS issue #466, being that somebody at Amazon had finally gone and checked the usage metrics. No new customers after April 30, 2026, console goes dark March 31, 2027.
The community did get loud about it, which surprised me until I read what people were actually upset about. Nobody was mourning WorkMail. They were doing arithmetic on their own dependencies. App Runner's deprecation had leaked earlier in the year and then been walked back; CodeCommit was deprecated and subsequently resurrected. Fourteen at once reads less like lifecycle management and more like a policy change, and once you have had that thought you cannot stop having it about every service you rely on.
The reaction to WorkMail specifically was closer to anthropological: wait, people were using that?
Reader: I was people. I was, by some estimates, a statistically significant fraction of people.
Stages of grief, abbreviated
I sat on it for a while, in the manner of anyone handed a deadline eighteen months out. Then a weekend arrived with nothing in it and I made the mistake of opening the migration guide being on painkillers from a surgery I had in the weeks before.
AWS's own guidance suggests third-party landing spots like Kopano Cloud and Zoho Mail. These are perfectly reasonable, WorkMail-shaped replacements from vendors who have every incentive to make the move painless. I looked at them for 6-7 minutes and went to Proton Mail instead, which is the kind of decision that in retrospect sounds principled for some people and looked a lot like spite at the time.
To be clear about the principle, since everyone assumes they know it: I did not have a road-to-Damascus moment about surveillance capitalism ( in a similar move I decided to upgrade my iPhone instead of buying a Fairphone ). That's the reason people cite and it's a perfectly good one, but it isn't mine and I'm not going to borrow it to sound better. Mine was narrower and maybe nerdier. I wanted my mail under Swiss jurisdiction rather than in a bucket subject to whatever the current American legal weather happens to be. I also wanted the cryptography to be a library I could actually read ( not that I could, but I can feed the code to Claude using Fable and let it explain it to me ) — Proton maintains OpenPGP.js in the open, third parties audit it, and when I have a question about what is happening to my mail I can answer it by reading source instead of reading a trust page written by the marketing department.
That's the whole thesis. Everything else was a tiebreaker.
The road not taken, and why I did not take it
I bet you wonder why didn't I go self host!? I know. I could have run iRedMail on an EC2 instance. Postfix, Dovecot, Rspamd, a Let's Encrypt cron job, and total sovereignty over every byte. It's good software. I've done it before. The knowledge is still in there somewhere, filed next to my Sendmail trauma.
Here's what that weekend looks like instead. EC2 blocks outbound traffic on port 25 to public addresses by default, so before you can send a single message you get to sign in with your root account credentials and fill in the Request to Remove Email Sending Limitations form, explaining to Amazon in the Use Case Description field why you, personally, should be trusted with SMTP. Approval is discretionary. People get denied. There are re:Post threads about this that read like hostage negotiations. You'll also want an Elastic IP with a reverse DNS record, which is a separate request, because the modern internet has decided that an EC2 IP address sending you mail is guilty until proven otherwise and Microsoft will cheerfully drop your messages into a void with no bounce and no appeal.
Then you own it. Forever. Patching, spam filtering, backups, become your own problem, and at some point in a year or two a disk fills up at 3 a.m. and your mail server stops accepting mail and you find out about it because a client texts you, because you are a one man shop and you don't implement the observability you do for your clients.
And then money wise it doesn't work. A right-sized instance, EBS, snapshots, and an Elastic IP land you in the neighborhood of a few Proton seats before you have spent one minute of your own time, which — and I say this with love for everyone who has ever hand-tuned a Postfix main.cf — is not free. I'm too old for this. I'd rather pay someone in Switzerland.
Self-hosting genuinely wins in exactly two cases. You need total control of the server, or you have data residency requirements tight enough that "Swiss company, Swiss datacenter" doesn't clear the bar and only "this rack, this jurisdiction, this contract" will. Those are real requirements and if you have them, none of the above applies and you should stop reading. Everyone else is choosing a hobby, not an architecture.
Step one: admit that WorkMail was doing three jobs
WorkMail was three products in a trench coat, and only one of them is email.
- Human mailboxes. This is the part you migrate.
- Email flow rules with a Run Lambda action. This is not email. This is a workflow engine that convinced you it was email.
- Transactional sending for some app you shipped in 2019 and have not thought about since.
If you are number three: STOP. Go outside. That should have been going through SES the whole time, and the only reason it wasn't is that you had a working SMTP endpoint and no supervision. Verify the domain in SES, point the app at it, remove it from the migration checklist. Proton is not your application's SMTP relay, and treating it like one is how you end up reading bounce logs at 1 a.m. while questioning your career.
If you are number two: keep SES as well, and take a moment to appreciate that you already were. Inbound mail arrives at Amazon SES first and is handed to WorkMail afterward — if SES blocks a message, your flow rules never see it. SES has been standing in front of your mail server this entire time, quietly, like a bouncer you forgot you hired.
Proton, needless to say, has no equivalent to a Run Lambda rule. You configured those in the WorkMail console, picked your sender and recipient patterns, and your function fetched the message body through the workmailmessageflow API. There is no CLI verb for any of it, which tells you something about how much AWS expected you to be doing this. It was an AWS-flavored appendage grafted onto email, not a feature of email, and nothing outside AWS is going to replace it. Route the automated addresses to SES receiving rules, keep the Lambda, let Proton handle the humans.
What survives this triage is invariably smaller than what you feared. Mine went from eleven mailboxes to seven, and two of the four casualties were aliases nobody had sent to since the Trump administration. The first one.
Get your data out before you touch DNS
WorkMail ships a native export. Use it — not because you'll import from it, but because you want a cold copy in S3 before you start moving load-bearing DNS records around.
aws workmail start-mailbox-export-job \
--organization-id m-a123b4c5de678fg9h0ij1k2lm234no56 \
--entity-id S-1-1-11-1111111111-2222222222-3333333333-3333 \
--role-arn arn:aws:iam::111122223333:role/WorkmailMailboxExportRole \
--kms-key-arn arn:aws:kms:eu-west-1:111122223333:key/KEY-ID \
--s3-bucket-name my-workmail-escape-hatch \
--s3-prefix exports/alice/ \
--client-token $(uuidgen)
Prerequisites, because AWS would never let you have a nice thing unmediated: an S3 bucket with public access blocked, a symmetric KMS key, and an IAM role that export.workmail.amazonaws.com is permitted to assume. The trust policy scopes to aws:SourceArn for a single organization, though you can drop that condition and reuse the role across several. It is about fifteen minutes of policy-wrangling per organization, not per user, which by AWS standards qualifies as a delightful surprise.
Loop it over your entity IDs, walk away, return to a bucket full of .zip files containing MIME-format messages.
Now, two things before you call this a backup and go to bed.
It exports email and calendar items only. Contacts and tasks do not come along. This is documented, in the sense that it is written down somewhere you were never going to look. Also, the job runs over a period of time rather than capturing the mailbox at an instant, so it is emphatically not a snapshot — mail arriving mid-export lands wherever it lands. Poll describe-mailbox-export-job for progress, and be aware that list-mailbox-export-jobs will only show you the previous seven days, because retention is a feature you pay extra for elsewhere.
Full procedure, trust policy JSON included: Exporting mailbox content and the start-mailbox-export-job CLI reference.
This is your insurance. It is not your migration path. Your migration path is IMAP, like it was before Y2K.
Migration is boring, which is the entire point
Proton's Easy Switch handles generic IMAP sources, not merely the Gmail and Outlook boxes its marketing page is excited about. WorkMail is a generic IMAP source. Feed it:
- Host:
imap.mail.<region>.awsapps.com - Port:
993, TLS - Username: the full address
- Password: the account password
It runs server-side, chews through your folder hierarchy, and re-encrypts everything on arrival. For a 40 GB mailbox with a decade of nested folders named things like Archive/2019/misc/actually-important, budget most of a day and — this is the important part — do not watch it. Nothing good has ever come from watching a mailbox sync.
If you'd rather drive, imapsync speaks fluently to both ends and gives you folder filtering and a log file that tells you the truth. I ran imapsync on the two mailboxes I actually cared about and let Easy Switch handle the rest, on the theory that a tool you can debug is worth more than a tool you can trust. Both landed clean, which was mildly disappointing. I prepared mentally I might need to tell my wife that I will not watch a movie with her that weekend.
DNS: twenty minutes that determine your weekend
Drop your MX TTL to 300 or smaller the day before cutover. Everyone forgets this. You will forget this. Then, in Proton's admin console, collect:
- A
protonmail-verification=TXT record - MX at
mail.protonmail.ch(priority 10) andmailsec.protonmail.ch(20) - SPF:
v=spf1 include:_spf.protonmail.ch ~all - Three DKIM CNAMEs
- A DMARC record, which you should have had for years, and we are not going to discuss it further
Add verification, SPF, and DKIM first. Leave MX pointed at WorkMail. Let it settle. Then swap MX. Keep the WorkMail organization breathing for a week afterward — it's four dollars a mailbox, the cheapest insurance policy in the history of the discipline — and run a delta sync at the end to sweep up whatever landed on the old side while the internet made up its mind.
Parts that will annoy you, ranked
No IMAP. No SMTP. Not really. Proton is end-to-end encrypted, which means your mail client cannot simply talk to it. You run Proton Bridge locally, which stands up a loopback IMAP/SMTP endpoint for your client to connect to. It works. It is also a daemon you must now think about, and if your team is on Thunderbird or Apple Mail, that conversation happens before the migration, not during it, unless you enjoy conflict.
Server-side search is different. Proton cannot index what it cannot read, which is the whole selling point, so search is client-side against a locally built index you download once. This is fine. It is not Exchange. If your workflow is "search fourteen years of mail from a hotel wifi on a borrowed laptop," recalibrate.
Storage math, honestly. WorkMail: $4/user/month, 50 GB. Proton Mail Essentials: $6.99/user/month billed annually, 15 GB. Proton loses that comparison on paper and I'm not going to pretend otherwise by adding up "value" until the number comes out right. It wins the comparison back only if you were already paying separately for a VPN, a password manager, or file storage, because Workspace Standard bundles the lot at $12.99. If all you want is a mailbox, you are paying a premium for Swiss jurisdiction and zero-access encryption. That is a legitimate thing to buy. Just know that's the transaction.
Calendar interop. Remember those free/busy lookups I was bragging about four hundred words ago? Gone. Proton Calendar is end-to-end encrypted and handles invitations perfectly well, but there is no EWS endpoint for Outlook to interrogate and there is not going to be one. This was the single hardest thing to surrender. If your organization schedules meetings by staring at a grid of everyone's availability, price that in before you commit, and possibly consider scheduling fewer meetings.
Was it worth it!?
I did not leave WorkMail on principle. I left because Amazon deprecated it and I was given a deadline. The principle only decided where I landed, which I suspect is true of most principles.
But the migration forced the triage I'd been avoiding for four years: the app mail that should have been SES, the alias nobody had touched since 2021, the "team" mailbox that was, on closer inspection, one person. The cutover consumed a weekend. The only casualty was an email flow rule I wrote in 2018 and am still not certain ever did anything.
The Community Builder badge expired anyway, but who knows maybe this article will get me back into the program next year?
Note: If you're still using WorkMail, you have until March 2027 and you should not use all of it. DNS propagation is patient. Your users are not. And AWS has now established, conclusively, that "it's been running for a decade" is not a support commitment.
Top comments (0)