889,000+ emails on the record since 2020

Every emailyour app sends,accounted for.

Your app has no Sent folder: once SMTP takes a message, no copy is left on your side. Point your SMTP config at Mailway and every message is kept exactly as sent, searchable, and provable years later, with automatic failover across your providers.

private beta  ·  EU-hosted  ·  bring your own providers  ·  watch it fail over →

m.01j9zk3vq7delivery record
sample record
from billing@yourapp.comto customer@gmail.comsubj Invoice #2041
09:41:02.113Received via SMTP :587 · TLS 1.3
09:41:02.129Routed → sendgrid · fallback, 1 of 3
09:41:02.351SendGrid → 535 credentials rejected
09:41:07.371Retry 1 → Amazon SES · after 5 s
09:41:07.513250 OK — accepted · 142ms
09:41:08.812Amazon SES reports delivered · bytes archived · searchable
strategy: fallback · 3 providersyour app saw: 250 OK
889K+
emails routed
since 2020
99.9%
accepted by a provider
after failover
320ms
avg handoff
to the provider
5yr+
in production
real customer volume

Bring your own keys, the providers you already pay for

Works with Amazon SES, SendGrid, Mailgun, Postmark, Mailtrap, Brevo, Mandrill, Gmail, and any SMTP provider.

How it works

The whole migration
is a config change.

the migration — mailer config
const transporter = nodemailer.createTransport({
- host: "smtp.sendgrid.net",
+ host: "smtp.mailway.net",
port: 587,
auth: { user, pass },
});
1

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 a REST API.

2

Paste in the keys you already have

Add your provider API keys, assign them to projects, pick fallback, free-first, round-robin, or random per project. All from the dashboard, with no deploy and no DNS archaeology.

3

Mailway takes it from here

Routing, retries, suppression, logging, archive, and switching providers never touches your code again. Here's one invoice's day through it.

Join the waitlistprivate beta · invites go out one at a time
10 April · 09:41

One invoice.
One bad password.

  1. 01 · The handoff

    Your app sends the way it always has.

    Plain SMTP to smtp.mailway.net on port 587, over TLS. Same mailer, same library. The host is the only line that changed.

  2. 02 · Written down first

    Nothing is acknowledged until it's on disk.

    Mailway writes the message to its ingest queue, and only then answers 250 OK. Your app moves on in milliseconds.

  3. 03 · The rules

    Your rules read it before any provider does.

    The subject contains “Invoice”, so it picks up the billing tag and takes the project's chain: SendGrid first, Amazon SES behind it.

  4. 04 · The failure

    SendGrid rejects the credentials.

    Someone rotated the SendGrid API key and one config missed it. A 535 during login is about your provider account, not the recipient, so Mailway files it as an auth failure and keeps the message queued.

  5. 05 · The retry

    Five seconds later, the next provider takes it.

    The problem is the SendGrid account, not your message, so there's no point waiting on it. The retry goes to the next provider in your chain, and Amazon SES accepts in 142 ms. No deploy, no code change, nobody paged.

  6. 06 · The inbox

    The invoice lands. Your customer never knew.

    Gmail's server takes it within a second, and Amazon SES reports that back as a delivery event. Only then does the record say delivered: accepted and delivered are separate facts, each recorded when a provider reports it.

  7. 07 · On the record

    Every attempt, every answer, the bytes themselves.

    Kept exactly as sent, for as long as your plan keeps it. Nobody looks at it for months. Then someone does.

m.01j9zk3vq7Invoice #2041 · billing@yourapp.com → customer@gmail.com
illustration · real sequence
your app
host: smtp.mailway.net
sending…✓ 250 OK · moved on
retry in 5 s
queue ✓rulesrouter
if subject contains "Invoice"→ tag billing
SendGrid
primary535 auth failed
Amazon SES
fallback250 accepted
Postmark
standing by
customer@gmail.com
Invoice #2041
delivery recordin flightaccepted · amazon sesdelivered · amazon ses
09:41:02.113Received via SMTP :587 · TLS 1.3
09:41:02.118Written to the ingest queue → 250 OK to your app
09:41:02.129Rule matched → tag billing · chain sendgrid → ses
09:41:02.351SendGrid → 535 credentials rejected · next provider in 5 s
09:41:07.513Retry 1 → Amazon SES · 250 accepted · 142ms
09:41:08.812Amazon SES delivery event → delivered · Gmail took it at 09:41:08.4
archived · 48 KB raw · sha-256 9f2c…a41e · searchable
09:41:08.812
Months later, legal asks

