Skip to content

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.

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.

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).

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:

Mail lifecycleINGESTpendingaccepteddeliveredsoft-bouncedbouncedcomplainedpausedfailedexhaustedfailoverreleasedBEFORE HANDOFFDELIVERY WEBHOOKSprimary pathconditional state

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 both state:rejected and state: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.