How to Move from AWS WorkMail to Custom Email Without Message Loss

How to Move from AWS WorkMail to Custom Email: Step 1 – Mailbox Backup and S3 Export

A reliable migration requires keeping a cold, accessible copy of your email history before you alter mail exchange routing. If you want to know how to move from aws workmail to custom email safely, your first technical milestone is extracting your messages from AWS servers.

Method A: Asynchronous S3 Export via AWS CLI

AWS WorkMail provides an asynchronous export API that packages a mailbox into an industry-standard .pst file and deposits it directly into an Amazon S3 bucket. This requires an IAM role with write permissions to your target bucket.

First, create an S3 bucket in the same AWS region as your WorkMail organization (e.g., us-east-1). Attach an IAM policy granting WorkMail access to assume a role and push objects to that bucket. Once configured, execute the export command via the AWS CLI:

aws workmail start-mailbox-export-job \
    --organization-id "m-0123456789abcdef0123456789abcdef" \
    --entity-id "user-01234567-89ab-cdef-0123-456789abcdef" \
    --description "PreMigrationExport" \
    --role-arn "arn:aws:iam::123456789012:role/WorkMailExportRole" \
    --kms-key-arn "arn:aws:kms:us-east-1:123456789012:key/your-kms-key-id" \
    --s3-bucket-name "your-migration-backup-bucket" \
    --s3-prefix "workmail-backups/"

Check the export status until it marks complete:

aws workmail describe-mailbox-export-job \
    --organization-id "m-0123456789abcdef0123456789abcdef" \
    --job-id "export-job-identifier"

Once the status reads COMPLETED, download the .pst file from S3 to encrypted local storage. You now hold a complete historical record independent of AWS infrastructure.

Method B: Desktop Client IMAP Synchronization

If you prefer not to manage IAM roles, KMS keys, and the AWS CLI, you can pull your entire mail directory down using an IMAP client such as Mozilla Thunderbird or Apple Mail. This method is effective for mailboxes under 20 GB.

