Amazon WorkMail alternatives before the shutdown
AWS stopped accepting new WorkMail customers in April 2026 and ends support on 31 March 2027. What the deadline means, and how to plan the move.
AWS has decided to end support for Amazon WorkMail. This is not a rumour or a deprecation notice buried in a changelog — it is on the service's own documentation, with dates.
The dates
| Date | What happens |
|---|---|
| 30 April 2026 | WorkMail stops accepting new customers. Existing accounts continue. |
| 31 March 2027 | Support ends. The console and WorkMail resources become inaccessible. |
If you signed up before April 2026 you can keep using it until the second date. After that the console, the mailboxes, and the mail inside them are gone — this is a shutdown, not a read-only mode, so anything you have not exported by then is not recoverable.
What to do first, today
Export before you choose anything. The decision about a new provider can take a month; the export cannot start after the shutdown. AWS documents a mailbox export process that writes mailbox contents to S3, and running it early costs you almost nothing while leaving you with a copy that does not depend on the deadline at all.
Do it for every mailbox, including the ones nobody has opened in a year — those are usually
the shared addresses like billing@ where the invoices live.
What AWS suggests, and what it leaves out
The end-of-support notice points customers at Kopano Cloud, Zoho Mail and Zoom Mail, each of which offers migration tooling. Those are reasonable, and if you want the closest thing to a like-for-like Exchange-style replacement with calendars and ActiveSync, they are where to look first.
What the notice does not raise is whether you still need what WorkMail was. A lot of WorkMail accounts exist because a team was already in AWS and wanted mail on their domain without standing up a mail server. If that is the whole story, a forced migration is an unusually good moment to ask whether per-user pricing was ever the right shape for you — you are paying the migration cost either way, so you may as well land somewhere you would have chosen deliberately.
Choosing a replacement
- Do you use the calendar and ActiveSync parts? If yes, you need a groupware product, not a mail host.
- How many addresses versus how many people? WorkMail billed per mailbox, which is why most accounts have fewer addresses than they wanted.
- Is anything wired to WorkMail's API? Lambda triggers and SES integrations do not travel; budget for rewriting them.
- Where does the exported archive live afterwards? An S3 bucket nobody can search is not the same as mail history.
snailworkmail is the plain-mail answer to that list: real stored mailboxes with webmail, IMAP and SMTP, priced per domain rather than per mailbox, with addresses and aliases unlimited on the paid plan. It does not do calendars or ActiveSync — if you need those, take the Kopano or Zoho route instead. Being clear about that is more useful to you than winning the click.
How the cutover goes
Export first, then set up the new domain and confirm it works, then move MX, and only then close the AWS side. Concretely: add your domain at the new provider and add its verification TXT, SPF and DKIM records while WorkMail still holds the MX record. Nothing changes for your users during that step. When DKIM has propagated — allow up to 72 hours — switch MX, watch mail arrive for a few days, and keep the WorkMail account until you are certain.
The one thing not to do is wait for March 2027. Every migration guide competes for the same support queues in the final weeks, and DKIM propagation does not go faster because you are in a hurry.