One email.
The whole journey.
- From
- billing@yourapp.com
- To
- customer@gmail.com
- Subj
- Invoice #2041
- Body
- HTML + text alternative · 140 KB
- Route
- then
:587
shown over SMTP — the HTTPS API (POST /v1/send) takes the same handoff, TLS either way; everything after this step is identical
:587
Stored first, acknowledged second — only then does your app's send() return. If everything after this failed, the message would already exist.
Delivered — and provable.
- It arrived
One provider had a bad moment; the email didn't. Mailway rerouted it mid-send — no code changed, nobody paged.
- It's on file
Saved byte-for-byte before your app even got its OK — and it stays searchable long after provider logs expire.
- Your app knows
A signed webhook reported the confirmed delivery back to your endpoint — the loop closed, on the record.
It runs on its own — but it's yours to steer: pick the route, hold the send for a human, fail the first provider or let it through, choose what reports back. Every fork is a real Mailway behavior, and the wire carries what the machines say meanwhile. A browser-only simulation — the shapes match production.
What happens in the demo, step by step.
1 · The message, and the chain that will carry it
It starts where every transactional email starts: an application has a message ready — here, an invoice — and a provider chain to route it through. You pick the primary and the fallback from real providers (Amazon SES, Mailtrap, Postmark, Mailgun); the order you choose is the order failover will walk later.
2 · The SMTP handoff
The app connects to the Mailway relay exactly as it would to any SMTP server — same protocol, same libraries. The connection is encrypted before credentials cross it, and the message travels the standard path: your mailer already speaks this. Adopting the gateway is the config change you see here, not a migration.
3 · Stored before the 250 OK
This is the ordering that matters most in the whole film: Mailway writes the message durably to the archive first, and only then answers 250 OK. The acknowledgment is a receipt, not a hope — from this moment the mail has an id and a permanent record, whatever the providers do next.
4 · The rules gate
Before any provider sees the message, your routing rules read it. In the demo you make the call a rule would make: tag it for billing, hold it for human approval, or pin it to one provider per policy. A held mail waits untouched until someone releases it — the approval flow used for high-stakes sends.
5 · The provider doors — and the failure
The message walks to the first provider in your chain, and you decide how that provider answers. If it accepts, done. If it times out or rejects, watch the point of the product: Mailway reads the error, classifies it, and re-routes to the next door mid-send. The failure becomes a reroute instead of a missing email.
6 · What flows back
A provider accepting the handoff is not the end of the story. Delivery events — delivered, bounced, complained — flow back asynchronously from providers that report them, land on the message's timeline, and can reach your own app as a signed webhook. Accepted and delivered stay two separate facts, labeled as such.
7 · Delivered — and provable. Or stopped — and honest.
Both endings are wins. Delivered leaves you a timeline, the archived bytes, and the option of a signed proof-of-delivery certificate. Bounced leaves you the truth: the address is suppressed so it never hurts your reputation twice, and the record says exactly what happened. What Mailway never leaves you is a mystery.
The whole run takes about a minute. When you want the real thing instead of the film,the quickstartgets a first send through the relay in ten — andhow it workscovers the architecture the demo is dramatizing.