Migrating from AWS WorkMail to Custom Email: What Breaks on Each Domain, and What It Costs

What breaks in a multi-domain AWS WorkMail migration (and how to catch it early)

A multi-domain cutover introduces specific protocol failure points that do not appear during single-mailbox migrations. Knowing these points in advance lets you spot issues before mail starts bouncing.

1. Selector isolation across secondary domains

As defined in the RFC 6376 DKIM standard, cryptographic signatures validate mail authenticity for specific domain selectors. In multi-domain setups, operators often configure a DKIM public key for their primary corporate domain and forget their secondary brands. If your mail client transmits an email from founder@secondarybrand.com, but signs the message with the cryptographic key or selector of primarybrand.com, DKIM verification will fail DMARC alignment. The message may still show a valid signature, but receiving servers will treat it as unaligned because the d= domain tag in the email header does not match the From: address domain.

2. The SPF 10-lookup limit and TXT record bloat

The RFC 7208 SPF specifications state that an SPF evaluation must not perform more than 10 DNS lookups during a single check. When switching hosts, operators frequently paste a new include: directive into their TXT record while leaving the legacy AWS record active. If your domain already includes directives for Shopify, Google, or transactional relays, adding another host can exceed the 10-lookup ceiling. When an SPF record exceeds 10 lookups, major receiving servers return an immediate PermError, which invalidates SPF authentication entirely across all your outbound messages. To check your syntax, use our free SPF record generator and testing tools under tools before publishing.

3. Strict DMARC enforcement during transit

If your domain publishes a strict DMARC rejection policy (p=reject or p=quarantine), any temporary mismatch during your cutover will result in outright message drops or spam folder placement. You can avoid this by setting your DMARC policy to monitor mode (p=none) at least 48 hours prior to migrating:

_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;"

A monitor policy preserves delivery while dispatching aggregate XML reports that highlight any unaligned servers or misconfigured selectors.

4. Forwarding loops and automated alias routing

A common solopreneur workaround is forwarding secondary domains to an external inbox and relying on generic identity aliases to send replies. If your legacy configuration contained server-level forwarding inside AWS WorkMail, recreating identical forwarding in your new destination before deprecating the old routing can trigger an infinite mail loop. Forwarded messages strip or alter original envelope headers; when evaluated against modern receiving standards, forwarded messages often fail SPF unless signed with an unbroken DKIM key.

The FTC phishing guidance highlights that cybercriminals routinely exploit spoofed headers and inconsistent domain authentication to bypass filters. Modern receiving providers actively penalize domains with erratic authentication configurations.

5. Calendar and contact endpoint severance

AWS WorkMail exposes CalDAV and CardDAV synchronization points for calendar appointments and address books. These protocols terminate the instant an AWS WorkMail user account is deprovisioned. If you migrate only your message archives via an IMAP sync and abandon your CalDAV endpoints, you will lose past meeting histories, client notes, and recurring calendar invitations.

Choosing the destination: per-domain pricing versus per-seat pricing

When searching for a practical AWS WorkMail alternative, solo operators face a structural disconnect in email hosting models. Most modern email platforms are designed around teams, billing per user, per month. For an entrepreneur managing five separate corporate identities, standard enterprise platforms require five distinct user seats—even though only one human is reading and typing messages.

Consider the core paths available on the market:

• Per-seat business suites: Platforms such as Google Workspace and Microsoft 365 provide enterprise mail, shared calendars, office suites, and collaborative file storage. You can evaluate their plans directly on the Microsoft 365 Business plans comparison page. However, for a single operator who manages separate brands, paying a per-user fee for each domain quickly adds unnecessary recurring overhead.
• Per-domain and multi-domain hosts: Services such as Migadu, Purelymail, Zoho Mail, Fastmail, and Forward Email cater to cost-conscious domain owners. Each provider balances quotas, inbound forwarding, technical interfaces, and alias routing differently across varying account structures.

If your workflow requires collaborative workspaces, real-time shared documents, and multi-user delegation across an active staff, a traditional per-seat enterprise provider is the correct choice. But if you are an independent operator seeking a consolidated inbox across a multi-domain portfolio, paying per seat for empty mailboxes is an unnecessary cost.

Folio is one mailbox that sends and receives across many custom domains, with a separate DKIM key and signature per domain, for a single operator. Folio is a single-operator inbox, not a team or shared mailbox — there are no per-user seats and no team collaboration features. When an organization requires multiple staff members and ticket routing, standard team suites handle that requirement.

According to the published terms on folioinbox.com, Folio pricing is flat per plan, not per user or per seat:

• Solo: $2.99/mo billed annually ($35.88/yr) or $3.50 monthly. Covers up to 3 domains with a monthly cap of 1,000 sends.
• Studio: $12/mo billed annually ($144/yr) or $15 monthly. Covers up to 10 domains with a monthly cap of 6,000 sends.
• Holding Co.: $29/mo billed annually ($348/yr) or $39 monthly. Covers unlimited domains with a monthly cap of 30,000 sends.

Storage is included and not metered by plan, while email attachments are capped at 15 MiB per message. Folio has no free plan. A free preview of 100 sends on one domain, no card required. Paid plans (Solo, Studio, Holding Co.) start with a 14-day trial, card required.

The cutover, domain by domain: a repeatable sequence

