SMTP relay
The relay accepts standard SMTP/ESMTP, authenticates your per-project credential, and routes the message through your attached providers. If you just want to send your first mail, start with the quickstart — this page is the full reference.
Connection
Section titled “Connection”Host: smtp.mailway.net
| Port | Protocol | Notes |
|---|---|---|
| 587 | SMTP + STARTTLS | The standard submission port — use this if you can. |
| 465 | SMTPS (implicit TLS) | Legacy secure SMTP. |
| 25 | SMTP + STARTTLS | Standard relay port. |
| 2525, 2587, 588 | SMTP + STARTTLS | Alternates for clouds that block the standard ports. |
| 2465 | SMTPS (implicit TLS) | Alternate for 465. |
Seven ports because outbound SMTP is blocked more often than people think: GCP blocks port 25 permanently, DigitalOcean blocks 25, 465 and 587, AWS blocks 25 by default, and plenty of corporate networks filter the rest. Whatever your platform allows out, one of these gets through — same host, same credentials.
Authentication
Section titled “Authentication”- Mechanisms:
PLAINandLOGIN. - TLS first, always. The server refuses
AUTHon a plaintext connection — negotiate STARTTLS on the submission ports, or connect with implicit TLS on 465/2465. - Credentials are per-project (concepts): a credential sends through its own project’s providers and nothing else.
- What the pair looks like: the username is
mw_user_+ the credential’s ID core (e.g.mw_user_01k8w9qz3f7m2xv5tj6b4n8d) — the same identifier the console shows for the row, so logs and support tickets line up. The password ismw_pass_+ 40 random characters and is the only secret of the pair — if a string startingmw_pass_,mw_live_ormw_test_ever lands in a repository, revoke it. AUTHrejected, or the connection won’t open? The usual causes — authenticating before STARTTLS (538), a blocked port, or a transient throttle (454) — are mapped to fixes in troubleshooting.
What happens to your message
Section titled “What happens to your message”Mailway’s core promise is byte-for-byte fidelity: the message your app hands over is the message the provider relays. Concretely:
- No tracking pixels, no link rewriting, no footer injection. Ever. Open/click tracking mutates your message and breaks DKIM alignment; Mailway doesn’t do it.
- The message is parsed for the console (search, preview, analytics) and archived verbatim — the parsing never feeds back into what’s sent.
- Your DKIM signature, if you sign before handing off, survives intact.
One other case can change what a provider receives, and it is opt-in, per project, off by default: some API providers can’t accept a raw message, so relaying through them means re-encoding — which an admin must explicitly enable, accepting that the delivered copy may not be 100% identical to the original. Relayed mail skips those providers otherwise. Which APIs carry raw bytes, which can’t, and exactly what re-encoding does: SMTP mail through API providers.
Failover, from SMTP’s point of view
Section titled “Failover, from SMTP’s point of view”Your app gets its 250 OK when Mailway accepts and stores the message —
then routing happens asynchronously. If the first provider rejects or
times out, Mailway retries through the project’s provider chain; your app
never sees provider hiccups, and the console shows every attempt. One
ordering is specific to relayed mail: providers attached over SMTP are
tried before providers attached over an API, whatever the project’s
routing strategy — byte-fidelity
outranks strategy preference.
Testing
Section titled “Testing”For staging and CI, point the same SMTP config at smtp.mailway.dev
with your normal project credential — the same relay, a different
hostname. Messages are accepted, stored, and fully visible in the console,
but never forwarded to a provider: nothing reaches a real recipient
unless you explicitly
release a capture.
See Sandbox for the capture-and-release flow, or the
Send API sandbox if you’re testing over HTTP.