# MailStoa — full published content

> 6 articles. Source: https://mailstoa.com


---

## The Mailcow arc — and what comes next when self-hosting wears out

Source: https://mailstoa.com/blog/mailcow-burnout-managed-mail-alternative
Published: 2026-05-31
Tags: mailcow-alternative, self-host-burnout, eu-jurisdiction, public-roadmap, pillar-3

Self-hosted mail tends to follow the same 12-month curve: heroic in month one, quiet attrition by month twelve. The interesting question is what the burnt-out self-host operator wants next.

There's a specific arc that self-hosted mail tends to follow. It usually goes:

1. **Month 1.** You read the Mailcow Docker docs over a weekend. The setup is clean, the project is well-maintained, the docs are good. You stand up mail for two domains. It works. You feel slightly heroic.

2. **Month 3.** Everything mostly still works. You've debugged one DKIM rotation, fixed a Rspamd false positive, and resized the disk once because Maildir grew faster than expected. Background friction is real but bearable.

3. **Month 6.** Some Microsoft 365 recipient silently dropped your mail and you only noticed because a customer asked why they hadn't gotten a password reset. You spend two evenings on Microsoft's SNDS portal and reading about "Outlook reputation."

4. **Month 9.** Cert auto-renewal broke during a kernel upgrade. Postfix queue backed up for six hours before you saw the alert. You wrote your third Sunday-afternoon-debugging post-mortem.

5. **Month 12.** You realise that the dollar cost of Mailcow was zero but the time cost has been significant, and that running mail is now an ambient background process in your head competing with the things you actually want to build.

Not everyone hits this. Some operators love mail; the puzzle is the point. But the dominant arc, especially among indie founders whose actual product isn't email, ends here: not in a crash, just in quiet attrition.

## Why this arc is so consistent

Mail is one of the few things on the modern internet where the operator burden grows the longer the service runs, not the shorter. The reasons:

- **Reputation decays.** Even a well-configured server's deliverability drifts over time as filtering rules change at the receivers' end. You don't set it and forget it.
- **The dependency surface is broad.** Postfix, Dovecot, Rspamd, ClamAV, OpenDKIM (or Rspamd signing), Sieve, the TLS cert pipeline, the DNS records, the IP's blocklist status, the reverse DNS — any of them breaking is your problem.
- **Failures are silent.** Most mail problems are "the message disappeared into a recipient's spam folder," not a 5xx error. You only learn about it when a customer notices.
- **The receivers are oligopolies.** Google, Microsoft, and Apple between them handle the inboxes that matter, and each has its own opaque filtering system. You're playing against their unilateral rules.

For someone whose product is mail (Migadu, Fastmail, Mailgun), this is their full-time job and they're good at it. For someone whose product is a SaaS that *uses* mail, this is overhead.

## What the burnt-out self-host operator actually wants next

The interesting thing — and the reason this post exists — is that the operator coming off a Mailcow year usually doesn't want to go to Google Workspace next. The Google answer feels like giving up on something that mattered, not solving the actual problem.

What they want is more like:

- **Someone else handles the operations,** but the philosophy is still adjacent to what they were trying to do themselves.
- **Hosting in a jurisdiction they trust.** Often the same EU/Germany/Switzerland location they self-hosted in.
- **An operator who treats email as the product,** not as a side feature of a larger productivity suite.
- **Honest about its scope.** Indie scale, indie tooling. Not pretending to be enterprise.
- **A way out.** If the operator stops, you can export your mail and move. Not locked in.

This is the "managed but principled" position. It's the soft landing after the self-hosted year.

## What MailStoa is trying to be

MailStoa is built explicitly for this audience — and I'm being honest about it because I went through the same arc myself (Mailcow for a year on Hetzner, then back to a managed provider, then frustrated enough with the managed options to build this).

The positioning:

- One operator (me), one piece of infrastructure, EU/Germany hosted on Hetzner — the same setup most self-hosters were doing themselves.
- A public roadmap, public status page, public transparency report.
- Standard IMAP/SMTP — your existing clients work; no lock-in to a proprietary protocol.
- A documented data-export tool from day one. If MailStoa stops, you take your Maildir and go.
- Flat $49/year for unlimited domains — so the multi-product founder shape gets the same operational simplicity.

It's not for everyone. If you genuinely enjoy running mail, keep doing it; Mailcow is excellent software. If you don't, but you also don't want to retreat to Google Workspace, the managed-but-principled lane is where MailStoa sits.

## When to make the call