Executing a clean cutover without dropping incoming mail or triggering spam flags requires a disciplined, step-by-step process. Migrate one domain completely before moving to the next.

1. Provision the domain identity at your destination:
   

   Register your target domain inside your new email provider's dashboard. Your new host will generate domain-specific MX destinations, SPF include strings, and dedicated DKIM public keys. If your DNS provider supports Domain Connect, this record creation can happen automatically in a single step rather than requiring manual copy-pasting.

2. Publish and verify DKIM selector records:
   

   Publish your new CNAME or TXT DKIM keys at your DNS host. Do not touch your MX records yet. Verify that public nameservers resolve your new DKIM key by running a targeted query:

   dig +short TXT folio1._domainkey.yourdomain.com

   Confirm that the returned cryptographic public string matches the dashboard output exactly.

3. Lower TTLs across all active DNS records:
   

   Twenty-four hours before you plan to change mail routing, adjust the Time-to-Live (TTL) values on your existing MX and TXT records to 300 seconds (5 minutes). This prevents recursive DNS resolvers across the web from caching stale AWS WorkMail routes once you initiate the migration.

4. Update SPF records cleanly:
   

   Modify your existing SPF TXT record to include your new provider's mechanism. If you are replacing AWS WorkMail entirely, remove the legacy AWS inclusion string:

   # Incorrect: accumulating legacy includes
   v=spf1 include:amazonses.com include:newprovider.com ~all
   
   # Correct: clean authorization reflecting your actual senders
   v=spf1 include:newprovider.com ~all

5. Re-point MX records to the new destination:
   

   Change your domain's MX records to point to your new provider's endpoints. Because your TTL was lowered to 300 seconds, receiving mail transfer agents around the world will detect the new destination within minutes.

6. Perform an external alignment test:
   

   Send an email from your cut-over domain to an external test inbox. Inspect the raw headers to verify three specific data points: SPF PASS with your domain identity authorized, DKIM PASS with header domain matching your sending domain, and DMARC PASS indicating valid alignment.

7. Maintain a temporary grace period on AWS WorkMail:
   

   Keep your old AWS WorkMail mailbox active for at least 72 hours following the MX record update. Any external MTAs that cached the previous MX records under older, longer TTLs will continue delivering to AWS during that window. After three days without inbound traffic, you can safely deprovision the WorkMail entity.

Moving stored mail, calendars and contacts without losing anything

Re-pointing DNS routes future messages to your new destination, but historical messages remain stored inside Amazon's infrastructure. To preserve your archives, execute an IMAP transfer while both endpoints remain accessible.

Initiate the mailbox copy before updating your MX records. When both the source and target mailboxes are operational, your synchronization tool can transfer historical folders over standard TLS-encrypted IMAP connections in the background without downtime. If you wait until after MX records are severed, managing credentials and server endpoints across active zones becomes significantly more complicated.

When migrating IMAP data from AWS WorkMail, keep these practical operational realities in mind:

• IMAP transfer duration: Mailboxes containing tens of thousands of individual MIME objects take time to process. Due to rate limits on historical endpoints, migrations can take several hours to finish. Let the sync complete before running your DNS cutover.
• Folder hierarchies and flags: Because mail clients and servers implement IMAP metadata with minor differences, nested folders, read states, and custom flags can require manual verification after the initial sync. Check your core operational folders—specifically Inbox, Sent Items, and Drafts—to verify that message counts match between AWS WorkMail and your destination.
• Attachment restrictions: Check for historical messages with large attachments. Folio caps attachments at 15 MiB per message, which is optimized for standard business correspondence. If your legacy AWS WorkMail archive contains raw design files or video assets that exceed this limit, archive those large attachments to dedicated cloud storage before syncing.
• Calendar and contact extraction: Because CalDAV and CardDAV profiles do not sync over IMAP, export your calendar items into standard .ics files and your address book into standard .vcf vCard files directly from the AWS WorkMail web interface before closing your account.

Verifying the move: SPF, DKIM, DMARC and MTA-STS on every domain

Verifying a single domain does not ensure that your entire portfolio is healthy. A typo on a single DNS record can leave an entire brand's email failing silently. Audit each domain individually to confirm proper configuration.

You can run our free domain health and deliverability audit across every domain you migrate. The tool inspects your live SPF, DKIM, DMARC, and MTA-STS records with no email gate on the result, letting you confirm that your authentication records match current standards.

Work through this verification checklist for each domain in your portfolio:

1. Validate SPF string syntax and evaluation limits:
   

   Confirm that your domain has exactly one SPF TXT record. Multiple SPF records in a single DNS zone cause receiving servers to reject both. Ensure your total lookup count remains well below the 10-query limit.

2. Confirm cryptographic DKIM alignment:
   

   Ensure your public DKIM key matches your outbound signing selector. The domain listed in the d= tag of your outbound headers must match the domain found in the visible From: address.

3. Establish DMARC reporting:
   

   Review your daily XML DMARC aggregate reports. Maintain a policy of p=none for 14 days after your cutover. If the reports show consistent authentication alignment across legitimate mail, update your policy to p=quarantine or p=reject to protect your domain reputation.

4. Audit or retire stale MTA-STS and TLS-RPT policies:
   

   If you published MTA-STS records pointing to AWS-specific endpoints