Migrating from Fastmail to FolioInbox: What Breaks, What Moves, and What It Costs

What you are actually paying now, and what changes

When switching email provider for multiple domains, calculate your total operating expense by multiplying the number of domains against required account tiers. Typical business email platforms charge recurring fees on a per-user basis. When you pay for separate user accounts simply to keep domains isolated across several LLCs, recurring seat fees accumulate each month even if you are the only person typing. If you expand to eight or ten projects, your annual software expense triples even though your aggregate daily email volume remains consistent with what one person can type.

FolioInbox eliminates per-seat fees entirely. As detailed on the FolioInbox pricing page and defined in its published product capability contract, billing is flat per plan based on domain counts and monthly send volume:

• Folio Solo: $2.99 per month billed annually ($35.88/year) or $3.50 monthly. Supports up to 3 domains, 1,000 outbound sends per month, dedicated per-domain DKIM and signatures, and email support.
• Folio Studio: $12 per month billed annually ($144/year) or $15 monthly. Supports up to 10 domains, 6,000 outbound sends per month, dedicated per-domain DKIM and signatures, and priority support.
• Folio Holding Co.: $29 per month billed annually ($348/year) or $39 monthly. Supports unlimited domains, 30,000 outbound sends per month, an onboarding call, DNS setup review, and priority support with response SLA.

Examine the operational limits before reviewing the benefits. Monthly outbound send caps are hard thresholds: 1,000 for Solo, 6,000 for Studio, and 30,000 for Holding Co. Outbound message attachments are strictly capped at 15 MiB per message. Inbound storage is included across all plans and is not metered by tier.

Plan terms are straightforward. 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. As stated in Folio's published product capability contract, the preview allowance is a one-time allotment that never resets; sustained sending requires activating a paid tier.

Before you touch DNS: the pre-migration checklist

The primary reason email migrations fail is administrative oversight rather than protocol errors. Operators forget transactional endpoints or leave old records active. Complete this pre-migration audit before changing any DNS settings.

1. Inventory every operational address

List every address that receives or transmits traffic across your domains. Do not rely on memory. Check payment gateways, contact form destinations, vendor accounts, and registrar WHOIS records. Ensure you account for:

• Operational addresses (e.g., billing@brandone.com, invoices@brandtwo.io)
• System and transactional routing points (e.g., orders@storefront.com)
• Legacy addresses configured as aliases or forwarded to personal inboxes

2. Export historical archives from Fastmail

Once you modify MX records, incoming traffic stops delivering to Fastmail. Follow the vendor's backup documentation to download your historical mail as standard MBOX archives or synchronize your account to a local IMAP client. Preserving offline copies guarantees you retain historical records regardless of DNS cutover timing.

3. Snapshot your existing DNS zone files

Export or screenshot the existing DNS records for every domain you plan to migrate. Record all current values for:

• MX (Mail Exchange) hostnames and preference priorities
• TXT records containing SPF syntax (e.g., v=spf1 ...)
• CNAME or TXT records hosting DKIM public keys
• DMARC policy records located at _dmarc.yourdomain.com

4. Sequence your cutover schedule

Staging your transition one property at a time avoids widespread disruption across your portfolio. Select your lowest-risk property — an internal holding site or a low-volume side project — to execute first. Run that domain through the entire migration sequence, observe live delivery for 24 hours, and confirm proper signing. Once the workflow is validated, cut over revenue-critical business domains individually.

5. Establish a deliverability baseline

Before modifying records, run your current domain through the free deliverability audit tool at folioinbox.com/tools/domain-health. This tests your active SPF syntax, DKIM keys, DMARC policies, and MTA-STS parameters. It provides a clean, ungated baseline report so you can verify that authentication post-migration matches or exceeds your previous security standing.

The cutover, domain by domain: MX, SPF, DKIM and DMARC

Once your checklist is complete, execute the cutover domain by domain. Precision matters here. When switching email provider for multiple domains, updating DNS in the wrong sequence can lead to dropped messages or temporary authentication failures.

