Executing an AWS WorkMail End of Support Migration Across Multiple Domains

What Breaks During an AWS WorkMail Shutdown: MX, DKIM, and Mail Storage

Executing an AWS WorkMail end of support migration requires understanding the exact protocols that fail when an email organization is retired. Mail delivery relies on a coordinated handshake between DNS routing, cryptographic signatures, and transport storage. An unplanned AWS WorkMail shutdown breaks this chain across three critical layers.

First, inbound transport breaks instantly when MX records pointing to AWS endpoints stop accepting packets. If your domain's DNS zones still point to inbound-smtp.mail.REGION.awsapps.com after the routing cutoff, remote Mail Transfer Agents (MTAs) typically attempt redelivery for several days before dropping the messages and generating non-delivery reports (NDRs) to the sender. Senders receive bounce notifications, and time-sensitive transaction alerts or client inquiries disappear permanently.

Second, outbound authentication alignment collapses. Under IETF RFC 6376, DomainKeys Identified Mail (DKIM) requires a valid digital signature linked to the sender's domain. WorkMail managed outbound DKIM by generating public keys hosted under CNAME records pointing back to AWS infrastructure. Once an organization deactivates, those DNS selectors stop resolving valid public keys.

If you reroute outbound mail through another SMTP relay without configuring new, isolated DKIM keys for each custom domain, modern receiving providers will flag or drop your messages. Custom domain senders must maintain domain-aligned DKIM and valid SPF to avoid spam folder placement or outright message rejection across major receiving networks.

Third, message storage access terminates. WorkMail stores mailboxes inside a managed Directory Service container. Unlike Amazon EC2 instances, where an operator can take an EBS snapshot, WorkMail does not provide a single-click image backup of an entire multi-domain organization. Administrators must actively extract mailboxes via IMAP sync tools or schedule AWS CLI mailbox export jobs to an Amazon S3 bucket before decommission. Note also that storage ceilings and message constraints vary between platforms: while traditional email gateways often allow larger individual payloads, Folio caps attachments at 15 MiB per message. Stored messages containing large attachments must be reviewed during migration planning to avoid delivery rejections.

The Step-by-Step AWS WorkMail End of Support Migration Process

A controlled migration eliminates message loss and prevents deliverability downgrades. Follow this step-by-step procedure to transition your portfolio of custom domains cleanly.

Step 1: Lower DNS TTL Values 48 Hours in Advance

Log in to your DNS provider—whether Route 53, Cloudflare, Namecheap, or Porkbun—and locate your custom domains. Review the Time to Live (TTL) values on all active MX, TXT (SPF), and CNAME (DKIM) records. Default TTLs are often set to 86400 seconds (24 hours) or 3600 seconds (1 hour). Reduce all email-related TTLs to 300 seconds (5 minutes). This ensures that when you swap MX records during cutover, external MTAs discover the new destination within minutes rather than caching dead AWS routes for an entire day.

Step 2: Sync Mailbox Contents Over IMAP

Because AWS WorkMail supports standard IMAP access, you can run an offline synchronization utility to duplicate your message hierarchy, sent folders, and archived mail. Standard tools such as imapsync provide reliable, repeatable transfers:

imapsync \
  --host1 imap.mail.us-east-1.awsapps.com --user1 user@yourprimarydomain.com --passwork1 "WorkMailSecretPass" \
  --host2 imap.destination-mail.com --user2 user@yourprimarydomain.com --passwork2 "DestinationSecretPass" \
  --syncinternaldates --skipcrossduplicates

Execute an initial baseline sync several days before the cutover date. Because a full sync across several gigabytes of historical data can take hours, running the heavy transfer in advance leaves only a tiny delta to sync during final cutover.

Step 3: Provision Recipient Addresses and Identities in the Destination Inbox

Before touching your public MX records, recreate all active user addresses, routing aliases, and catch-all behaviors inside your destination platform. If you manage multiple domains, configure distinct identities for each entity so you can send from billing@brandone.com and hello@brandtwo.com without cross-identity leaks. Where supported, modern setups use the Domain Connect Specification to automate DNS record publication directly at compatible domain registrars, bypassing manual copy-pasting of cryptographic keys.

Step 4: Execute the MX and DKIM Cutover

