Decisions at the gateway, not in your code.
Match on sender, recipient, subject, headers, or size, then reroute, tag, hold for approval, or block, all from the dashboard.
Routing rules move email decisions out of application code and into the gateway. A rule matches on what the message is (sender, recipient, subject, headers, size, attachments) and acts before delivery: reroute to a specific provider, tag it, copy an address, hold it for a person's approval, or block it outright.
Rules are edited in the dashboard and versioned, so changing the route never means a redeploy. Every match is recorded on the message's timeline (the full filter and action reference), and a held mail waits untouched until someone releases it. That's the approval flow teams use for high-stakes sends like winner notifications.
Route by rule,
not by redeploy
The logic you'd otherwise hardcode into your app: match on sender, recipient, subject, headers, size, or attachments — then reroute, tag, bcc accounting, hold for approval, or block outright. Evaluated per message, before delivery, changed from the dashboard. Some of your cron jobs are about to be unemployed.
Domain-based routing lands on Team, the full engine with approve/reject on Business.
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: the suppression list first, then your rules, which can tag it, hold it, or reroute it before any provider is chosen. Every decision 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 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.