Step 1: Connect the domain in FolioInbox

Navigate to your account dashboard and add the target domain. Domain connection is managed on a single screen. If your domain is registered with an infrastructure provider that supports Domain Connect, Folio automatically detects the API and publishes all required DNS records directly to your zone file. If your registrar does not support Domain Connect, the dashboard generates the exact values you need to copy into your DNS management panel.

Step 2: Lower DNS Time-to-Live (TTL)

If you are pasting DNS records manually, log into your DNS host 24 hours prior to cutover. Reduce the TTL on your existing MX and TXT records from standard values (often 14,400 or 86,400 seconds) down to 300 seconds (5 minutes). This ensures that once you replace the records, external mail transfer agents query updated routing information almost immediately rather than caching stale servers.

Step 3: Update Mail Exchange (MX) records

Add the new MX records provided by FolioInbox to your zone file. Once published, delete the old Fastmail MX entries. Do not leave both providers configured simultaneously. Running dual MX records with identical or staggered priorities creates split-brain delivery, where some senders route to the old mailbox and others route to the new one.

Step 4: Refactor your SPF TXT record

Under Section 3.2 of the RFC 7208 SPF specification, a domain must never possess more than one TXT record beginning with v=spf1. Multiple SPF records cause receiving mail servers to return a PermError, which fails DMARC evaluation instantly. Locate your existing SPF entry and remove the old provider's lookup tag (such as include:spf.messagingengine.com). Insert the Folio SPF inclusion tag provided in your setup screen.

Audit your total DNS lookups. Section 4.6.4 of the RFC 7208 specification enforces a hard ceiling of 10 DNS lookups per evaluation. If your domain uses services like Shopify, Stripe, or transactional relay engines, calculate your nested lookups carefully. If you are hovering at nine or ten lookups, eliminate legacy vendors from your string during this cleanup.

Step 5: Provision dedicated DKIM selectors

This step represents the core structural change from your previous setup. Folio generates an isolated cryptographic key pair for every single domain you attach. Publish the generated CNAME or TXT records under the designated selector hostname (for example, folio._domainkey.yourdomain.com). Because each domain signs with its own distinct cryptographic key, your messages do not depend on generic shared-tenant signatures, which protects your sender reputation.

Step 6: Configure DMARC policy progression

Under the RFC 7489 DMARC specification, DMARC ties SPF and DKIM authentication directly to the visible From: header. If you do not already have a DMARC policy active at _dmarc.yourdomain.com, create one now using monitoring mode:

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

Leave the policy at p=none for the first seven days. Review incoming aggregate XML reports to confirm that all legitimate outbound sources (including automated invoice systems or transactional relays) pass alignment under the new DKIM keys. Once you confirm zero false positives, tighten your policy to p=quarantine, and ultimately to p=reject.

Step 7: Verify MTA-STS and TLS reporting

If your domain previously utilized MTA-STS (Mail Transfer Agent Strict Transport Security) to enforce encrypted transit, update your policy file to validate Folio's mail endpoints. Leaving MTA-STS pointing to retired hostnames causes sending servers to withhold delivery. Run your domain back through the health audit to confirm that TLS reporting, MX targets, and DKIM public keys match expected parameters.

What breaks, and what to do about it

Migrating email systems often introduces edge-case friction. Knowing what does not transfer automatically prevents downtime and operational confusion.

1. Unmapped aliases will bounce

If an external customer or automated invoice service sends mail to an address you forgot to configure in your new dashboard, the inbound server returns a standard 550 User Unknown bounce. The fix is not opening a support ticket — it is performing a thorough pre-migration inventory. If an unexpected address bounces, simply add the necessary routing rule inside the console.

2. Transient DKIM alignment blips during propagation

DNS propagation is not instantaneous worldwide. While authoritative servers update quickly, caching recursive resolvers may serve legacy DKIM keys for several hours if old TTLs were long. Outbound messages evaluated during this window may display temporary alignment warnings in external delivery logs. This resolves naturally as global DNS caches expire.

