Your provider bill stays yours.

You plug in your own API keys for email providers like Amazon SES, SendGrid, or Mailgun. Mailway routes emails through your accounts, not ours. You keep full control of your sender reputation, domain configuration, and provider costs, and Mailway has zero conflict of interest on which provider you use.

For SMTP, no. Just update your host, port, and credentials. Works with every language and framework. We also offer an HTTP API with live and sandbox keys for teams that prefer sending via HTTP. Either way, no proprietary SDK required.

Mailway classifies the error. If the provider refused for reasons on its side (a rejected key, exhausted credits, a rate limit, a server error), it retries on the next provider in your chain, five seconds later when it's one the mail hasn't tried (fallback, free-first, and round-robin strategies), otherwise after a widening backoff. If it's permanent (invalid recipient), it stops and records the result, and bounces your provider reports back go on the project's suppression list. Your app doesn't handle any of this.

Mail that Mailway hasn't received yet stays with your app. Without a 250 OK (SMTP) or a 202 (HTTP API) from Mailway, your app gets an error or no answer and can try again; a mail server, or a job queue with retries, does this on its own. Mail that Mailway has received waits in its queue and moves on when the service is back, so an outage delays it. One limit: until Mailway records an SMTP mail, normally within seconds, it is on one machine's disk, and losing that disk would lose it. Mailway runs in one EU region, with no multi-region failover. status.mailway.net shows whether Mailway is up right now. An independent monitoring service runs the checks.

SendGrid and SES are email providers that deliver emails. Mailway is the layer in front of them. You can use SendGrid and SES simultaneously through Mailway, with automatic failover between them. Mailway doesn't deliver mail itself: it keeps an exact copy of every email, records what each provider did with it, and hands a refused mail to the next provider. Whether a mail reaches the inbox still depends on your sender domain and your provider.

Yes. Where your provider reports delivery events (every supported provider except Gmail and Any SMTP server), Mailway ingests them and shows the real outcome of each message, whether delivered, bounced, or complained, not just "accepted". For Gmail and Any SMTP server, Mailway reads no outcomes, so their sends stay "accepted". Hard bounces and complaints auto-populate per-project suppression lists that are checked on every send. Outbound webhooks can notify your own app with signed, retried events.

All SMTP connections use TLS (STARTTLS on port 587, implicit TLS on 465). Payloads are stored with server-side encryption, and all data is hosted in the EU.

Yes. Each project can have multiple providers with one of four routing strategies: fallback (a fixed order), free-first (providers with free allowance left go first), round-robin (each provider in turn), or random (the default). Fallback optimizes for reliability, free-first for cost, round-robin for balance.

Configure multiple providers (for example Mailgun, Mailtrap, and Brevo) with the free-first strategy, and Mailway sends through providers that still have free allowance left before the others. You enter each allowance (prefilled from the provider's published tier), and Mailway counts it approximately, so treat it as a target, not a hard cap. With BYOK you pay each provider directly, and Mailway adds zero per-email cost.

1,000 emails per month (up to 100 a day), 250 MB of monthly throughput, 30-day retention, 1 project with 1 sender domain, and 1 provider, all with the full console, dev sandbox, and API access. You upgrade when you need failover routing, more projects, or longer retention.

30 days on Free, 90 days on Pro, 6 months on Team, 1 year on Business, custom on Enterprise. Multi-year retention add-ons cover SOX (7 years), HIPAA (6 years), and FINRA (3+ years) record-keeping. Provider logs are typically kept for days to weeks.

Keeping the exact message is what Mailway is for, so every project keeps mail content today. A mode that keeps only the delivery record isn't built. What you can rely on: content is kept for your plan's retention window (30 days on Free, 90 days on Pro, 6 months on Team, 1 year on Business, custom on Enterprise), and a nightly job then deletes it from storage. Mail already packed into a monthly archive is deleted with that archive once the newest mail in it is past the window, so it can stay up to about a month longer. The delivery record (sender, recipients, subject, and states) stays for the life of the account. Stored mail content is encrypted at rest and stays in the EU. If a metadata-only mode would change your decision, tell us at hello@mailway.net.

You can, and plenty of teams start there. A BCC copy is what arrived in a mailbox after your provider handled it, not the message your app handed off; it's one more billed recipient on every send; and it says nothing about what happened next: which provider took it, whether it failed over, whether it bounced. A sent-emails table holds what your code meant to send, usually without attachments, and never the provider's answer unless you wire up each provider's webhooks yourself. Mailway keeps the exact message next to its whole timeline, searchable by recipient, sender, subject, and state, and access follows your team's roles and projects instead of whoever can open a shared mailbox.

Point your dev environment at smtp.mailway.dev and emails are captured, held without delivery to any provider. Inspect them in the console, then discard them, or release one for real delivery behind a confirmation. Same credentials, same config, just a different hostname.