Migrating from Purelymail to FolioInbox: Real Costs, DNS Cutovers, and Daily Limits

Architectural Differences: Credit Balances, Send Caps, and Security Models

When completing the process of migrating from Purelymail to FolioInbox, your operational habits must adapt to distinct technical architectures. Purelymail treats email as a metered commodity utility. FolioInbox structures mail around identity isolation and outbound safety for independent operators.

The first divergence is message quotas. Purelymail relies on credit debits: if your balance runs out, outbound delivery pauses until you add funds. FolioInbox uses hard monthly send caps: 1,000 sends on Solo, 6,000 on Studio, and 30,000 on Holding Co. These caps reset every billing cycle. For standard business correspondence, proposal delivery, client communication, and order confirmations, 1,000 to 6,000 sends per month is plenty of headroom for a solo operator. However, FolioInbox is not a bulk email service. It cannot be used for cold mass prospecting or high-volume newsletters.

Attachment handling is also explicit. FolioInbox enforces an attachment limit of 15 MiB per message. If your workflow regularly requires transmitting 40 MiB raw print proofs or uncompressed video files through SMTP, you must link those files via external storage solutions rather than attaching them directly.

Authentication represents another core architectural difference. Purelymail uses traditional username-and-password combinations with optional time-based one-time passwords (TOTP). FolioInbox removes account passwords entirely. Sign-in is handled exclusively via WebAuthn passkeys (biometric sensors, YubiKeys) or cryptographically verified magic links sent to an emergency recovery address. This eliminates credential stuffing risks and credential harvesting vectors. As highlighted in FTC phishing guidance, moving away from reusable passwords protects critical communication lines against unauthorized account takeovers.

The cryptographic model of the mailbox itself must be clearly understood before initiating transfer. 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 compliance requirements mandate zero-knowledge client-side encryption (such as PGP-only hosting where the server provider cannot index messages), FolioInbox is not designed for that use case. Server-side processing is precisely what enables instant global search and automated junk classification across all your linked domains simultaneously.

Pre-Migration Audit: Inventorying Mailboxes, Aliases, and Stored Data

A smooth mail cutover requires an audit of your existing Purelymail configuration before modifying public DNS records. Rushing into an MX record swap without mapping existing routes creates delivery black holes.

1. Audit existing addresses and catch-all rules: Log into your Purelymail administration panel. Open each active domain. List all configured mailboxes, routing rules, aliases, and catch-all directives. Identify which addresses actively receive mail and which were created as disposable routing tokens.
2. Validate your team status: Folio is a single-operator inbox, not a team or shared mailbox — there are no per-user seats and no team collaboration features. If you have virtual assistants, co-founders, or contractors logging into dedicated sub-mailboxes under your Purelymail account, they cannot be moved into FolioInbox as secondary users. FolioInbox is engineered exclusively for an individual operator managing multiple distinct corporate identities.
3. Archive historical message data: FolioInbox does not provide an automated, one-click IMAP sync engine to suck in historical mailboxes during setup. You should back up your existing Purelymail messages locally before modifying records. You can download an Mbox export through standard webmail clients, or use a local desktop client like Thunderbird to synchronize all folders offline over IMAP:

   # Example offline sync configuration using mbsync / isync
   Channel purelymail-backup
   Master :purelymail-remote:
   Slave :local-mail-archive:
   Patterns *
   Create Both
   Sync All

   Retain this local archive for historical lookup. Once your MX records point to FolioInbox, all new incoming messages route into your unified FolioInbox interface.

4. Inventory third-party senders and transactional APIs: If your Shopify store, Ghost blog, or SaaS application uses Purelymail's SMTP servers to send notifications, transactional receipts, or system alerts, list those endpoints. You will need to transition those services to dedicated transactional providers or reconfigure their credentials, ensuring they do not breach FolioInbox's daily interactive messaging caps.

Step-by-Step Checklist for Migrating from Purelymail to FolioInbox

Once you have backed up your historical mail and audited your addresses, follow this structured deployment sequence to switch email provider routing without message loss.

Step 1: Lower DNS TTLs on Active Records

Log into your DNS provider (such as Cloudflare, Namecheap, or Porkbun) 24 to 48 hours before the migration. Locate your existing MX and TXT records for each domain you plan to migrate. Reduce the Time-to-Live (TTL) values from automatic or 86400 seconds (24 hours) down to 300 seconds (5 minutes). This ensures that once you swap routing pointers later, recursive DNS resolvers across the internet will drop stale cached routes within five minutes.

Step 2: Add Domains Within the FolioInbox Dashboard

Sign in to FolioInbox using your passkey or magic link. Open the single-screen domain setup dashboard. Enter the primary domain name for your first entity (for example, agencybrand.com). FolioInbox immediately generates the exact DNS records required for that specific domain: the receiving MX hostnames, the unique SPF authorization string, and a dedicated 2048-bit DKIM public key.

Step 3: Publish DNS Records via Domain Connect or Manual Entry

