Decisions at the gateway, not in your code.
Rules act on every mail before a provider sees it. Change one in the console, and the next mail follows it.
A rule is one condition and one or more actions. Typical first rules: reject mail to a domain your company retired, tag mail from a staging sender domain so it is easy to filter, or hold a prize-winner notification until someone checks the name. Each one used to be an if in application code, shipped with a deploy.
Rules are versioned, and every match is recorded in the rule's match history. A held mail waits untouched until someone releases or rejects it, and both the hold and the decision appear on the mail's timeline. The rules reference lists every filter and action, with the ones that only apply to API mail marked.
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, and changed from the console without a redeploy.
These change the content, so relayed SMTP mail never gets them: it stays byte-for-byte.
Rules are included on Team and up; holding mail for approval on Business and up.
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.