With identities provisioned and preliminary mailbox data staged, update your production DNS records:

1. Update MX Records: Replace the AWS WorkMail endpoint (e.g., 10 inbound-smtp.mail.us-east-1.awsapps.com) with your destination provider's designated MX endpoints.
2. Deploy Independent DKIM Keys: Add the 2048-bit DKIM public key TXT or CNAME records provided by your new host. Ensure each individual domain possesses its own distinct selector and cryptographic key pair.
3. Modernize SPF Records: Update your root domain TXT SPF record. Remove include:auth.smtp.mail.us-east-1.awsapps.com and replace it with your destination provider's include mechanism. Avoid listing more than one SPF string per domain.

Step 5: Transition Routing Aliases and Perform Final Delta Sync

Run a final delta sync with imapsync to pull across any new messages that arrived during the DNS propagation window. Confirm that catch-all addresses and secondary aliases receive test messages correctly across every domain in your portfolio.

Selecting the Right Destination Architecture for Solo Multi-Brand Operators

Consolidating several business entities into a workable email architecture requires matching your operational habits against provider capabilities. Choosing between modern platforms comes down to how many domains you operate and whether you need an office productivity suite.

If you build terminal-based workflows, use Sieve mail filtering scripts, or require absolute control over custom IMAP ports, developer-focused hosts like Migadu or Fastmail offer extensive protocol-level configuration. Fastmail provides web and mobile applications with robust alias management, though its pricing scales on a per-user basis that increases as you add discrete accounts.

If your businesses depend deeply on real-time collaborative spreadsheets, enterprise identity management via Google Cloud Identity, or integrated video conferencing, Google Workspace or Microsoft 365 are unavoidable investments. However, for a solo operator maintaining separate Workspace accounts primarily to keep a consulting brand distinct from an e-commerce holding company, paying for redundant collaboration seats and enterprise storage tiers adds expense for capabilities a single person does not use.

When you are an individual operating several distinct commercial brands, an architecture built specifically for portfolio operations is significantly simpler. Folio is a single-operator inbox, not a team or shared mailbox — there are no per-user seats and no team collaboration features. Instead of managing multiple logins or juggling complex "send as" aliases that break SPF and DKIM authentication, a single operator can send and receive across multiple custom domains from one interface, with a distinct signature and independent, domain-aligned DKIM key generated for each entity.

Security architecture also matters when centralizing multiple business brands into a single operational interface. To ensure inbox safety, FTC phishing guidance recommends treating unexpected messages and requests for personal information with caution across all active addresses. 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. As documented in its published product specifications, Folio is a proprietary, hosted service whose source code is not public. Folio is a fully hosted service and cannot be self-hosted or run on your own servers or infrastructure, as documented in its product capabilities contract. Authentication is handled via magic link or secure passkey, eliminating legacy password vulnerabilities entirely.

Post-Migration DNS Checklist: Verifying SPF, DKIM, and DMARC Alignment

Once your MX records point to your new destination host, an unhurried verification of your domain authentication setup ensures messages land reliably in client inboxes rather than spam folders.

1. Audit SPF String Syntax and Lookup Limits

Under IETF RFC 7208, SPF validation fails if a domain requires more than 10 total DNS lookups during resolution. Stacking multiple third-party services (such as WorkMail, SES, Shopify, and an email newsletter tool) inside a single record easily triggers the PermError lookup limit. Clean out dead AWS WorkMail mechanisms completely:

# Incorrect: Legacy WorkMail record left lingering alongside new host
v=spf1 include:auth.smtp.mail.us-east-1.awsapps.com include:_spf.folioinbox.com ~all

# Correct: Cleaned record referencing only active senders
v=spf1 include:_spf.folioinbox.com ~all

Ensure that each custom domain has exactly one v=spf1 record. Having multiple SPF TXT records on a single domain violates protocol specifications and causes immediate authentication failures across strict receiving servers.

2. Confirm Cryptographic DKIM Alignment Across All Entities

Send an individual test message from every custom domain you control to an external diagnostic address or personal Gmail account. Inspect the raw message headers (select "Show original" in Gmail). Verify that:

• The DKIM-Signature header contains an s= selector matching your destination provider's records.
• The d= domain tag in the signature matches the exact domain shown in the visible From: header (RFC 6376 strict/relaxed alignment).
• The verification status reads dkim=pass.

