Concepts
Five objects explain the whole product, and every other page uses these words. For single terms (BYOK, hard bounce, failover, SMTP relay, and more), see the glossary.
The account boundary — billing, members, and roles live here (the console’s Team section). Everything below belongs to a team, and each person’s role (Admin, Developer, Finance, or Member) decides what they can see and touch.
Project
Section titled “Project”The unit of sending. A project groups one application’s (or environment’s)
mail: its own credentials, its own attached providers, its own suppression
list, its own analytics. Typical setups have one project per app, or per
app-environment (shop-production, shop-staging).
A project also declares the sender domain(s) it mails from — plans cap how many domains a team can send from in total, and per project (limits). Domain authentication (SPF, DKIM, DMARC) stays where it belongs under BYOK: at your provider, on your DNS — see Deliverability for what goes where, and the Amazon SES guide for the concrete records.
Provider
Section titled “Provider”Your provider account — for example Amazon SES, SendGrid, Mailgun, or Postmark — added to Mailway with your API key. Mailway never resells email: every message relays through a provider account you own, on your reputation and your pricing. Providers attach to projects in an ordered list; the project’s routing strategy picks the first try, and failover works down the rest. Failover needs at least two providers on the project (Pro and up).
Credentials & API keys
Section titled “Credentials & API keys”Two ways in, both per-project so a leak is contained:
| Used for | Looks like | |
|---|---|---|
| SMTP credential | The SMTP relay — apps that already speak SMTP | username + password |
| API key | The HTTP API | mw_live_… / mw_test_… bearer token |
Both are created on the project’s page in the console, in its Access section. API keys are shown once and stored only as a hash; an SMTP password can be revealed again from the same section if you lose it.
One message, from ingest to archive. Every mail gets a permanent ID
(m.01k8w9…) that threads through the console, webhook events, share
links, and delivery certificates. In the console, each mail’s page shows its
timeline: every step Mailway and the providers recorded, in order. Its
lifecycle is a ladder of states:
Three of these deserve precision:
- Accepted — a provider took the handoff. Getting here isn’t a given: Mailway tries each provider in your failover chain in order until one accepts, and if every attempt fails the mail ends exhausted: every provider in the chain refused it, and a retry starts the chain over.
- Rejected (API value
failed) — stopped for good before delivery: by a person, a rule, the suppression list, a revoked SMTP credential, or a provider’s permanent refusal of a single-recipient send. The mail’s page says which. Search accepts bothstate:rejectedandstate:failed. - Delivered — the recipient’s mail server confirmed receipt, reported back through provider delivery events. It’s a conditional state: a mail only reaches it once those events are flowing (for Amazon SES, through Amazon SNS; each provider guide shows the setup); until then it rests at accepted. Mailway shows the two separately and never relabels one as the other.
The provider guides’ event tables use one more word: dropped. A dropped event means the provider itself declined to attempt delivery (for example, an address it already knows is bad). Mailway records the event with the mail, but it doesn’t change the mail’s state, fire a webhook, or add the address to the suppression list.
One more state sits outside this ladder: captured. Sandbox mail (the
*.mailway.dev hosts and mw_test_ keys) is held and never handed to a
provider, until you release it for real delivery or discard it
(Sandbox).
The full message — headers, body, attachments — is archived byte-for-byte for your retention window (your plan’s, or a shorter one you set), which is what makes share links and proof-of-delivery certificates possible. When the window closes the content is deleted; the delivery record (sender, recipients, subject, states) is kept for the life of the account.
Cookie consent
We may run ads on Google and Reddit. If we do, knowing whether they work needs your OK for one cookie each from them, used only to tie a signup back to the ad that brought it. Analytics here is cookieless either way, and declining changes nothing else.
Change your mind any time with "Cookie choices" in the footer. Details in the privacy policy.