Bring your own keys (BYOK)

Mailway is not an email provider — it’s the layer above yours. You add your provider accounts with your own API keys; Mailway routes each send through them and fails over when one misbehaves. You keep the provider relationship, the sending reputation, and the provider’s pricing (which, at SES rates, is usually a fraction of what an all-in-one service charges).

Supported providers

Provider	Transports	Delivery events
Amazon SES	API (raw-capable), SMTP	✔ full setup guide
SendGrid	API, SMTP	—
Mailgun	API (raw-capable), SMTP	—
Postmark	API, SMTP	—
Mailtrap	API, SMTP	✔ full setup guide
Mandrill	API, SMTP	—
Brevo	API, SMTP	—
Gmail / Google Workspace	SMTP	—
Generic SMTP	SMTP	—

Transports: most providers can be attached through their native API or their SMTP endpoint — pick whichever your provider plan supports. The choice matters for mail your apps relay through Mailway’s SMTP endpoint: see SMTP mail through API providers. Delivery events (confirmed delivery, bounces, complaints flowing back into Mailway) are live for Amazon SES and Mailtrap today; other providers report accept/reject at handoff.

Attaching a provider

1. In the console, open Providers and add the provider with its credentials. Providers belong to the team; secrets are encrypted at rest and never leave the console once saved.
2. Open the project that should use it and attach the provider. A project can attach several.
3. Order matters: the attach order anchors the failover chain — which provider gets the first try depends on the project’s routing strategy; on rejection or timeout the send falls through to the next.

Routing strategies

Each project has a strategy deciding which attached provider gets a send (changeable anytime in the project’s settings):

Strategy	Picks
random (the default)	any attached provider, evening out over time
fallback	strictly in attach order — the first provider gets every send, the rest are backup
round-robin	rotates through the chain, send by send
free-first	providers with remaining free tier first, paid volume after

free-first reads the Free tier quota you maintain on each provider (for example Mailtrap’s 4,000/month) and spends it before anything that costs money. A provider whose free tier is exhausted drops behind the rest but remains a failover target — deliverability outranks economy.

Whatever the strategy, a failed attempt falls through to the next attached provider, and a per-send pin overrides the strategy entirely. For mail relayed through the SMTP endpoint one more ordering applies before the strategy — see SMTP mail through API providers.

Before committing to a change, the project page’s routing simulator (Team plans and up) replays your recent traffic through a hypothetical configuration — a different strategy, or with a provider removed (“what if SES were down?”) — using the exact same routing engine the pipeline runs, and shows how first attempts would have split. It projects routing, never outcomes.

Failover, precisely

• A send that fails on one provider retries down the chain — a mail is only failed when every attempt is exhausted.
• Every attempt is recorded: the console shows the full per-attempt chain (provider, duration, response), and mails saved by a retry are counted as rescued on the dashboard — the number that tells you what the chain is worth.
• A hard bounce for a single-recipient send stops retrying immediately — re-sending a permanent reject to another provider would only hurt your reputation.

SMTP mail through API providers

Mail your apps hand to Mailway’s SMTP relay is promised byte-for-byte — so what happens when the failover chain reaches a provider attached through its API? That depends on the API:

• SMTP transports carry the original bytes natively. Nothing to decide.
• Raw-capable APIs — Amazon SES (SendRawEmail) and Mailgun (the MIME endpoint) accept a verbatim message over their API — relay the original bytes byte-for-byte, by default. The fidelity promise holds; no configuration needed.
• Structured-only APIs (SendGrid, Postmark, Brevo, Mandrill, Mailtrap) accept only JSON fields — carrying the original bytes is impossible. Relayed mail skips these providers by default; the project’s routing view says so on the affected hop.

For structured-only providers there is an opt-in. A project admin can enable re-encoding on that provider’s attachment (per project, per provider; the change is audited). Mailway then rebuilds the message from the archived original — headers, HTML and text bodies, attachments including inline images — and sends it as a structured API call. The consequences, stated plainly:

• The delivered message may not be 100% identical to what your app handed over. It is a faithful reconstruction, not the original bytes.
• A DKIM signature your app applied before handing off will not survive the rebuild — the provider signs with its own DKIM instead, as it does for any structured API send.
• The console marks every such attempt re-encoded — on the mail, in the list, and on its per-attempt pipeline view — so a fidelity caveat is never invisible.
• No proof-of-delivery certificate is issued for a re-encoded delivery: Mailway won’t certify byte equality it didn’t preserve.

To audit fidelity across your mail, filter the console with fidelity:re-encoded (or relayed / constructed); troubleshooting covers what to check when a delivery isn’t byte-for-byte.

Mail submitted through Mailway’s own Send API or console never faces any of this — it arrives as structured fields, so every provider variant carries it without a fidelity caveat.

One default worth knowing: independent of the routing strategy, SMTP mail tries SMTP-attached providers first and turns to API-attached ones only after every SMTP one has been attempted — fidelity outranks strategy preference. Explicit per-send pins still override.

Per-send routing

The Send API can pin a message to a specific provider ("routing": { "provider": "amazon-ses-api" }) or an ordered preference list. A pinned provider that isn’t attached to the project fails loudly with 422 routing_provider_not_configured — never a silent reroute. Rules can also route by content: send everything matching invoice through SES, everything else wherever.