3. Modernize DMARC Policies

Domain-based Message Authentication, Reporting, and Conformance (IETF RFC 7489) unifies SPF and DKIM. During the first 72 hours of an AWS WorkMail end of support migration, maintain a monitoring policy:

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

The p=none policy allows you to collect aggregate reports without risking false-positive rejections while DNS changes propagate globally. Once your diagnostic tools show consistent DKIM and SPF pass rates across legitimate outbound traffic, elevate your DMARC record to an enforcement state:

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

Enforcement protects your business reputation by telling receiving mail servers to quarantine or reject unauthenticated messages spoofing your domain name. Before terminating your old AWS organization, run your domains through the deliverability audit at /tools/domain-health to test your SPF, DKIM, DMARC, and MTA-STS records in a single check without an email gate.

Executing the Decommission: Safely Disabling AWS WorkMail and Clean-up

After your new mailboxes have received traffic for at least 72 hours with zero bounce reports, you can safely shut down your legacy AWS resources to stop recurring billing and eliminate orphaned records.

1. Disassociate Domains in WorkMail: Navigate to the AWS WorkMail console. Select your organization, navigate to Domains, and click Remove. This releases internal ownership locks on the domain names inside AWS Directory Service.
2. Clean Orphaned Route 53 Records: Open the Route 53 console. Locate your hosted zones and delete stale AWS WorkMail verification TXT records, obsolete MX records, and orphaned CNAME records associated with AWS DKIM selectors. If you use Amazon SES separately for programmatic transactional application email, take care to leave your active SES verification records untouched.
3. Remove Active WorkMail Organizations: Under the WorkMail console, select your organization, click Organization actions, and choose Disable. Once disabled, select Delete. This terminates directory hooks and cancels recurring per-user monthly charges.
4. Delete Managed Directory Service Instances: If WorkMail created a dedicated AWS Managed Microsoft AD or Simple AD directory that is not utilized by other AWS resources (such as Amazon WorkSpaces or EC2 instances), delete the directory under the Directory Service console to avoid ongoing directory hosting fees.
5. Monitor 7-Day Bounce Rates: Keep a close eye on customer support inquiries and operational alerts over the following week. If an obscure sub-brand or legacy forwarding rule was missed during discovery, check your registrar logs immediately to route the remaining traffic into your primary operational inbox.

Frequently Asked Questions

What happens if I do not migrate off AWS WorkMail before the end of support date?

If you fail to migrate before the shutdown date, AWS will terminate inbound SMTP access. Mail servers worldwide attempting to deliver email to your addresses will receive persistent 500-series hard bounces, resulting in dropped messages that cannot be recovered. In addition, user access to webmail, IMAP, and POP3 endpoints will be revoked, making mailbox contents inaccessible unless an S3 export was scheduled prior to the purge.

Can I keep Route 53 for DNS while routing custom domain email to another provider?

Yes. Route 53 is an independent, highly resilient authoritative DNS service. You do not need to move your domain registration or DNS hosting away from Route 53 to migrate your email away from AWS WorkMail. You simply edit the MX, TXT (SPF), and CNAME (DKIM) records inside your existing Route 53 hosted zones to point to your new email provider.

How does an AWS WorkMail migration affect my existing AWS SES transactional sending?

AWS WorkMail and Amazon Simple Email Service (SES) share underlying mail infrastructure but operate with separate configuration controls. Decommissioning WorkMail does not break your SES transactional sending, provided you do not accidentally delete the SES identity verification records or SES-specific DKIM CNAME strings inside your DNS zone. When cleaning your DNS records, verify every SES selector before deleting legacy WorkMail records.

Will migrating multi-domain email require my clients to re-verify my DKIM keys?

No. DKIM verification is handled automatically by receiving mail servers (such as Gmail, Apple Mail, and Outlook) behind the scenes. Your correspondents and clients will notice no disruption, provided your new 2048-bit DKIM public keys are published in your DNS records and resolving properly before you send outbound messages through the new mail host.

Executing an email migration across multiple brands requires careful attention to DNS records and cost per domain. Run your domains through the deliverability audit at /tools/domain-health to verify SPF, DKIM, and DMARC alignment before the WorkMail cutover.