Skip to content

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.

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.

  • Mechanisms: PLAIN and LOGIN.
  • TLS first, always. The server refuses AUTH on 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 is mw_pass_ + 40 random characters and is the only secret of the pair — if a string starting mw_pass_, mw_live_ or mw_test_ ever lands in a repository, revoke it.
  • AUTH rejected, 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.

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.

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.

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.