AWS WorkMail EOL — timeline and what it means
AWS published the end-of-support notice on the official WorkMail documentation page. Two dates are irrevocable: April 30, 2026 — no new customer sign-ups; March 31, 2027 — all accounts, mailboxes, calendars and contacts are deleted, with no recovery possible after that date.
In practice, WorkMail resources become inaccessible on April 1, 2027: the AWS console, APIs, IMAP clients and Exchange ActiveSync connectors all stop responding simultaneously. AWS has not announced any extension or post-date read-only mode. Anything not exported before March 31, 2027 is permanently lost.
The urgency depends on your mailbox volume: a 10 GB mailbox can take several hours to export to S3, and the imapsync IMAP migration takes time proportional to the number of messages. Starting the migration three months before the deadline is a reasonable minimum. Ideally, the DNS cutover should be completed before the end of January 2027, leaving enough time to monitor deliverability and fix any issues before the definitive deletion.
Why Mailcow rather than Stalwart or another alternative
AWS itself recommends Kopano Cloud, Zoho Mail and Zoom Mail as alternatives. These solutions remain SaaS — you switch providers without regaining control.
If you want an email infrastructure you fully control, Mailcow is the most proven option for migrating from a hosted email service. Its Docker Compose stack combines Postfix, Dovecot, Rspamd and SOGo in a unified administration interface. IMAP migration is well documented, the community is active, and native IMAP inbound support makes importing with imapsync straightforward.
Stalwart is a serious alternative (see the dedicated article), but its single-binary architecture is better suited to a fresh installation than to a migration from WorkMail — support for importing existing IMAP mailboxes is less mature at the time of writing. For a WorkMail migration, Mailcow is the pragmatic choice.
Prerequisites before you begin
Three resources are required before starting the migration:
VPS with at least 6 GB of RAM. The Mailcow stack (Postfix, Dovecot, Rspamd, MariaDB, Redis, ClamAV, SOGo and the nginx proxy) consumes around 3 to 4 GB under normal load. With 6 GB, you have a comfortable margin for imapsync and load spikes during migration.
Administrator access to the AWS WorkMail console. Mailbox export goes through the AWS API — you need sufficient IAM rights to create an export role, access S3 and trigger export jobs via the CLI.
A domain name with DNS access. The DNS cutover (MX, SPF, DKIM, DMARC records) is the final step — without access to your DNS zone, you cannot redirect inbound mail to Mailcow.
Detailed prerequisites list
- 64-bit Linux VPS (Debian 12 or Ubuntu 22.04 recommended), minimum 6 GB RAM / 2 vCPU / 40 GB storage.
- Dedicated IP with PTR (reverse DNS) configured to match the mail server hostname.
- Outbound port 25 unblocked by your hosting provider — check before ordering.
- Ports 25, 465, 587, 993 and 143 open in the VPS firewall.
- AWS IAM access with
workmail:StartMailboxExportJob,s3:PutObjectandkms:GenerateDataKeyrights. - A private S3 bucket in the same AWS region as your WorkMail organisation.
- A symmetric KMS key in the same region (required by the WorkMail export API).
- DNS access to the domain to modify MX, SPF, DKIM and DMARC.
- Docker and Docker Compose installed on the target VPS.
Exporting your AWS WorkMail data
Create the IAM role and export policies
The WorkMail export requires a dedicated IAM role. Create two local JSON files:
mailbox-export-trust-policy.json(trust policy for WorkMail):{ "Version": "2012-10-17", "Statement": [{ "Sid": "", "Effect": "Allow", "Principal": { "Service": "export.workmail.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "YOUR-ACCOUNT-ID" } } }] }mailbox-export-policy.json(S3 and KMS rights): see the official documentation for the complete JSON with your bucket and KMS key ARNs.Create the role via AWS CLI:
aws iam create-role --role-name WorkmailMailboxExportRole --assume-role-policy-document file://mailbox-export-trust-policy.jsonaws iam put-role-policy --role-name WorkmailMailboxExportRole --policy-name MailboxExport --policy-document file://mailbox-export-policy.jsonRetrieve organisation and user identifiers
The export API requires the WorkMail organisation ID and entity ID for each user. Retrieve them from the AWS WorkMail console under Organizations → your org → Users, or via CLI:
aws workmail list-organizationsaws workmail list-users --organization-id m-XXXXXXXXXXXXNote the
OrganizationId(formatm-xxxxx) and theUserIdof each mailbox to export.Launch the S3 export job
Trigger one export job per mailbox:
aws workmail start-mailbox-export-job --organization-id m-XXXXXXXXXXXX --entity-id S-1-1-11-XXXXXXXXXX --kms-key-arn arn:aws:kms:us-east-1:ACCOUNT:key/KEY-ID --role-arn arn:aws:iam::ACCOUNT:role/WorkmailMailboxExportRole --s3-bucket-name your-bucket --s3-prefix exports/user1/The API supports up to 10 concurrent export jobs per organisation. For large organisations, launch exports in batches of 10 and wait for each batch to complete.
Monitor export job status
Check progress with:
aws workmail list-mailbox-export-jobs --organization-id m-XXXXXXXXXXXXOr for a specific job:
aws workmail describe-mailbox-export-job --organization-id m-XXXXXXXXXXXX --job-id JOB-IDWhen the status changes to
COMPLETED, the.zipfile is available in S3. The output log showstotalMessages,totalBytesandsha384Hashfor integrity verification.Download and verify exported files
Download the archives from S3:
aws s3 sync s3://your-bucket/exports/ ./workmail-exports/Verify the integrity of the downloaded archives. Each
.zipcontains emails in MIME format. Check that the file count matches thetotalMessagesfrom the export log:unzip -l workmail-exports/user1/*.zip | tail -1KMS encryption is transparent on the AWS side — files downloaded by a user with access to the KMS key are decrypted automatically.
Extract .eml files for imapsync
imapsync works IMAP-to-IMAP — it does not directly import
.zipor.emlfiles from disk. The recommended approach is to configure imapsync to read directly from the WorkMail IMAP server before access is cut off, rather than going through S3 archives.The S3 archives serve as a safety backup and for mailboxes that are no longer accessible via IMAP. To process
.emlfiles as a last resort, a temporary local Dovecot server can expose them over IMAP for imapsync.
Installing Mailcow on VPS
Prepare the VPS and configure the hostname
Set an FQDN hostname consistent with the future PTR record:
hostnamectl set-hostname mail.yourdomain.comVerify that
hostname -freturns the full FQDN. Configure the PTR for the VPS IP from your hosting provider's control panel — this PTR must exactly match the hostname.Clone Mailcow and run the installer
Refer to the dedicated article Host an email server on VPS with Mailcow for the full installation. In summary:
git clone https://github.com/mailcow/mailcow-dockerized /opt/mailcow-dockerizedcd /opt/mailcow-dockerized && ./generate_config.shdocker compose pull && docker compose up -dThe administration interface is available at
https://mail.yourdomain.comafter DNS propagation.Create domains and accounts in Mailcow
In the Mailcow interface (Configuration → Mail Setup), add the domain and create an account for each WorkMail user to migrate. Addresses must be identical to those in WorkMail so imapsync can match mailboxes.
Do not change the MX records yet — Mailcow can accept IMAP connections without being the active MX, which allows migration before the DNS cutover.
Migrating emails with imapsync
Install imapsync on the Mailcow VPS
On Debian/Ubuntu:
apt-get install -y imapsyncOr from the official repository for the latest version:
curl -L https://imapsync.lamiral.info/INSTALL.d/INSTALL.Debian.txt | bashVerify the installation:
imapsync --versionMigrate a WorkMail mailbox to Mailcow
The AWS WorkMail IMAP server in us-east-1 is
imap.mail.us-east-1.awsapps.com(port 993, SSL). Adjust the region if your organisation is in eu-west-1 (imap.mail.eu-west-1.awsapps.com) or us-west-2.`imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 [email protected] --password1 'WorkMailPassword' \
--host2 mail.yourdomain.com --ssl2 --port2 993 \
--user2 [email protected] --password2 'MailcowPassword' \
--automap --skipcrossduplicates --useuid`The
--automapoption automatically maps system folders (Sent, Drafts, Trash) between the two servers.--skipcrossduplicatesavoids duplicates if you re-run the migration.--useuiduses IMAP UIDs for accurate progress tracking.Migrate all mailboxes in parallel
For organisations with multiple users, run migrations in parallel with a script:
`while IFS=: read -r user pass_wm pass_mc; do
imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 "$user" --password1 "$pass_wm" \
--host2 mail.yourdomain.com --ssl2 --port2 993 \
--user2 "$user" --password2 "$pass_mc" \
--automap --skipcrossduplicates --useuid \
--logfile "/var/log/imapsync-$user.log" &
done < users.csv`Limit to 4 to 6 simultaneous migrations to avoid saturating bandwidth. Monitor logs in
/var/log/imapsync-*.log.Run a final synchronisation pass
While users continue using WorkMail, re-run imapsync one last time just before the DNS cutover to sync emails received since the first migration:
`imapsync \
--host1 imap.mail.us-east-1.awsapps.com --ssl1 --port1 993 \
--user1 [email protected] --password1 'WorkMailPassword' \
--host2 mail.yourdomain.com --ssl2 --port2 993 \
--user2 [email protected] --password2 'MailcowPassword' \
--automap --skipcrossduplicates --useuid --delete2duplicates`Thanks to
--useuid, imapsync only transfers messages absent from Mailcow.
DNS cutover — MX, SPF, DKIM, DMARC
Once the IMAP migration is complete and verified, the DNS cutover redirects inbound mail to Mailcow. Do not cut over before verifying deliverability (see the next section).
Step 1 — MX record. Replace the existing MX entry (pointing to WorkMail, e.g. inbound-smtp.us-east-1.amazonaws.com) with your Mailcow server:
yourdomain.com. MX 10 mail.yourdomain.com.
Verify propagation: dig MX yourdomain.com +short
Step 2 — SPF. Remove the WorkMail authorisation (include:amazonses.com or similar) and authorise your VPS:
yourdomain.com. TXT "v=spf1 mx a:mail.yourdomain.com -all"
Verify: dig TXT yourdomain.com +short | grep spf
Step 3 — DKIM. Mailcow generates DKIM keys from the interface (Configuration → Configuration & Details → ARC/DKIM Keys). Copy the generated TXT record into your DNS:
nslookup -type=TXT dkim._domainkey.yourdomain.com
Step 4 — DMARC. Update the DMARC policy. If a policy existed for WorkMail, replace the rua address and keep p=quarantine or p=reject if already in place:
_dmarc.yourdomain.com. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"
Verify: dig TXT _dmarc.yourdomain.com +short
Reduce the TTL of all these records to 300 seconds one hour before the cutover to speed up propagation.
Test deliverability before cutting AWS
Before changing the MX, send an email from Mailcow (via SOGo webmail or a client configured on port 587) and check the score on mail-tester.com — a score of 9/10 or above is the acceptable threshold for production.
Also verify with swaks from the VPS itself:
swaks --to [email protected] --from [email protected] --server mail.yourdomain.com --port 587 --auth LOGIN --auth-user [email protected] --tls
Inspect the headers of the received message — the Authentication-Results header must show spf=pass, dkim=pass and dmarc=pass. If any of the three is missing or failing, do not cut the MX — fix the failing DNS record first.
Also check that the VPS IP is not listed in a reputation database with dig +short TXT <reversed-ip>.zen.spamhaus.org (an empty response means a clean IP).
Troubleshooting — common imapsync and Mailcow errors
IMAP Command 'LOGIN' failed: 535 5.7.3 Authentication unsuccessful — WorkMail credentials are rejected. Verify that the password is the application password generated in the WorkMail console (not the SSO/federated password). If your organisation uses Active Directory or an external identity provider, IMAP credentials must be configured separately in WorkMail.
SSL connect attempt failed error:14090086 — Incompatible TLS version or expired certificate on one of the servers. Add --ssl1 --tls1 to force TLS 1.2, or --notls1 --ssl1 to force direct SSL. Check the Mailcow certificate with openssl s_client -connect mail.yourdomain.com:993.
Can't login to host2... Connection refused on port 993 — Mailcow is not yet listening on the IMAPS port. Check that all containers are running with docker compose -f /opt/mailcow-dockerized/docker-compose.yml ps. The dovecot-mailcow container must be Up.
Quota exceeded on host2 — The destination mailbox has reached its quota limit in Mailcow. Increase the quota from the Mailcow interface (Configuration → Mail Setup → Mailboxes) before re-running imapsync.
Very slow migration or random disconnections — imapsync can be slowed by network latency between the VPS and AWS servers. Add --maxbytespersecond 500000 to limit throughput and avoid timeouts. Run imapsync inside a screen or tmux session to avoid interruptions if the SSH connection drops:
screen -S migration imapsync ...
Conclusion — act before March 31, 2027
The closure of AWS WorkMail is a final decision. The migration window is short: between DNS propagation, deliverability verification and IMAP migration of large mailboxes, budget one to two weeks of work for a small-to-medium organisation.
The safest path is the one described here: first export data to S3 (an irreversible backup before any manipulation), migrate emails via imapsync while WorkMail is still active, validate deliverability on Mailcow before cutting over, then switch the MX and deactivate WorkMail accounts.
For large organisations with dozens of mailboxes and high volumes, plan a coexistence period of two to four weeks where both systems are active, with automatic forwarding of WorkMail messages to Mailcow via a forwarding rule, before the final DNS cutover.