3. Calendars, contacts, and collaborative assets remain behind

Fastmail offers an integrated suite featuring WebDAV calendars, address books, and notes. FolioInbox does not ship calendar features, contact books, cloud document hosting, or video conferencing tools. Folio is built exclusively as an email communication system. If your daily operations depend on synchronized CalDAV engines, migrate those calendars to a dedicated standalone calendar tool before shutting down your old account.

4. Application-specific passwords and mail client setups

Desktop and mobile mail clients configured to talk to your previous provider will immediately throw authentication errors after cutover. Folio does not utilize static user passwords. Authentication is handled securely via cryptographic passkeys or magic links. Install the dedicated Android app from Google Play or access your account through the primary web interface, bypassing legacy password configurations.

5. Fastmail Masked Email addresses do not transfer

If you made extensive use of Fastmail's integration with password managers to generate dynamic "masked" email addresses, those addresses will deactivate once your previous subscription lapses. Identify all critical services using generated masked aliases and update their profile addresses to a persistent domain address under your direct control before canceling your old subscription.

6. Encryption architectures are structured differently

Understand how privacy models function on modern hosted platforms. 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. If your regulatory constraints require zero-knowledge cryptographic architectures where the service provider cannot parse message text for spam identification, hosted consumer business mail platforms will not satisfy that standard.

Folio is a proprietary, hosted service; its source code is not public. It is designed for operators seeking stable, fully managed deliverability without managing software updates or maintaining complex mail transfer agents themselves.

Verifying the move: proving each domain sends and receives correctly

Do not assume a migration was successful simply because you stopped seeing error messages in your DNS control panel. Prove that authentication protocols, routing rules, and deliverability paths operate correctly using systematic tests.

Send a standard plain-text test email from your connected domain to an external destination mailbox you control, such as a personal Gmail address. In the destination inbox, open the raw message headers (in Gmail, select "Show original") and review the forensic authentication block:

ARC-Authentication-Results: i=1; mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=folio header.b=...;
  spf=pass (google.com: domain of user@yourdomain.com designates ... as permitted sender)
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Verify three strict checkpoints in these headers:

• DKIM passing with domain alignment: The header.i= parameter must match your root domain, and the selector must reflect your new DKIM record.
• SPF passing cleanly: The envelope sender must align with the authorized sending IP ranges without relying on softfail (~all) exceptions.
• DMARC alignment passing: The domain visible in the From: header must align directly with the authenticated DKIM signing domain.

Next, test the inbound routing pipeline. Send a message from an external network to your custom domain. Check that it appears in your console without delay. Send test messages to every operational address you cataloged, including low-volume destinations like accounting@ or support@.

Finally, run your domain back through the free health audit tool at folioinbox.com/tools/domain-health. Compare the live results against the baseline report you generated before starting the migration. Confirm that MX pointers, SPF syntax, and DKIM public records return green status indicators across all parameters.

Critical Operational Rule: Keep your old Fastmail subscription active for at least one full billing cycle following your cutover. Senders with outdated DNS caches, obscure services with hardcoded routing, or forgotten forwarding pipelines may still attempt delivery to your old mailbox for several days. Maintaining access for a few weeks ensures you catch edge cases without losing important business correspondence.

When staying on Fastmail is the better call

Changing software infrastructure involves real time, effort, and testing overhead. Migrating from Fastmail to FolioInbox is not necessary or recommended for every operational structure. In many scenarios, staying on your current platform is the sensible business decision.

Use this straightforward operational framework to decide whether to migrate:

1. Count your human team members: If more than one person needs to log into the inbox, triage customer threads, or access shared message queues, do not switch. Folio is a single-operator inbox, not a team or shared mailbox — there are no per-user seats and no team collaboration features. Fastmail offers dedicated multi-user support, team folders, and permission controls that fit multi-employee businesses.
2. Count your non-email dependencies: If you use integrated calendars, synchronized address books, WebDAV file storage, and desktop calendar integrations, Folio will not replace them. Folio does not build calendar, contacts, or file hosting utilities. You would need to introduce separate tools to cover those functions.
3. Count your managed domains: If you operate only one primary domain alongside an address or two, the administrative cost savings of flat-tier pricing are negligible. Fastmail handles single-domain setups well. That path is real, and if it works for you, take it.
4. Check your security requirements: If your operational mandate requires local on-premises hardware or source code inspection, Folio is a fully hosted service and cannot be self-hosted or run on your own servers or infrastructure. If you require mathematical zero-knowledge privacy, neither hosted platform fits that model.

If you evaluate your workflow and find that your biggest daily frustration is seat fees multiplying across secondary corporate entities, or complex alias setups breaking outbound DKIM signatures, the move makes sense. If your business relies on team collaboration or shared calendars, remain where you are.

Frequently Asked Questions

Will I lose email during a Fastmail to FolioInbox migration?

No, provided you stage the migration in the correct order. Mail transfer agents retry delivery automatically if a server is momentarily unreachable, and lowering your TTL prior to cutover minimizes DNS propagation lag. Backing up historical mail via MBOX export before updating MX records ensures no message history is lost.

Does FolioInbox give each domain its own DKIM key?

Yes. Every custom domain you connect generates an isolated cryptographic key pair and unique selector. This ensures full SPF and DKIM alignment under strict DMARC policies, completely avoiding the shared-reputation risks associated with sending through generic alias relays.

Can I run FolioInbox and Fastmail side by side during the switch?

Under the mail exchange mechanisms defined in RFC 5321 Section 5, sending transfer agents select MX records by priority and balance across identical preference values. Publishing active MX records for two different email providers on a single domain causes split delivery, routing incoming mail unpredictably between the two platforms. You can run the services in parallel across separate domains in your portfolio, but avoid pointing active MX records for the same domain to both platforms simultaneously. Move your domains over one at a time instead.

Is there a free plan or free trial I can test the migration with?

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 preview allowance is a one-time allotment that never resets; sustained sending requires activating a paid plan as outlined in Folio's published product capability contract.

What happens to my Fastmail aliases and masked email addresses?

Masked email addresses and server-side alias rules configured inside Fastmail do not transfer automatically. You must map any required operational addresses directly into your Folio console, and update any third-party accounts that use Fastmail-generated masked addresses before closing your old account.

Doing the move in the right order

Adhering to a strict order of operations protects your business communication and your sender reputation. For domain protection and inbox-safety context, official FTC guidance on recognizing phishing scams highlights how spoofing relies on unauthenticated sender domains. Clean email authentication helps receiving servers distinguish your legitimate business communications from unauthorized spoofing attempts.

Execute your migration using this sequence:

1. Inventory: Document all operational addresses and active routing dependencies.
2. Export: Download local MBOX backups of your existing message histories.
3. Baseline: Run every domain through a comprehensive authentication audit.
4. Connect & Repoint: Add one pilot domain to Folio, reduce TTLs, and publish your new MX, SPF, and dedicated DKIM records.
5. Verify: Inspect raw headers on outbound mail to confirm passing DMARC alignment, then repeat the process across your remaining domains.

The cost structure is straightforward: Solo ($2.99/mo billed annually) for up to 3 domains, Studio ($12/mo billed annually) for up to 10 domains, and Holding Co. ($29/mo billed annually) for unlimited domains. Switching email provider for multiple domains is worth doing when you want to stop paying per-seat tax on secondary brands and need clean, isolated email authentication for every entity you manage.

Start by running your domains through the free deliverability audit at folioinbox.com/tools/domain-health. The audit checks your live SPF, DKIM, DMARC, and MTA-STS configurations instantly, with no email address required to see the results. Once you have a clear picture of your current DNS health, review the pricing plans to choose the tier that matches your domain portfolio.