Everything your email touches, in one place.
Mailway sits between your app and the email providers you already use. It keeps an exact copy of every email and shows what happened to each one, and if a provider refuses a mail, it sends it through the next.
An email gateway sits between your application and its email providers: your app hands a message to one endpoint, and the gateway keeps the record, decides which provider carries it, and retries when one fails. Mailway is that layer for transactional email, and the record is the point: for every mail it answers “what exactly did we send?” Adopting it is a config change: standard SMTP or HTTP in, your own provider accounts out.
Every message first walks the rules gate and your routing policy; the suppression list is checked again before any provider is contacted. From there the product answers three questions: what was sent (the archive, which works as your app's Sent folder), what happened to it (the delivery history), and whether you can prove it (proof of delivery, on Business and up). Automatic failover keeps the record whole when a provider refuses. Everything is BYOK. Mailway records and routes; your providers deliver and bill you at their prices.
The whole migration
is a config change.
Point your app at Mailway
Swap host, port, and credentials in the mailer you already use: Nodemailer, Laravel, Rails, smtplib, whatever ships your mail today. 7 SMTP ports open, so it works even where your cloud blocks the usual ones. Prefer HTTP? There's an HTTP API.
Paste in the keys you already have
Add your provider API keys, assign them to projects, and pick how each project chooses a provider: fallback (a fixed order), free-first (providers with free allowance left go first, counted approximately), round‑robin (each provider in turn), or random (the default). All from the console, with no deploy and no DNS changes.
Mailway takes it from here
Mailway handles routing, retries, suppression, and the archive. Switching providers never touches your code again.
Your app doesn't have a Sent folder.
Mailway gives it one.
Every mail client keeps what you send. Your app sends the more consequential mail and keeps none of it: receipts, reset links, and contracts vanish the instant SMTP takes them. Mailway archives each message exactly as sent, searchable by sender, recipient, subject, and state. So when a customer complains and legal asks what exactly was sent to them, and when, you open the emails themselves instead of a log line that mentions them, for as long as your plan keeps them (30 days on Free, a custom window on Enterprise, up to unlimited with a retention add-on).
And it doesn't have to be a developer who looks. Give support or legal a member seat and they answer "what did we send?" themselves, only for the projects you give them.
“Sent” is not
the whole story.
Most mailers call a mail “sent” as soon as a server answers 250, SMTP’s OK. That only means the server took the mail, not that it arrived. Mailway records the rest: every attempt, every provider response, every error code, down to the SMTP session for mail relayed over SMTP. So when support asks “did that email go out?”, you answer with a timeline.
Where a provider reports back (every supported provider except Gmail and Any SMTP server), its delivered, bounced, and complained events land in one normalized delivery history, beside every other provider's attempts and responses on the same timeline. No single provider can see across your whole sending; the gateway in front of them can.
- Search by subject, sender, recipient, or state
- Delivered, bounced, complained: one vocabulary for every provider that reports outcomes
- A bounce or complaint your provider reports blocks the address for every provider in that project
- The SMTP session behind every relayed message, credentials redacted
- Per-project analytics, with 30 days of volume
of delivery
“I never got that email.”
Here’s the receipt.
Every SMTP-relayed message is archived with its raw MIME and original DKIM signature. Any mail a provider accepted can be turned into an Ed25519-signed proof-of-delivery certificate, countersigned by an independent time authority so it can't be back-dated, and the certificate says whether it proves acceptance or delivery. The signature and the timestamp verify in anyone's browser, with no call to our database; compare the certificate's key with Mailway's to know it came from us. Share the rendered email itself with a private mailway.to link, and settle the dispute instead of having it.
Certificates are included on Business and up, and share links on Pro and up. Free has 1 limited share link a month.
30 days on Free, 90 days on Pro, 6 months on Team, 1 year on Business, custom on Enterprise, with retention add-ons (+1 year, +3 years, +7 years, or unlimited) for SOX, HIPAA, and FINRA record-keeping. All of it EU-hosted.
Providers fail.
Your app shouldn't notice.
Your app hands off once, gets 250 OK, and moves on. Mailway reads whatever the provider says back: a rejected key, an empty credit balance, a rate limit. Then it retries on the next provider in your chain five seconds later; a provider it has already tried waits on a widening backoff. Here's a bad day, handled with no one stepping in:
Failover needs at least two providers in a project. It is included on Pro and up, with up to 3 providers per project on Pro.
illustration · a failover chain of three · each retry to an untried provider leaves 5 s after the last failure
Four routing strategies
Primary provider first. When an attempt fails, the next provider in your chain takes it five seconds later; one this message already tried waits on a widening backoff (1, 5, 15, 30 min).
Providers with free allowance left go first. Paid volume mostly starts once the free capacity you entered is used up (an approximate count, not a hard cap), and exhausted providers stay available for failover.
Take providers in turn, one message after another. Spreads spend and sender reputation, and keeps any one account further from its rate limits.
A random provider per message, the default for a new project. Retries draw again, so for a guaranteed failover order pick Fallback.
Not all errors are equal
A permanent reject on a single-recipient send stops there instead of walking your chain. Addresses your providers report as bounced or complained go on your suppression list, and suppressed addresses are skipped before any provider sees them again. Everything else fails over, and every attempt is on the message's timeline.
One message in.
A defensible decision out.
Your app should send mail, not carry routing policy. Inside the gateway every message walks the same gate: your rules, which can tag it, hold it, or reroute it before any provider is chosen, and the suppression list before any provider is contacted. Every hold and tag lands on the mail's timeline; changing the policy is a console edit, not a redeploy.
3 rules evaluated · 2 matched · decision on the timeline
Your mailer config has
one block to change
Mailway is in private beta, and we onboard teams one at a time. Leave your email and we'll send your invite when it's your turn.