Practical signals that you've hit the point on the arc where outsourcing makes sense:

- You've debugged a deliverability issue at a US recipient and lost a customer-trust moment because of it.
- You've spent a weekend on what was supposed to be a Saturday-morning fix.
- You're delaying a kernel upgrade because last time it broke certbot.
- You catch yourself thinking "I should just move everything to Workspace" and then immediately not wanting to.

That last one is the diagnostic. If "just go back to Google" is the obvious answer and it still feels wrong, there's a third option worth looking at.

The [/founding](/founding) offer is $99 lifetime, refundable until V1. If you've done a year of Mailcow, you know how to evaluate the trade.


---

## EU email hosting without self-hosting your own Postfix on a Sunday

Source: https://mailstoa.com/blog/eu-email-hosting-indie-founders-privacy
Published: 2026-05-31
Tags: eu-jurisdiction, hetzner-germany, privacy-conscious, public-roadmap, pillar-3

Privacy-conscious founders don't want to hand email to a US hyperscaler. They also don't want to babysit Mailcow at 11pm. The 'managed but principled' lane is where this lives.

There's a specific kind of founder who reads the standard email-hosting recommendations — Google Workspace, Microsoft 365, Fastmail — and feels a quiet objection that isn't really about features or price. The objection is *about who's holding your email*.

It's not paranoia. It's that email is the universal account-recovery mechanism for every other service you use, so the company that hosts it has unusual leverage. Handing that leverage to a US tech giant feels like the wrong default if you have any other option.

The standard answer to this objection used to be "self-host." That's becoming a less reasonable default for reasons worth being honest about.

## Why "just self-host" stopped being a sufficient answer

Mailcow, Mail-in-a-Box, iRedMail, Modoboa — the self-hosted options are excellent software. The problem isn't the software; it's the operational shape:

- **IP reputation is hard.** Hetzner gives you a fresh IP that may or may not be on Microsoft's blocklist on day one. Recovering reputation is a multi-week support-ticket exercise.
- **Email infrastructure is full of weekend incidents.** TLS cert auto-renewal breaks. Postfix's queue fills up. DKIM signing gets misaligned after an upgrade. Rspamd's thresholds need tuning.
- **You're now an email operator.** Once your customers depend on `hello@yourcompany.com` for password resets, you can't take your mail server down for a Sunday afternoon to "just upgrade something."
- **The dependency stack is long.** Postfix, Dovecot, Rspamd, ClamAV, Sieve, OpenDKIM/Rspamd-signing, certbot, your DNS provider, your IP's blocklist status, your reverse DNS — all of them need to be right.

None of this is impossible. It's just an order of magnitude more time than the "weekend project" framing suggests. For someone whose actual product isn't email, that time is the cost.

## What "principled but managed" actually means

The position that's emerging for founders who don't want self-hosting and don't want Google is something like:

- Email hosted by a small operator, not a hyperscaler.
- Hosted somewhere with strong privacy law (typically the EU).
- Run by someone whose business model is the subscription, not data or upsells.
- Operationally durable — you don't have to be the one debugging it at 11pm.

That last point is the one self-hosting can't satisfy without your weekends. The first three are the ones Workspace/365 can't satisfy structurally — they're large companies whose business model is broader than email.

In practice, the providers that occupy this position today are: Fastmail (Australia, well-regarded, premium pricing), Migadu (Switzerland, technical audience, slightly dated UI), Posteo (Germany, privacy-focused, idiosyncratic), Tutanota / Proton (their own protocols, not interoperable IMAP). Each is a slightly different shape of the same idea.

MailStoa is built deliberately in this niche, with a specific positioning: indie operator, German hosting, public roadmap, modern UI, flat pricing.

## Why Germany specifically

The reasons stack up:

- **Jurisdiction.** GDPR and ePrivacy enforcement is real and applies to the data center.
- **Hetzner.** Hetzner Falkenstein is a known, mature data center with EU billing and EU law applying to the contract. Cheap enough that the business model doesn't require advertising or upsells.
- **Cable distance.** Most European customer email lives within a few network hops; latency for inbox loads is small.
- **No CLOUD Act exposure.** Data stored exclusively in EU infrastructure by an EU operator is structurally different from data stored by a US company in an EU region.

The trade-off worth being honest about: you lose proximity to Google's calendar/Drive integration. For founders who already aren't running Google as their core productivity stack, that loss is small. For Google-natives, it's the whole reason to stay.

## Operator transparency

