Skip to content

SMTP quickstart

If your application already sends mail over SMTP, switching to Mailway is a configuration change — no code. Your app authenticates against smtp.mailway.net, and Mailway relays each message through the providers you attached to the project, byte-for-byte.

  1. Add your provider and create a project.

    The fastest route is the console’s guided setup at /get-started. It walks you through the provider, the project, the credentials, and the first send.

    To do it by hand: open Providers → New provider and add your provider account (the provider guides cover each one, including verifying your sender domain at the provider). Then open Projects → New project and attach the provider in the project’s Routing section. A project with no attached provider can’t send.

  2. Create an SMTP credential.

    On the project’s page, open the Access section (it reads Connect while the project is still being set up) and choose New SMTP credential. You get a username (mw_user_…, the credential’s own ID) and a password (mw_pass_…, the secret of the pair). Store the password in your secret manager; if you lose it, you can reveal it again from the same Access section.

  3. Point your app at Mailway.

    SMTP_HOST=smtp.mailway.net
    SMTP_PORT=587
    SMTP_USERNAME=mw_user_…
    SMTP_PASSWORD=mw_pass_…
    SMTP_ENCRYPTION=tls # STARTTLS
  4. Send something.

    Trigger any mail your app already sends. No app at hand? Send one from the command line with swaks, using a From address on your sender domain:

    Terminal window
    swaks --server smtp.mailway.net --port 587 --tls \
    --auth-user "$SMTP_USERNAME" --auth-password "$SMTP_PASSWORD" \
    --from billing@yourapp.com --to customer@gmail.com \
    --header "Subject: Invoice #2041" --body "Your invoice #2041 is ready."
  5. Find it in the console.

    Open Mails: the mail is at the top within seconds. Click it to see its timeline: received by Mailway, accepted by the provider, and delivered once the provider’s delivery events are set up. If it doesn’t appear or shows an error, troubleshooting maps the symptom to a fix.

Next: set up delivery events for your provider so mail can reach delivered, add a second provider for failover, or wire webhooks into your app.

Mailway listens on seven SMTP ports, so there is always one your host can reach:

Port Protocol Notes
587 SMTP + STARTTLS Submission, upgraded to TLS before login. The most widely supported.
465 SMTPS (implicit TLS) Submission over TLS from the first byte, the current standard (RFC 8314). Use it if your library supports it.
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.

The alternates matter more than they look: GCP blocks outbound port 25 to external destinations, DigitalOcean blocks outbound 25, 465 and 587, and AWS blocks 25 by default. If your platform can’t reach a standard port, use 2587 (STARTTLS) or 2465 (implicit TLS) with the same credentials.

  • Mechanisms: PLAIN and LOGIN.
  • TLS is required before AUTH — the server refuses authentication on a plaintext connection. Use STARTTLS on the submission ports or implicit TLS on 465/2465.
  • Credentials are per-project. A credential can only send through the project it belongs to, so a leaked credential is contained.

Mailway relays through your provider account, so inbox placement lives where it always did: verify your sender domain at your provider and keep SPF/DKIM/DMARC green on your DNS — see Deliverability for what each record does. If you’re on SES, the setup guide covers the exact records — including wiring real delivery/bounce events back into Mailway.

For staging and CI, use the sandbox: the same SMTP config against smtp.mailway.dev, or the HTTP API against api.mailway.dev with a mw_test_… key. Mail there is captured: stored and visible in the console, but never forwarded automatically. Nothing reaches a provider or a recipient unless you release a capture from the console.