“What exactly did we send this customer?”
Your app kept no copy. Mailway did.

Every mail client keeps what you send; your app keeps none of it. Without Mailway, this is where someone greps logs and guesses. With it, legal searches the customer's address and opens every email your app sent them, exactly as sent, with what happened to each: invoice #2041, accepted by Amazon SES on 10 April at 09:41 and delivered to Gmail's server, the reminder before it, the terms change. For as long as your plan keeps them (up to unlimited on Enterprise or 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.

storedthe raw message, byte for byte: headers, attachments, original DKIM signature intact (SMTP relays; API sends are kept exactly as submitted)
foundby sender, recipient, subject, plus operators like state:delivered, before:2024-06-01, rescued:yes
openedrendered · plain text · headers · raw source · attachments, unchanged for your plan's full retention
console.mailway.net — Mails
to:customer@gmail.com
Invoice #20412026-04-10✓ delivered
Payment reminder — invoice #19872026-03-12✓ delivered
Changes to our terms of service2026-01-15✓ delivered
Your password was changed2025-11-02✓ delivered
Welcome to YourApp2024-06-18✓ delivered
renderedheadersrawinvoice-2041.pdf
FromYourApp Billing <billing@yourapp.com>Tocustomer@gmail.comDateFri, 10 Apr 2026 09:41:02 +0000
Invoice #2041YourApp
Amount due · €240.00due 10 May 2026
accepted by Amazon SES 09:41:07 · deliveredsha-256 9f2c…a41e · the bytes as sent
5 of 38 sent to this customeron the record since 2020
The Email Notary

Not just sent.
Provable.

So legal answers the complaint with a receipt, not a promise. Any message a provider accepted can be minted into a certificate: the content's SHA-256, the sender's DKIM verdict (SMTP mail), the provider's acceptance, and the recipient server's delivery event where the provider reports one. All of it is sealed with Mailway's signature and countersigned by an independent timestamp authority, so not even we could back-date one. The signature and timestamp verify offline, with standard tools, and it names the source of each claim: Mailway for the stored bytes, your provider's event for the delivery.

And where proof runs out, the certificate says so: accepted and delivered are different claims, never blurred.

How the notary works
Mailway · Email Notary
Certificate of Delivery
content sha-256 9f2c…a41e ✓ match
sender dkim d=yourapp.com ✓ verified
accepted provider msg-id · 09:41:02Z
delivered SES event · 09:41:03Z
sealed ed25519:Kx4v…9dQ=
countersigned RFC 3161 timestamp
The difference

Not another provider

Mailway doesn't replace SES, SendGrid, or Postmark. It sits in front of them and makes them interchangeable, which changes what they can do to you.

Without Mailway
Hardcoded to a single provider
Provider goes down = your emails stop
Switching providers means a code change
No single view of what was sent
Each provider only knows its own bounces
Days of retention, nothing to show a dispute
Locked into one provider's pricing
With Mailway
Route through any provider, or all of them
Automatic retry on a provider the mail hasn't tried
Switching is a dashboard action
Every email searchable, with a full timeline
Outcomes pool: a reported bounce protects every provider in the project
30 days to unlimited archive, by plan, + signed proof of delivery
Free tiers spent first, volume spread across providers

your providers · your keys · one gateway in front

the full comparison →
Built in Europe

Your email stays
on European soil

EU data residency

Your mail is ingested, routed, and archived inside the European Union, on servers in Falkenstein, Germany. Not "EU region available". EU, full stop.

Encrypted in transit & at rest

TLS on every SMTP connection, both STARTTLS and implicit TLS. Stored payloads compressed and encrypted at rest.

Your keys only

Pure BYOK. Your mail rides your own provider accounts, never pooled with other Mailway customers. Your reputation stays yours.

Proven in production

5+ years of real customer volume, 889,000+ messages, 99.9% accepted by a provider after failover. Not a weekend project.

one EU region today, with additional regions on the roadmap as we grow

Your mailer config has
one line 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.

read the docs meanwhile →

join the waitlist — mailway.net

Your invite, one email away.

Mailway is in private beta, and we onboard teams one at a time, in order. Leave your email and yours arrives when it's your turn.