If your domain registrar supports the Domain Connect standard, FolioInbox can automatically authenticate and publish your records with a single authorization click. This eliminates the tedious process of copying and pasting strings between browser tabs.

If your registrar does not support Domain Connect, open your DNS management zone and create the records manually:

• MX Records: Replace the existing Purelymail MX records with FolioInbox's receiving endpoints. Set the priority to 10.
• SPF TXT Record: Update your existing v=spf1 TXT record to include FolioInbox's authorized sending mechanism while removing Purelymail's include statement.
• DKIM CNAME/TXT Records: Add the dedicated DKIM selector generated specifically for this domain in your FolioInbox dashboard.

Step 4: Configure Sender Personas and Signatures

Within FolioInbox, define your sending identity for the connected domain. Set the "From" display name (e.g., Jane Doe ) and the address (e.g., jane@agencybrand.com ). Configure your separate HTML or plain-text signature. Repeat this process for each secondary brand or LLC domain permitted under your plan tier (up to 3 on Solo, 10 on Studio, or unlimited on Holding Co.). Each brand receives its own independent signature and identity profile.

Step 5: Verify DNS Propagation and Authentication Alignment

Once published, use the built-in domain validation tool inside FolioInbox to confirm that public DNS resolvers are serving your updated parameters. You can verify your SPF alignment, DKIM cryptographic integrity, and DMARC enforcement using the free domain health checker provided by FolioInbox. This diagnostic tool runs deep deliverability checks with no email gate on the result.

DNS Cutover Details: SPF Alignment, Per-Domain DKIM, and DMARC Policy

The primary technical motivation for migrating from Purelymail to FolioInbox is eliminating deliverability leaks. Achieving proper domain isolation requires strict compliance with modern email authentication protocols. According to IETF RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC) requires either SPF or DKIM to align identically with the RFC5322.From header domain displayed to the recipient.

When you host multiple domains on standard low-cost mailboxes, many platforms sign outbound mail using a single shared DKIM key belonging to the server cluster, or route messages through return paths that fail strict alignment. If you send an invoice from store.com, but the underlying DKIM signature resolves to a shared host selector, receiving mail servers at Google and Yahoo may penalize your inbox placement score.

FolioInbox mitigates this risk by generating an isolated, cryptographically distinct DKIM key pair for every single domain you attach. One entity's sending reputation rarely bleeds into another. If a marketing campaign on your eCommerce domain encounters elevated spam complaints, the DKIM signature on your consulting domain remains completely isolated.

Configuring SPF Without Exceeding the 10-Lookup Limit

The Sender Policy Framework (SPF) specification enforces a strict limit of 10 DNS lookups when evaluating an authorization string. If an SPF record triggers more than 10 lookups, receiving mail transfer agents return a PermError, which causes DMARC validation to fail instantly.

When replacing Purelymail's include mechanism, audit your existing record carefully. A clean, optimized record should look like this:

v=spf1 include:_spf.folioinbox.com ~all

If you also send transactional receipts through a provider like Postmark or an eCommerce host like Shopify, combine them cleanly into a single TXT entry:

v=spf1 include:_spf.folioinbox.com include:spf.mtasv.net ~all

rarely publish multiple SPF TXT records on the same root domain. Multiple v=spf1 records violate RFC standards and result in automatic authentication failure. If you need to generate a validated string from scratch, use the SPF record generator to ensure clean syntax before publishing.

Establishing a Phased DMARC Policy

rarely switch an MX record and deploy a strict p=reject DMARC policy on the same afternoon. A safe deployment requires a phased rollout to catch any misconfigured outbound services:

1. Phase 1 (Monitoring): Deploy a monitoring policy immediately after cutover:

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

   This instructs receiving mail servers to deliver messages normally even if an authentication mismatch occurs, while transmitting XML aggregate reports to your monitoring address.

2. Phase 2 (Quarantine): After seven days of clean reports showing many DKIM and SPF alignment across your business correspondence, escalate the policy to quarantine: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; pct=100; Unauthenticated messages spoofing your brand are diverted to the recipient's spam folder.
3. Phase 3 (Rejection): Once you have verified that all legitimate traffic passes alignment checks, enforce full protection:

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

   Unauthorized messages are blocked at the perimeter by receiving mail servers.

To confirm that your security mechanisms protect your contact information and identity, review the FTC guidance on how websites and apps collect and use information. Enforcing DMARC prevents third parties from impersonating your corporate identity to defraud your clients.

Purelymail Alternatives: When FolioInbox Is Not the Right Choice

A transparent evaluation means recognizing when alternative platforms are better suited for your business model. FolioInbox is deliberately specialized: it serves a solo operator managing multiple commercial brands. If your operational profile deviates from that model, other purelymail alternatives may be more appropriate.

When to Stay on Purelymail

Purelymail remains an exceptional choice under specific conditions:

• Massive, cold archive storage: If you have 80 GB of historical client attachments from a decade ago that you need to store at rock-bottom prices (a measurable budget/GB/mo), Purelymail's consumption model is vastly cheaper than almost any flat-rate provider.
• Hobby projects with negligible traffic: If you run four side projects that receive two emails a month and rarely send outbound proposals, paying a measurable budget per year total makes more economic sense than subscribing to a dedicated business tool.
• Budget multi-user hosting: If you have two partners who each need their own separate login and webmail interface on a shoestring budget, Purelymail allows you to provision multiple user accounts under one balance.

When to Choose Migadu

Migadu offers a pooled infrastructure model where pricing is based on total outbound message volume across an entire organization rather than per-user seats. If you run a small micro-business with three employees who need distinct mailboxes, shared calendars, and internal collaboration, Migadu provides a viable middle ground without per-seat Workspace costs.

When to Choose Google Workspace or Fastmail

If your business operations depend on an integrated office suite—collaborative document editing, Google Meet links generated directly within calendar invites, shared company contact directories, and delegated inbox access across executive assistants—you should pay the per-seat fee for Google Workspace or Fastmail. FolioInbox does not ship a calendar suite, spreadsheet editor, cloud file drive, or collaborative team tools.

When FolioInbox Is the Optimal Choice

FolioInbox is the right solution when you match this exact profile: you are a single human running two, five, or eight distinct commercial domains (a holding company, an agency, an advisory brand, several eCommerce stores). You do not want to manage eight separate webmail logins, you refuse to pay a measurable budget to a measurable budget per month per domain to enterprise office suites, and you are tired of alias hacks that break DKIM signatures. You want one unified, secure inbox where you can switch between sending identities with a single click, confident that each domain possesses its own authenticated reputation.

As reinforced in Google guidance on creating helpful content, practical technical decisions should focus directly on utility, operational constraints, and transparent tradeoffs rather than marketing hype.

Post-Migration Verification and Deprecation

Do not close your source hosting account the moment you update your DNS records. A structured deprecation sequence ensures you do not bounce incoming client messages during the DNS propagation window.

1. Send bidirectional test messages: From each connected brand address inside FolioInbox, send a test email to an external account (such as a personal Gmail or Outlook address). Inspect the raw headers of the received test email: Authentication-Results: mx.google.com; dkim=pass header.i=@yourbrand.com header.s=folio...; spf=pass (google.com: domain of sender@yourbrand.com designates ... as permitted sender); dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourbrand.com Verify that the DKIM signature passes and that the d= domain matches your actual From address. Then, reply to that message and verify that the inbound email routes cleanly into your FolioInbox interface.
2. Monitor the Purelymail inbox during TTL decay: Because some recursive DNS resolvers ignore low TTL values and cache records for hours, keep an eye on your old Purelymail webmail account for 24 to 48 hours. Any message delivered to Purelymail during this window indicates that a remote server is still resolving your old MX records.
3. Deprecate the old account cleanly: Once many hours have elapsed with zero incoming traffic hitting Purelymail, disable the domain routing rules inside your Purelymail control panel. Download any final log files you wish to retain, and cancel your recurring credit replenishment billing to prevent unexpected credit card charges.

Frequently Asked Questions

Can I transfer existing emails automatically from Purelymail to FolioInbox?

No. FolioInbox does not include an automated IMAP synchronization tool to ingest historical message archives. To preserve your existing mail history from Purelymail, export your mailboxes locally via an Mbox backup or sync your folders using an offline desktop email client like Mozilla Thunderbird before modifying your DNS MX records. Once you point your MX records to FolioInbox, all new incoming correspondence will arrive in your FolioInbox account.

Does FolioInbox offer shared team mailboxes like Purelymail does?

No. Folio is a single-operator inbox, not a team or shared mailbox — there are no per-user seats and no team collaboration features. While Purelymail allows provisioning multiple mailboxes for different people under a single shared billing credit balance, FolioInbox is engineered strictly for an individual entrepreneur running several distinct domains from one interface.

What happens if I exceed the monthly send cap on FolioInbox?

Each FolioInbox plan has a defined monthly send quota: 1,000 outbound messages on Solo, 6,000 on Studio, and 30,000 on Holding Co. If you reach your plan's outbound limit before the end of your billing cycle, outbound message transmission pauses until the quota resets on your next billing date. You can upgrade your plan immediately from your account settings to expand your sending quota. Storage, by contrast, is unmetered across all plans.

Why does FolioInbox assign a different DKIM key to each domain?

FolioInbox generates an isolated, 2048-bit DKIM key pair for every connected domain to ensure complete cryptographic isolation and reputation independence. Many low-cost mail bundles use a shared DKIM selector across all accounts or domains hosted on a particular server. By using dedicated DKIM keys per domain, your sender reputation remains isolated: spam flags or deliverability issues on one secondary project will rarely degrade the inbox placement of your primary consulting brand or operating business.

Audit your domains before switching: run a free SPF, DKIM, and DMARC scan with FolioInbox's Domain Health tool, then launch a 14-day trial to connect your first domain in seconds.