Every emailyour app sends,accounted for.
Your app has no Sent folder. Mailway gives it one: every email kept exactly as sent, with what happened to it, so anyone on your team can answer “what exactly did we send?”
private beta · EU-hosted · bring your own providers · open the Sent folder →
Bring your own keys, the providers you already pay for
Works with Amazon SES, SendGrid, Mailgun, Postmark, Mailtrap, Brevo, Mandrill, Resend, Mailjet, MailerSend, Nuntly, SMTP2GO, Gmail, Microsoft 365, SparkPost, Elastic Email, Zoho ZeptoMail, and any SMTP server.
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. Here's one invoice's day through it.
One invoice. Every step on the record.
- 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. Only the host and the SMTP credential changed.
- 02 · Written down first
Nothing is acknowledged until it's written down.
Mailway writes the message to its ingest queue, and only then answers 250 OK, the SMTP reply that means “received”. Your app moves on in milliseconds.
- 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.
- 04 · The refusal
SendGrid refuses. The record says why.
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, writes SendGrid's own answer into the record, and keeps the message queued.
- 05 · The failover
Five seconds later, Amazon SES takes it.
The problem is the SendGrid account, not your message, so Mailway fails over to the next provider in your chain, and Amazon SES accepts in 142 ms. No deploy, no code change. Both attempts stay on the record.
- 06 · The delivery
Delivered, because the provider said so.
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. Failover changed which provider carried it. Whether a mail reaches the inbox still depends on your sender domain and your provider.
- 07 · In the Sent folder
Every attempt, every answer, the bytes themselves.
Kept exactly as sent in your app's Sent folder, for as long as your plan keeps it. Nobody looks at it for months. Then someone does.
“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 (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.
Not just sent.
Provable.
So legal answers the complaint with a receipt, not a promise. Any message a provider accepted can be turned 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. Certificates are included on Business and up.
How proof of delivery worksNot another provider
Mailway doesn't replace Amazon SES, SendGrid, Postmark, or any other provider you use. Your provider accounts, keys, and sender domains stay yours. Mailway sits in front of your providers and adds one thing: the record.
- Provider accountsfor example Amazon SES, SendGrid, Postmark
- Provider keyscreated in your provider account, stored encrypted
- Sender domainsverified at your provider
- Sender reputationnever pooled with other Mailway customers
- Provider pricingbilled to you, no markup
- Your mailerover SMTP, only the host and SMTP credential change
- An exact copy of every email your app sends: its Sent folder.
- Every provider's answer, and delivery events where the provider reports them.
- Failover when a provider refuses, on Pro and up.
One record.
No gaps.
Mailway sits between your app and the providers you already pay for. It keeps what your app sent and shows what happened to it, and on Business and up it can prove it. If a provider refuses a mail, failover sends it through the next.
Product overviewSent folder
The archive of every email your app sends. Open any one to see its exact HTML, text, headers, and attachments, and search by sender, recipient, subject, or state.
Explore the archiveDelivery history
What happened to each mail after your app sent it: when Mailway received it, the rules it matched, every provider attempt and answer, and the delivery events the provider reported.
See the timelineProof of delivery
Once a provider accepts a mail, you can create a signed proof-of-delivery certificate: what was sent, when, and the delivery event if the provider reported one. It verifies offline with standard tools. Available on Business and up.
See proof of deliveryAutomatic failover
Keep multiple providers behind one endpoint. When one refuses a mail over a rejected key or an empty credit balance, the next one sends it, without a redeploy. Available on Pro and up.
See provider failoverSend one email through the whole system.
Pick the route, fail a provider, hold the send for a person's approval, then watch the record write itself. Browser-only; nothing real is sent.
Open the demoWhat Mailway stores
stays on European soil
EU data residency
Your mail is received, routed, and archived inside the European Union, all in Germany: the servers in Falkenstein, the archived messages in Frankfurt (AWS S3). Not an optional EU region: the only one.
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.
one EU region today, with additional regions on the roadmap as we grow
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.