The other axis privacy-conscious founders look at: who's running this, how do they communicate, what happens if they get a subpoena?

The honest answer for a small operator like MailStoa:

- One human (Khoa) runs it. Not anonymous; visible on X, GitHub, the StoicSoft network.
- A public roadmap on the site. A public status page. A public transparency report at year-end.
- A documented 10-year commitment, with what happens if it can't continue (export tooling, data-portability guarantee).
- Email never used for cross-product advertising — there's no ad business to feed.

None of that is unique. It's also not the structural default of a hyperscaler.

## When this isn't the right fit

For founders who:

- Run their business inside Google Workspace's collaboration suite (Docs/Sheets/Meet daily). The integration is the product; switching loses too much.
- Need enterprise compliance — HIPAA BAA, SOC 2 reports, advanced eDiscovery. MailStoa is for indie scale, not Fortune 500.
- Want anonymous E2E mail (Proton, Tutanota). Different problem; standard IMAP/SMTP isn't the answer.

For everyone else who reads "Google Workspace" as the default recommendation and feels a small wrong-shape signal: it might be worth checking the EU-indie-operator side of the market.

The [/founding](/founding) offer is the low-risk way to try the position — $99 lifetime, refundable until V1.


---

## MXroute deliverability without the 2010-era admin panel

Source: https://mailstoa.com/blog/mxroute-alternative-modern-ui-multi-domain
Published: 2026-05-31
Tags: mxroute-alternative, purelymail-alternative, modern-webmail, multi-domain, pillar-1

Budget email hosts win on deliverability. They lose founders on UI. Here's the respectful intercept for founders who'd choose MXroute if the panel matched the reliability.

MXroute has a reputation. If you've spent any time in LowEndTalk, Hacker News email threads, or the indie-hosting corners of the internet, you've seen it recommended dozens of times — usually with some version of "the UI is rough but the deliverability is great."

That recommendation is honest, and the people making it aren't wrong. MXroute's reliability and inbound/outbound reputation are genuinely impressive for the price. The "UI is rough" part is also genuinely true.

For a long time that trade was easy: founders who cared most about deliverability accepted DirectAdmin and Roundcube; founders who cared about UI paid for Fastmail or Workspace. The split was clean. What's changed is that more founders sit in the middle — they care about both — and there isn't an obvious option for them.

## Why the UI matters more than purists admit

There's a recurring response to "the UI is dated" complaints which goes something like: "It's just email. Use IMAP and your favourite client." That advice is correct in the abstract and also misses the actual texture of being a multi-domain solo operator.

You don't only use email through one client. You read it on your laptop's mail app, sometimes the iPhone Mail app, sometimes the web interface when you're on someone else's machine. The web interface matters because:

- **Mobile web is the fallback when the native app misbehaves.** Roundcube on mobile in 2026 is a rough experience.
- **Admin tasks live in the web UI.** Adding a domain, creating an alias, checking bounce logs, rotating an SMTP password — all of it happens in the panel. A 2010-era admin panel does these things slowly and with friction.
- **Switching between products.** A multi-domain founder is constantly moving between inboxes. The web UI's domain/alias switching becomes the daily-use surface.

The "use IMAP" advice is real but partial. The panel is where the friction lives.

## What "modern UI" actually means in 2026

It's not skeuomorphic gradients or animation. The bar most founders have settled on, after using Fastmail / Migadu / Hey / Superhuman, is:

- **Fast.** Inbox loads in under 500ms; search returns in under a second.
- **Keyboard-shortcut-driven.** Gmail's hotkeys are now the universal grammar; matching them removes a cognitive layer.
- **Native-feeling on mobile web.** Tap targets that don't require precision; readable fonts; no horizontal scrolling.
- **Multi-domain awareness.** The fact that you have several domains is a first-class concept, not a buried setting.
- **Admin tasks in the same UI.** Add a domain, add an alias, rotate a password — without leaving for a separate cPanel-style admin.

None of those are hard requirements. They're the implicit baseline modern web apps set. A mail UI that doesn't meet them feels like infrastructure that was designed for a different decade.

## The respectful intercept

To be clear: this is not "MXroute is bad and you should leave." MXroute is great. People who love it have good reasons. If you're on $40/year MXroute and happy, stay.

What's worth thinking about is the *adjacent* audience — founders evaluating MXroute who are bouncing off the UI not because they're spoiled but because their daily workflow now lives in a modern web mail app and they don't want to context-switch into a 2010 panel.

For that audience the trade looks like:

| Need | MXroute (and similar budget hosts) | MailStoa |
|---|---|---|
| Deliverability | Excellent | Hetzner Falkenstein, mature setup |
| Multi-domain | Yes | Yes |
| Pricing | $40–50/year | $49/year |
| UI | 2010-era panel + Roundcube | Modern web app |
| Mobile web | Functional | Native-feel |
| Setup | DirectAdmin | One panel, single sign-on |

The price point is close enough that UI becomes the real decision. That's the part of the market MailStoa is built for.

## When MXroute is still the right call

There are specific cases where MXroute remains the better choice and switching would be a downgrade:

- **You manage email professionally and prefer DirectAdmin.** The control surface MXroute exposes is broader than MailStoa's intentionally is.
- **You're at a specific storage/volume tier where the math works out.** MXroute's storage tiers can be cheaper at scale.
- **You don't care about UI at all.** If everything happens in Apple Mail anyway, you'll never see the panel after setup.

MailStoa isn't trying to displace MXroute for those users. It's the alternative for everyone who would have chosen MXroute *if* the UI matched the deliverability.

If that's you, the [/founding](/founding) offer locks in $99 lifetime — refundable until V1 ships if it turns out not to be a fit.


---

## One SMTP relay for every product instead of one vendor per product

Source: https://mailstoa.com/blog/one-smtp-relay-for-multiple-saas-products
Published: 2026-05-31
Tags: smtp-relay, transactional-email, resend-alternative, postmark-alternative, pillar-2

A typical multi-product founder has Resend, Postmark, Mailgun, SendGrid, and one cron job spread across five repos. The fragmentation tax is invisible until you total it.

Each new product launch goes the same way: ship the MVP, realise it needs to send transactional email, pick the path of least friction, ship it. The path of least friction is usually whatever's on the "10 minute setup" docs that day — Resend, Postmark, Loops, Mailgun, SendGrid, AWS SES.

That decision is roughly 8 minutes long and is repeated for every product. A few launches later, you're looking at five different transactional email vendors, five DKIM records to maintain, five bills in different currencies, and a `process.env.MAIL_PROVIDER` that's a different string in each repo.

This is the fragmentation tax. It's almost invisible while it's accumulating.

## The shape of the problem

A real example, lightly fictionalised, of what a multi-product founder's transactional email looks like after 18 months of shipping:

| Product | Provider | Why that one |
|---|---|---|
| Product A | Resend | It was new and trendy when you launched A. |
| Product B | Postmark | A had Resend issues; you tried Postmark for B. |
| Product C | Mailgun | Cheaper at expected volume. |
| Product D | SendGrid | Inherited from a template you cloned. |
| Personal blog | Just SMTP via Gmail | You forgot you needed transactional and threw together a script. |

Each one has:

- A separate DKIM record in DNS.
- A separate sending-domain or subdomain configured.
- A separate dashboard for tracking bounces and complaints.
- A separate API key in a separate environment variable in a separate `.env` file.
- A separate monthly bill, often on a different billing cycle.

Nothing here is hard. Each individual setup is fine. The problem is the *total count* of separate setups — the cognitive overhead of remembering which product uses which provider when something breaks at 11pm.

## Why founders don't consolidate

The obvious answer is "just standardise on one provider." Founders don't, for three reasons:

1. **The provider you picked for Product A might not be the right price tier for Product C.** Postmark is great until volume scales; SES is cheap but the onboarding is hostile; Resend's pricing is friendly until you cross thresholds.
2. **Switching providers in an existing product is risky.** Email is a thing where "it works" is hard-won; nobody wants to re-engineer it for a product that's already live.
3. **The bill is small enough per product to not be worth fixing.** $10/month here, $15/month there — each line item alone is forgettable. The aggregate becomes a problem only when you sit down to total it.

So the fragmentation accumulates. Each individual decision was rational. The aggregate is the cost.

## What "one SMTP relay" actually means

The simplification — once you've felt the fragmentation tax — is to run all your products through one SMTP endpoint. Every app's password-reset, signup-confirmation, receipt, and notification email goes out via the same relay credentials.

This sounds boring and is. The boring details are the value:

