Leaving Forward Email: The Complete Migration Guide (2026)

The short version — Forward Email is a genuinely impressive piece of open-source engineering: per-mailbox encryption, a published Cure53 audit, 35+ API endpoints, unlimited domains and aliases for $36/year. It's also, by design, not an inbox — the free tier is DNS-TXT-record forwarding, and even the paid tier ships no webmail (bring your own Thunderbird or self-host a client). People leave when they realize they wanted email, not email infrastructure — or when the tiny team's support and documentation gaps catch up with them. Here's the move, history intact.

Credit where a lot is due

Forward Email does things most hosts don't: it's 100% open source, it commissioned and published a Cure53 security audit (June 2026), it encrypts each mailbox individually, and its API surface is real. If you're a developer who wants forwarding-as-code in DNS records, or who's happy living in Thunderbird against a well-engineered backend, it's a legitimately good choice and you should probably stay. This guide is for people for whom "you're kind of on your own" stopped being charming.

Why people actually leave

• There's no inbox to use. The free tier forwards mail; it doesn't store it. The paid tier adds IMAP/POP/SMTP hosting — but still no first-party webmail, with apps perpetually "coming soon" (their FAQ). You supply the client. For anyone who wanted to read email rather than assemble a mail stack, that's the wall.
• Documentation and support strain a tiny team. An independent reviewer described "confusing documentation… you're kind of on your own" (James Cridland), alongside Gmail SPF bounces and unanswered support. Public trails include a support ticket open from June to December 2025, and a multi-DKIM outbound bug open since 2024 (GitHub #394).
• Forwarding's structural limits still apply on the free tier. Config lives in publicly-readable DNS TXT records, and forwarding breaks SPF alignment by design — the same deliverability tax every forwarder pays. The paid hosted tier fixes the storage half but not the "is this a product or a toolkit" question.
• The site itself is a maze. Hundreds of SEO comparison pages and dense docs make the simple path hard to find — a common first impression that doesn't improve much after signup.

Notice what's not here: Forward Email genuinely beats most rivals — us included — on API breadth, webhooks, POP3, and PGP/S-MIME. If those are your requirements, weigh this move carefully; you may be trading down on exactly the axes you value.

Before you start

1. Determine which tier you're on. Free (forwarding-only) means there's no stored mail to copy — you're changing where forwarding points, not migrating an inbox. Paid hosted means you have IMAP mailboxes to copy.
2. For paid mailboxes: note the generated mailbox passwords (Forward Email issues per-mailbox credentials) — the import authenticates over IMAP.
3. Inventory domains, aliases (including regex aliases) and any Sieve rules. Regex aliases and Sieve won't port automatically anywhere.
4. Cancel nothing yet.

The migration, step by step

1. Create the destination and verify your domains. On MailHow: Settings → Domains, verify each by TXT record. Unlimited domains at Forward Email can consolidate into one inbox here.

2. Copy your mail (paid tier). Settings → Import → the Forward Email preset (imap.forwardemail.net), the mailbox address and its generated password. One-way, folders/flags/dates preserved. Free-tier users skip this — there's no stored mail; your history lives in whatever inbox you were forwarding to, so import from there instead.

3. Recreate routing — and get an actual inbox in the bargain. Rebuild aliases and catch-alls at the destination. The forwarding rules you kept in TXT records become normal addresses on a real mailbox; the Thunderbird-or-nothing constraint goes away.

4. Switch DNS. Replace Forward Email's MX and TXT-based forwarding/auth records with the new provider's MX/SPF/DKIM. On MailHow these are generated for you (one click via a connected registrar, SPF merged). Delete the old forwarding TXT and MX records so mail stops routing to the old path.

5. Grace period, sweep, cancel. Two weeks for DNS caches, one final import (paid) or forwarding-target check (free), then cancel.

What changes, concretely

This is the most genuinely two-sided comparison in our migration set: Forward Email wins on openness, API depth, and protocol breadth; we win on "it's an inbox you just open". Pick honestly for what you actually do.

Questions from Forward Email switchers

I'm on the free tier — what am I actually migrating? Not stored mail (there isn't any) — you're moving from "forward my domain into some other inbox" to "my domain is a real inbox." Point your domain's MX at the new mailbox; import history from whatever inbox you'd been forwarding into.

I rely on the API / webhooks / PGP. Then move deliberately — Forward Email is ahead of us there. If those are load-bearing for you, this may not be your switch; if they were nice-to-haves you never used, you lose nothing and gain an inbox.

Will my regex aliases and Sieve rules come across? No — those are provider-specific. Recreate the aliases you use as normal addresses, and rebuild the filter logic you actually rely on (usually far less than the accumulated total).

Is my mail encrypted at the destination? Forward Email's per-mailbox encryption is a real differentiator. We're straightforward about our model — TLS in transit, encrypted disks at rest — on /security. If cryptographic per-mailbox encryption is a hard requirement, verify any destination against it explicitly before moving.

Full side-by-side: MailHow vs Forward Email. Fundamentals: the complete guide to email on your own domain.