Mailway documentation

Mailway is a smart gateway between your applications and your email providers. Your apps talk to Mailway over SMTP or the HTTP API; Mailway routes each message through your own provider accounts (Amazon SES, SendGrid, Mailgun, Postmark, …), fails over automatically when a provider misbehaves, and keeps a byte-for-byte archive of everything it relays.

Bring your own keys. Mailway is not an email provider — it sits above the one you already have. You keep your provider relationship, your reputation, and your pricing; Mailway adds routing, failover, observability, and an archive that can prove what was sent.

Get started

SMTP quickstartPoint your app at smtp.mailway.net and send your first mail in five minutes — no code changes beyond an .env file.

Send APIPOST /v1/send — JSON in, delivery out. Idempotency, batching, scheduling, and per-message provider routing.

Bring your own keysAttach your provider accounts, order the failover chain, and wire Amazon SES delivery events in fifteen minutes.

WebhooksSeven lifecycle events, Stripe-style HMAC signatures, automatic retries. Know when mail is delivered, bounces, or gets flagged.

Ruleswhen / if / then — tag, route, hold, or reject mail at the gateway instead of in every app.

Share links & proof of deliveryShow anyone exactly what was sent — and prove it, with an independently verifiable certificate.

DeliverabilitySPF, DKIM, and DMARC live at your provider under BYOK — what each record proves, and how to verify alignment before you send.

TroubleshootingFind your symptom — auth errors, stuck mail, bounces, quotas, webhooks — and map it to a cause and a fix.

How a send flows

1. Your app hands Mailway a message — over SMTP or POST /v1/send.
2. Mailway accepts it, stores it, runs your rules, and picks a provider from the ones you attached to the project.
3. If the provider rejects or times out, Mailway fails over to the next attached provider — the send survives a provider outage.
4. Delivery confirmations, bounces, and complaints stream back in from the provider — normalized into one delivery history whichever provider reported them — onto your webhooks, and into the project’s suppression list, where a bounce learned through one provider protects sends through all of them.
5. The full message — headers, body, attachments — is archived verbatim, so the console can show you exactly what left — and prove it.

Two environments

Host	Purpose
smtp.mailway.net / api.mailway.net	Production — messages relay to your providers. Live API keys (mw_live_…) work only here.
smtp.mailway.dev / api.mailway.dev	Sandbox — messages are accepted, stored, and visible in the console, but never forwarded automatically. Delivery only happens if you explicitly release a capture from the console. Test keys (mw_test_…) on the API door.

The payload shape is identical in both environments, so switching to production is a hostname and key change — nothing else.