- **One DKIM record** to set up per sending domain (still per domain — that's a DNS requirement, not avoidable), but with one provider's signing key.
- **One bill.** One renewal date. One dashboard.
- **One set of credentials** to rotate when needed.
- **One deliverability story** to debug when something gets flagged.
- **One mental model** for the whole network.

The trade is: you lose access to fancy per-provider features (Postmark's templates, SES's huge scale, Resend's React-Email integration). For most indie products, those features aren't load-bearing — `nodemailer` against a plain SMTP relay does the job.

## What MailStoa does about this

MailStoa includes an outbound SMTP relay as part of the $49/year base plan. Your apps' password resets, signup confirms, receipts, and notifications go through the same infrastructure that handles your inbox. Same credentials, same dashboard, same DKIM signing for any domain you've added.

It's not the best transactional email service on the market — Postmark wins on dashboards, SES wins on price-at-scale, Resend wins on developer experience. MailStoa wins on *not being a separate purchase*.

For a multi-product founder shipping side projects, that's usually the right trade. The fancy features matter less than the cognitive load of running yet another vendor.

If your transactional email is already fragmented across three or more providers, the consolidation alone is worth thinking about. The [/founding](/founding) offer ($99 lifetime) gives you a low-risk way to try it before V1.


---

## When forward-only inbox setups stop being enough

Source: https://mailstoa.com/blog/cloudflare-email-routing-vs-real-send-as
Published: 2026-05-31
Tags: cloudflare-email-routing-alternative, send-as, multi-domain, indie-hacker, pillar-1

Cloudflare Email Routing is one of the best free services on the modern internet. It's also receive-only, which matters more than founders expect.

Cloudflare Email Routing is one of the best free services on the modern internet. Set up a custom-domain inbox in four minutes, route `hello@yourdomain.com` to your existing Gmail, done. Costs nothing. Works.

It's a fantastic answer to "how do I receive email on a custom domain." It is not, however, an answer to the question most founders are actually asking, which is: "how do I *use* a custom-domain inbox for real correspondence."

The gap between those two questions is where forward-only setups quietly fall apart.

## What "send-as" actually means

When a customer emails `hello@yourproduct.com`, Cloudflare forwards the message to your Gmail. You read it. You hit reply.

That reply now goes out from `you@gmail.com`, because that's the actual mailbox sending it. Gmail's "Send mail as" feature can be configured to send from `hello@yourproduct.com` instead — using your old domain's SMTP, or Cloudflare's outbound relay, or some other route — and it kind of works.

But it's fragile in a way that compounds:

- **Different Gmail clients show it differently.** Some show `hello@yourproduct.com via gmail.com`. The `via` tag is small. Sophisticated customers see it.
- **DKIM/SPF alignment is awkward.** Your reply is signed by `gmail.com`, not by your product domain. Modern mail filters notice. Some flag it. Most don't, but a meaningful percentage do.
- **You can't easily set up a Reply-To different from From.** And if you misconfigure it, customers reply to your personal Gmail thinking they're replying to your business.
- **Setup is per-mailbox.** Add another domain? Configure Send-As again. Add another alias? Configure again. The friction scales with how many products you ship.

The first version works. The hundredth message reveals the cracks.

## The audience this actually matters to

If you only need to receive password resets and the occasional cold pitch, none of this matters. Forwarding is genuinely sufficient.

The audience for whom forwarding breaks down:

- **Support handlers.** You're replying 5–50 times a day from a support address. Every one of those goes out via Gmail with a small inconsistency.
- **Sales contact.** You're trying to look like a real business to enterprise prospects. The `via gmail.com` tag is small but expensive.
- **Multi-domain operators.** You've configured Send-As four times across four products and each one drifted slightly. Two work, two send from the wrong identity.
- **Founders who want SPF/DKIM/DMARC alignment without a 6-page setup doc.** You want reply-from-your-domain to be the default, not a feature toggle.

For these cases, the real fix is sending from your domain *for real* — your DNS, your DKIM signature, your reputation.

## What "real send-as" looks like

What you actually want is a mailbox that lives on your domain. Receives email at it. Sends email from it. DKIM-signs with your domain's key. Reply-To and From match. Your domain's SPF record authorises the sending server because it actually is the sending server.

This is what proper email hosting does — Fastmail, Migadu, MXroute, Google Workspace, and yes, MailStoa. The cheap option (Cloudflare Routing) buys you receive-side parity but punts on send-side.

The honest framing: forwarding is *receive emulation*. Hosting is *real ownership*.

## When to switch

Practical decision points:

- You've sent a reply to a customer and noticed the `via gmail.com` tag.
- You've replied to support and the customer responded to your personal Gmail by accident.
- You're past 2 domains and configuring Send-As is now a chore you put off.
- A potential enterprise customer asked why your email "looks like a Gmail address."

If any of those have happened, forward-only has aged out. The free tier did its job — it got you started — and now your customer-facing identity needs to actually be yours.

## What MailStoa does here

MailStoa hosts the mailbox. You add the domain, point MX, and `hello@yourdomain.com` becomes a real inbox that sends from your domain with proper DKIM signing. Multi-domain operators add as many domains as they want under the same $49/year — there's no per-domain charge, so the "is this worth setting up?" question doesn't apply.

Cloudflare Email Routing is a great place to start. The moment you outgrow it, the next step is hosting, not workarounds. That's the gap MailStoa is built for.

If you're past the forwarding phase, the [/founding](/founding) offer locks in $99 lifetime; the runway pre-sale runs through this build.


---

## Google Workspace fatigue at the third product domain

Source: https://mailstoa.com/blog/google-workspace-cost-multiple-domains-indie-founders
Published: 2026-05-31
Tags: google-workspace-alternative, multi-domain, flat-price, indie-hacker, pillar-1

Per-user-per-domain pricing is fine for one inbox. At three domains, the math stops being about money and starts being about whether you're being charged per side project.

If you run one product on one domain, Google Workspace at $7/month is fine. Two domains, $14, still fine. Three domains and suddenly you're paying $21/month for a single inbox you check from one phone, and it starts to feel like you're being charged per side project rather than per person.

This is the indie-founder shape of the email-hosting problem. The bill isn't catastrophic — it's quietly misaligned. The product isn't designed for someone who launches a new domain every quarter and uses the same Apple ID, the same laptop, and the same brain across all of them.

## The math gets uglier the more you ship

A typical multi-product solo founder's domain list, a few years in:

- `yourname.com` — personal landing
- `firstproduct.com` — the SaaS that's paying the bills
- `secondproduct.com` — the smaller tool that's growing
- `experimentdomain.com` — last quarter's launch
- `nextidea.com` — registered three weeks ago because the name was available

That's $35/month on Google Workspace before you've added a single employee. $420/year. For one human checking five inboxes that mostly receive password resets and the occasional support ticket.

It's not that the money is impossible. It's that it scales the wrong way: linearly with how often you ship. Every successful product launch makes the email bill grow at the exact moment you'd rather be putting that capital into Stripe fees, Hetzner, or a second monitor.

## Why the alternatives haven't caught on

Founders in this position usually try one of these and bounce off:

- **Cloudflare Email Routing.** Free, elegant, forward-only. The moment you need to *reply* from `hello@yourproduct.com`, the illusion breaks — your reply goes out from `you@gmail.com` and the customer notices.
- **MXroute / Purelymail.** Beloved by LowEndTalk for good reason: cheap, reliable deliverability. The UI is from 2010 and the mobile experience is "use a different app."
- **Self-hosting Mailcow.** Works for the first week. Then your Hetzner IP ends up in a Microsoft blocklist on a Sunday and you spend the next three weekends learning about Rspamd thresholds you didn't want to learn about.
- **Defer the problem.** Use `you@gmail.com` and a forwarding rule. Works until your support load grows or a customer asks why your "company email" is on a free provider.

None of these are wrong. They're just optimized for a different shape of person. The "I run several small products" shape is genuinely underserved.

## What flat-pricing actually changes

MailStoa is $49/year flat. Unlimited custom domains under one bill. The arithmetic stops being per-domain — at five domains, that's $0.82/month per domain; at ten, $0.41. The pricing curve flattens at exactly the moment your domain count goes up, which is the opposite of how Workspace behaves.

For a multi-product founder, this changes the decision: *every new domain you register is now "$0 marginal email cost"* until you hit storage limits. Naming a side project no longer triggers a billing question.

That's the entire idea. The infrastructure (Hetzner Falkenstein, Germany; SMTP relay included; modern webmail) is the implementation. The pricing model is the product.

## When this is the wrong fit

To be clear about who shouldn't switch:

- **One domain, one user, never going to change?** Workspace is fine. The Docs/Drive integration alone earns the $7.
- **Team of 5+ with shared calendars and Drive workflows?** Workspace's collaboration suite is the real product; email is incidental.
- **Need calendar federation, advanced eDiscovery, or M365 interop?** Stay with the big providers.

MailStoa is for the solo operator who keeps registering domains. If that's you, the third domain is where the per-domain pricing starts feeling wrong — and that's also where flat-pricing starts paying off.

If you want the founding-member offer ($99 lifetime, refundable until V1 ships), [/founding](/founding) has the details.