When your mail server goes down, your mail shouldn’t.
A second, independent mail host, designed to run across multiple availability zones, that holds incoming mail and delivers it when your main server recovers. We are building it — and we want to build it around what actually breaks for you.
A fallback route for your domain.
Standby nodes in independent zones.
Held until your server is back.
Your existing mailboxes stay put.
During an outage
Illustration — not live dataUnreachable
Senders retry for a while, then bounce. Nobody is holding it for you.
Holding mail
A second MX accepts what your server cannot and keeps it queued.
Multi-AZ · planned
Delivered automatically
When the primary is healthy again, the queue drains to it.
One server, one point of failure.
A long outage ends in a bounce
Most senders retry for a while, but a long outage ends in a bounce — and the sender rarely tells you. Invoices, orders and client replies disappear quietly.
You find out from a customer
Small hosts rarely tell you that inbound mail stopped. By the time someone calls, the outage has usually been running for hours.
A standby is another server to run
A second MX needs its own queue, retry logic and monitoring. Most small teams cannot justify operating one just in case.
A second route, not a second migration.
The design keeps your primary server exactly where it is. Mail Standby sits behind it as a lower-priority MX record.
- 01
Add a second MX
You point a lower-priority MX record at the standby. Your existing mailboxes and DNS do not move.
- 02
We hold what you cannot
While the primary is unreachable, senders fall through to the standby and the messages are queued.
- 03
The queue drains
When the primary answers again, queued mail is delivered to it automatically — no manual replay.
- 04
You see the record
Queue counts, how long mail was held, and an alert when the primary was first unreachable.
Multi-AZ, so the fallback has a fallback.
One standby server is still one server. The design target is a standby that runs across independent availability zones — where the hosting provider offers them, with separate power, network and cooling domains inside one region — so a single zone failure cannot take your fallback with it. It does not cover a whole-region or provider-wide failure; multi-region comes later.Planned architecture — not built yet
Independent zones
Standby nodes sit in different availability zones, so they do not share a power, network or cooling domain.
A zone can go dark
If one zone fails, the remaining nodes keep accepting mail for your domain. The queue is not tied to a single machine.
One region first
Multi-AZ is the first reliability step. Multi-region comes later, once the queue and delivery semantics are proven.
Nothing here is shipped yet.
These are the pieces we intend to build first. Your registration tells us which ones matter enough to fund.
Always-on standby host
Separate from your primary, with its own queue and independent monitoring.
Automatic redelivery
The queue drains to your primary as soon as it answers again.
Outage alerts
An email and SMS when your primary stops responding — not after a customer calls.
Read-only webmail
Look at what is held during a long outage without taking over your primary.
Queue visibility
See what is held, how old it is, and when delivery succeeded.
Multi-AZ redundancy
Independent standby nodes across availability zones, so a zone failure cannot take the fallback with it.
Founding cohort locks the 40% tier.
We cannot sell a product that does not exist yet, so there is no universal price to discount. What we can do is fix the spread: the add-on is planned at roughly 40–50% above your plan, and the first 50 registrations — a cap we enforce — lock the 40% tier for as long as they stay, with free setup for anyone who joins the beta. After the cohort fills, the standard early-access rate is the 50% tier. No card, no deposit, no obligation: if we never ship it, you have lost nothing.
Two minutes. It decides what we build.
We are measuring two things: whether a 40–50% premium is acceptable, and which long-standing email complaints are worth solving first. Both answers shape the beta.
Straight answers.
Is this available now?
No. Mail Standby is in development. Registering interest costs nothing and does not create an order. We will contact you before anything is chargeable.
Will it change my existing mailboxes?
The design adds a lower-priority MX record beside your primary. Your existing mailboxes, passwords and mail clients stay where they are. Nothing is migrated as part of the standby service.
What happens if my server is down for days?
The plan is to hold and retry queued mail. The exact retention window and overflow behaviour are still being designed, and founding members will be asked to confirm what they need before launch.
What does multi-AZ mean here?
Availability zones are independent power, network and cooling domains inside one region, where the hosting provider offers them. The design target is for the standby to run across several zones, so a single zone failure cannot take the fallback with it. It does not cover a whole-region or provider-wide failure — multi-region is a later step. Neither is built yet.
Can I read my mail while the primary is down?
Read-only webmail is on the candidate list, marked as dependent on interest. It is not promised yet, and the form is where you tell us whether it matters.
Why not just use a free backup MX?
A free or cheap backup MX will accept mail, but it usually gives you no way to read what is held, no multi-AZ placement, no alerting, and nobody to call. The value here is not the MX record itself — it is continuity you can see, and a human who owns it.
What happens to the mail you hold?
Three design decisions are still open, and founding members will be asked to confirm them: how long mail is held before it is returned to the sender, whether held mail is encrypted at rest, and how recipients are validated at the standby so the service cannot be used to generate backscatter. They will be published before the beta.
Why 40–50% more?
A standby host is a second server with its own queue, monitoring and support. That is real cost. We are asking now whether a premium is acceptable so we can scope the service to the answer instead of guessing.
What happens to my details?
They are stored in our own database and used only for this campaign. You can ask us to delete them at any time by emailing hi@mercstudio.com. We do not sell or rent the list.
If your email cannot fail, tell us.
The clearest signal we can get is a registration with a specific complaint attached. It takes two minutes and costs nothing.