How it's built, and how it fails.

The path of a message

Your application speaks one of two protocols to Mailway: SMTP (seven submission ports, TLS on every one — STARTTLS or implicit) or the HTTPS send API. Either way, the same rule holds: Mailway stores the message durably before acknowledging it. The 250 OK or202 Accepted your app receives means "this message is now Mailway's responsibility, and a copy exists that a crash cannot take away."

From there: rules you've defined run against the message, the routing engine picks a provider from the accounts you attached, and failed attempts reroute through your chain — a timeout at one provider becomes a handoff to the next, mid-send. Whatever the providers report back — acceptance, delivery, bounce, complaint — lands on the message's timeline and, if you want it, on your own endpoint as a signed webhook.

① the store, ② the acknowledgement — in that order, always; the two boxes beneath the checkpoint are where it lands. The dashed lane is the evidence path: what your providers report flows onto the message's timeline and, signed, to your endpoint. This page is about what happens when a step of this picture breaks.

Does the gateway become another single point of failure?

Honest framing first: yes, a gateway is a new hop, and a new hop is a new thing that can fail. The design answer isn't to pretend otherwise — it's to make every failure loud, lossless, and cheap to route around.

Nothing is acknowledged before it's stored. If Mailway cannot durably store your message, you don't get a 250 — you get a failure code while the message is still yours. For SMTP that means your mailer's own queue keeps it and retries, exactly as SMTP was designed to behave. For the API it means a non-2xx and a retry on your side — idempotency keys make those retries safe, so an ambiguous timeout can't become a duplicate send.

If Mailway is unreachable, nothing is silently lost. A message that never got its acknowledgement was never Mailway's — your mailer spools and redelivers, your API client retries. The failure mode of an outage is delay, not loss, and delay is visible on your side the moment it starts.

Accepted mail rides out provider failures. Once a message is stored, a provider outage triggers the failover chain: the error is classified (a provider timeout is not a bad address — a hard bounce is suppressed, never retried through the next door), attempts walk your chain with retries, and a message that exhausts every option is stamped with an explicit exhausted state you can see and act on in the console. There is no state where mail sits invisible.

One region, said plainly. Mailway runs on dedicated hardware in one EU region today. There is no multi-region failover claim on this page because there is no multi-region failover — when that exists, it will be written here, and not before.

Durability & recovery

Two stores carry your mail. Message content lives in object storage in the EU (AWS S3, Frankfurt), replicated across facilities by the storage layer itself. The metadata and index — what the console searches, what the timeline renders — live in a database on Mailway's own EU hardware.

The database ships nightly encrypted backups off the primary machine, with binary logs retained between snapshots for point-in-time recovery. Restores are rehearsed, not assumed — a backup that has never been restored is a hope, not a plan.

Deletion is policy, never accident: retention follows your plan, expiry runs on schedule, and what your plan retains stays readable for as long as it says.

Failure semantics, surface by surface

SMTP submission fails

A temporary failure returns a 4xx — your mailer requeues and retries on its own schedule. Permanent rejections (bad auth, malformed message) return 5xx with a specific code. Nothing that wasn't acknowledged is Mailway's to lose.

API submission fails

Non-2xx with one documented error envelope — branch on error.code. Retries with an idempotency key are exactly-once from your perspective; rate-limit responses carry Retry-After. The whole contract is machine-readable at /openapi.yaml.

A provider attempt fails

The error is classified before anything is retried: infrastructure failures walk the failover chain; address-level verdicts (hard bounce, complaint) go to the suppression list instead of the next provider. Every attempt — including the failed ones — is on the message's timeline.

Everything fails

A message that spends every retry on every eligible provider is stamped exhausted — a visible verdict with a retry action, not a mail quietly stuck in "pending".

Your webhook endpoint is down

Deliveries are at-least-once with a backoff ladder (six attempts over roughly nine hours); an endpoint that keeps failing for 24 hours is disabled rather than hammered, and you re-enable it when it's healthy. Dedupe keys are documented.

The recipient's server is the problem

Provider-accepted is not delivered, and Mailway never blurs the two. Recipient-side outcomes surface as delivery events where the provider reports them; where a provider doesn't, the timeline says "accepted" and stops — it never rounds up.

Trust boundaries

Mailway ingests, processes, and stores your mail in its EU region. The onward path follows the providers you connect — a message handed to your US provider account goes where your provider takes it; that choice stays yours, stated plainly rather than hidden behind an EU badge.

BYOK means the boundaries stay clean: your provider credentials are stored encrypted, scoped to your team, and used only to send what you configured. Your mail never rides a shared Mailway sending account, and your DNS — SPF, DKIM, DMARC — lives at your provider, untouched. Mailway is not in your authentication path, which is half of why leaving is cheap (next section). Sub-processors, encryption specifics, and the disclosure policy live on the trust page.

If you leave

Rollback is a first-class scenario, not a fine-print one. Because the provider accounts are yours, reverting to a direct provider connection is the same kind of change that adopting Mailway was: one mailer configuration block — host, port, credentials — or one API base URL. There is no DNS to migrate, no reputation to rebuild, no export ransom: your archived mail stays readable for its retention window, raw source downloadable per message.

What this page doesn't claim

No multi-region high availability — one EU region today. No delivery guarantees — nobody who is honest offers those. No inbox-placement promises — evidence, not assurances. If a sentence on this page stops being true, the sentence changes; that's the maintenance contract this page ships with.