1. Open your IMAP client and add your WorkMail account using standard connection endpoints:
   • Inbound Server: imap.mail.us-east-1.awsapps.com (replace us-east-1 with your organization's region)
   • Port: 993 (SSL/TLS)
   • Username: Your full email address
   • Password: Your WorkMail user password or app-specific password
2. Ensure your client is set to sync all offline messages, not just the past 30 days.
3. Let the client complete the initial synchronization. Check folder by folder—Inbox, Sent, Archive, custom folders—to confirm message counts match the WorkMail web client.
4. Create a set of "Local Folders" in Thunderbird or an "On My Mac" mailbox hierarchy in Apple Mail. Copy (do not move) every folder from the WorkMail IMAP tree into these local directories.

This creates an offline, independent store of every email and attachment before any DNS records change.

How to Move from AWS WorkMail to Custom Email: Step 2 – MX, SPF, and DKIM Cutover

Once your messages are backed up, switch your routing. The goal during this stage of migrating email from aws workmail is to introduce the new receiving server while preserving outbound deliverability.

1. Update Mail Exchanger (MX) Records

In your DNS host, locate the MX records for your domain. When configured for WorkMail, an MX record points to an Amazon WorkMail regional endpoint:

example.com.   300   IN   MX   10 inbound-smtp.us-east-1.amazonaws.com.

Delete the Amazon WorkMail MX record and insert the MX record provided by your new custom email service. For example, if migrating to FolioInbox, add the corresponding mail exchanger host provided in your single-screen dashboard. Set the priority to 10. Because you previously reduced the TTL to 300 seconds, external MTAs will begin delivering new messages to your new inbox within minutes.

2. Reconfigure Sender Policy Framework (SPF)

SPF informs receiving servers which IP addresses or mail platforms are permitted to send messages from your domain. A typical AWS WorkMail SPF record looks like this:

v=spf1 include:amazonses.com ~all

If you are completely departing AWS for outbound transactional and personal mail on this domain, replace include:amazonses.com with your new provider's SPF directive. If you plan to retain Amazon SES for high-volume marketing scripts but want your personal business correspondence routed through your new inbox, combine them:

v=spf1 include:amazonses.com include:_spf.yournewprovider.com ~all

Caveat: rarely maintain more than one TXT record starting with v=spf1 on the same domain. Multiple SPF records cause receiving mail servers to return a PermError, which fails DMARC evaluation and sends your messages directly to spam. Also ensure your total SPF lookup count remains at or below the RFC-mandated limit of 10 DNS queries.

3. Establish Dedicated DKIM Keys

WorkMail handles DKIM through Amazon SES by providing three CNAME records pointing to Amazon infrastructure (e.g., abcde._domainkey.example.com CNAME abcde.dkim.amazonses.com). Leaving these pointed to AWS after decommissioning your organization will cause DKIM signatures to break.

Generate fresh 2048-bit DKIM keys at your destination provider. Add the new TXT or CNAME records to your DNS zone. Each domain you own must have its own distinct DKIM private key rather than borrowing a generic signature from a shared forwarder. Maintaining separate DKIM authentication per domain ensures your agency domain's reputation remains isolated from your e-commerce domain's reputation.

4. Review and Enforce DMARC

DMARC ties SPF and DKIM together. Ensure your domain has an active DMARC record at _dmarc.example.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100

DMARC compliance is an essential defense against spoofing. Official FTC phishing guidance highlights how attackers impersonate legitimate businesses using unauthenticated domains. If you are uncertain whether your records are configured properly, verify them with our free, ungated domain health audit.

Importing Historical Mail into Your Replacement Inbox

With DNS routing new inbound messages to your replacement system, your next objective is restoring historical threads. Having past emails available in your active inbox ensures seamless continuity when clients reply to conversations started months ago.

Using Imapsync for Server-to-Server Transfer

For automated mailbox synchronization, imapsync is a trusted, production-grade CLI tool. It transfers folders, flags (read, unread, flagged), and dates directly between IMAP servers without downloading messages to local disk.

Run a test run with the --dry flag, then execute the live transfer:

imapsync \
    --host1 imap.mail.us-east-1.awsapps.com \
    --user1 operator@example.com \
    --passfile1 /path/to/workmail-pass.txt \
    --ssl1 \
    --host2 imap.yournewprovider.com \
    --user2 operator@example.com \
    --passfile2 /path/to/newprovider-pass.txt \
    --ssl2 \
    --folderrec "INBOX" \
    --skipsize \
    --noauthinfo

Handling Edge Cases: Attachments and Folder Structures

During mailbox imports, be aware of three common issues:

• Attachment Size Constraints: AWS WorkMail supports message sizes up to 25 MiB. Many modern web mailboxes and alternative providers enforce different caps (for instance, FolioInbox enforces a 15 MiB per-message attachment cap). If you have historical emails containing oversized PDFs or raw media files that exceed your destination provider's limit, imapsync will return a message-size error for those specific items. Extract those large files locally and save them to cloud storage before migrating.
• Folder Name Mapping: WorkMail uses standard root folders like Sent Items and Deleted Items. Some mail systems look for Sent or Trash. When using imapsync or an IMAP client, map folder names manually so past sent messages land in your new system's native sent archive.
• Timestamp Preservation: Simple IMAP drag-and-drop actions can occasionally rewrite the internal delivery date to the current timestamp. Using automated tools like imapsync preserves the original RFC 822 date header and internal IMAP arrival times, keeping your message threads sorted chronologically.

Safely Decommissioning WorkMail and Cleaning Up AWS SES

Do not delete your WorkMail instance the hour you swap DNS. Inbound mail may still hit AWS servers for a few hours due to residual DNS caching across small, regional ISPs. Allow a 72-hour burn-in period where both your old backup and your new inbox exist simultaneously.

Once 72 hours have passed without new mail arriving in the WorkMail console, follow the operational procedures outlined in the AWS WorkMail Administrator Guide on removing domains:

1. Remove Mailbox Users: You cannot detach a domain from an AWS WorkMail organization if users, aliases, or groups are still bound to that domain. Go to Users in WorkMail, edit each user identity, and delete or reassign all aliases referencing your custom domain.
2. Disassociate the Domain from WorkMail: Navigate to Domains inside the WorkMail organization. Select your custom domain and click Remove.
3. Clean Up Amazon SES Identities: WorkMail automatically provisions identity verification inside SES. Open the Amazon SES console, navigate to Configuration > Verified Identities, and locate your domain. If you are no longer using SES for system transactional delivery, delete the identity to clean up DNS checks.
4. Delete Route 53 Verification Records: If Route 53 manages your DNS, remove the old CNAME records generated by AWS WorkMail and SES (such as the three dkim.amazonses.com CNAMEs and any AWS-specific ownership verification TXT records). Leaving orphan records creates confusion during future audits.
5. Shut Down the WorkMail Organization: Once all custom domains and users are removed, navigate back to the main WorkMail console, select the organization, and click Delete. If you used an AWS Directory Service Simple AD directory created solely for WorkMail, delete the directory as well to prevent ongoing hourly charges on your AWS bill.

Selecting the Right Custom Email Architecture for a Single Operator

Once you decide to move away from WorkMail, you need an architecture that matches how you run your business. Solo founders and portfolio operators typically fall into one of three traps:

1. The Google Workspace Per-Seat Multiplier: Paying a measurable budget per user per month across five separate Google Workspace accounts costs a measurable budget each month (a measurable budget per year) for one person checking their own mail. Setting up secondary domains inside a single Google Workspace account forces all outbound emails to share one primary user identity, which risks mixing corporate branding and makes clean separation impossible.
2. Consumer Gmail 'Send-As' Routing: Forwarding emails from multiple domains into a free @gmail.com account and configuring "Send mail as" via SMTP is fragile. When you send email through an external relay this way, the message headers often expose your personal Gmail address in the Sender or Return-Path headers. Worse, SPF and DMARC alignment frequently fail because consumer relays do not sign custom DKIM keys cleanly for secondary domains. Official FTC guidance on online data collection notes the risks of personal contact data sprawl, which this setup exacerbates.
3. Low-Cost Shared-Identity Forwarders: Forwarding services can deliver inbound mail, but outgoing email either breaks DMARC or requires you to configure external SMTP providers, leaving you with two distinct systems to maintain for every single domain you register.

For independent founders, the ideal setup is an inbox designed specifically for a single operator managing multiple custom domains. That means flat pricing per plan rather than per-seat pricing, coupled with independent cryptographic keys (DKIM) and dedicated signatures for every domain you manage.

Folio is a single-operator inbox, not a team or shared mailbox — there are no per-user seats and no team collaboration features. It was engineered specifically for multi-LLC owners, portfolio entrepreneurs, and solo consultants who need distinct brand identities without managing enterprise infrastructure.

Consider the math: managing 8 custom domains across independent Google Workspace accounts costs $57.60 every month ($691.20 annually). On FolioInbox Studio, that same 8-domain portfolio costs $12 per month billed annually ($144 per year), delivering a distinct DKIM key and signature for every individual domain from one unified interface. You can calculate your specific portfolio expenses using our email cost calculator.

Folio is a fully hosted service and cannot be self-hosted or run on your own servers or infrastructure. Folio is a proprietary, hosted service; its source code is not public. Folio encrypts mail in transit (TLS) and at rest, but is not end-to-end or zero-knowledge encrypted: mail is stored server-side and readable by Folio for spam filtering and search. Authentication uses modern passwordless access via magic link or passkeys. For domains hosted at registrars supporting Domain Connect, Folio publishes your required MX, SPF, and DKIM records automatically in a single step, removing the need to manually copy and paste DNS strings.

Frequently Asked Questions

Will migrating off AWS WorkMail cause inbound email downtime?

No, if you stage the migration properly. By dropping your DNS TTLs to 300 seconds 48 hours prior to cutover, MTAs update their routing quickly. While your new MX records propagate, any message delivered to the old AWS MX destination simply lands in your existing WorkMail mailbox. As long as you leave your WorkMail user active for 72 hours after updating your MX records, you can sync remaining delta messages to your new destination with zero message loss.

How do I export my WorkMail mailbox if I do not know how to use the AWS CLI?

You can connect Mozilla Thunderbird or Apple Mail to your WorkMail account using standard IMAP settings (port 993 with SSL). Once the client syncs all historical folders from the server, copy those folders into "Local Folders" on your computer. This saves a local copy of your mail history without touching the command line, IAM policies, or S3 buckets.

Do I need to delete my AWS Route 53 hosted zones when I leave WorkMail?

No. Route 53 is a DNS management system independent of WorkMail. You can keep your Route 53 hosted zones active to manage your domain names, web servers, and DNS records while pointing your MX, SPF, and DKIM entries to your new custom email host. You only need to delete the specific DNS records created by WorkMail and SES that you are no longer using.

Why does sending from multiple domains through basic email forwarding break DMARC?

Basic email forwarding services receive a message on one domain and forward it to another inbox (such as a personal consumer address). When you send a reply through that personal account using an alias, the outgoing email is sent through the consumer host's servers rather than your domain's authorized infrastructure. Because the sending server's IP address is not listed in your domain's SPF record and the email lacks a cryptographic DKIM key signed by your custom domain, receiving mail platforms fail DMARC verification and send your message to the spam folder.

Verify your current domain authentication setup in seconds with our free, ungated audit tool at /tools/domain-health, or calculate your multi-domain hosting costs before you switch.