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

Host: smtp.mailway.net

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.

Seven ports because outbound SMTP is blocked more often than people think: GCP blocks outbound port 25 to external destinations, DigitalOcean blocks 25, 465, and 587 by default, AWS blocks 25 by default, and plenty of corporate networks filter the rest. On DigitalOcean, a port that answers over IPv4 can still hang over IPv6. Whatever your platform allows out, one of these gets through — same host, same credentials.

Authentication

• 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_01k8w9qz3f7m2xv5tj6b4n8dqr) — 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.

Limits and reply codes

A message can be up to 25 MB in total. A team can have up to 128 SMTP sessions open at once, across all its credentials (16 on the sandbox). One connection carries up to 1,000 mails and stays open for up to 1 hour; after that Mailway answers 421 and your mailer has to open a new connection. A mail can have up to 1,000 recipients; for the rest Mailway answers 452 4.5.3 Too many recipients, and your mailer sends them in another mail. The replies your mailer can see from Mailway’s SMTP relay. Each one also carries an enhanced status code after the number (535 5.7.8 Authentication failed), which mail servers log and libraries report:

Code	Meaning	What to do
250 2.0.0 Received as …, safe with Mailway	Mailway received and stored the message. The text after Received as is the relay’s queue ID for the mail: the connection’s ID, a dot, and the mail’s number on the connection (.0 for the first). It isn’t the mail ID (m.…) the console shows.	Nothing: routing to your providers starts now.
421 4.7.0 / 4.7.1	Too many connections: your team’s sessions (in reply to AUTH), your host’s, the port’s, or the relay’s; or too many new connections or failed authentication attempts from your host. Temporary.	Retry with backoff; reuse one connection for several messages. More
451 4.3.0	Mailway couldn’t take the message right now. Nothing was stored. Temporary.	Retry with backoff. A mail server does this on its own; with an app library (nodemailer, PHPMailer, Symfony Mailer), your app has to retry. More
452 4.7.0 / 4.3.1 / 4.5.3	The daily send limit is reached, the relay is short of disk space, or a mail has more than 1,000 recipients (452 4.5.3). Temporary.	If the text says Daily send limit reached, retry after 00:00 UTC. If it says Insufficient system storage, retry with backoff. More
454 4.7.0	Authentication is briefly unavailable. Temporary; your credential is fine.	Retry with backoff. More
501 5.1.7 / 5.1.3	A sender or recipient address isn’t valid, such as a,b@example.com. Permanent, for that address.	Correct the address. More
530 5.7.0 Authentication required	Your app sent MAIL FROM without authenticating first. Permanent.	Set the SMTP username and password in your mailer, and make sure it uses TLS.
530 5.7.0 This SMTP credential was revoked. …	The credential was revoked while the connection was open. Within a minute of the revoke, Mailway refuses the next mail on that connection. Permanent.	Create a new credential in the project’s Access section and switch your app to it. More
535 5.7.8	The username and password don’t match an active SMTP credential. Permanent.	Check the credential in the project’s Access section. More
538 5.7.11	AUTH was sent before TLS.	Use STARTTLS, or implicit TLS on 465/2465. More
550 5.7.0	A monthly plan limit is spent (message quota or data volume), or the team is a person’s second Free team (the text then starts This is a second Free team). Permanent.	Wait for the month to roll over, add an add-on, or upgrade. Such a team sends once it’s on a paid plan. More
550 5.1.7 Null sender …	The envelope sender is empty (MAIL FROM:<>), as in a bounce or an auto-reply. Mailway hands each mail to your provider from that address, so it needs one. Permanent.	Set MAIL FROM to an address on a domain your provider has verified. More
552 5.3.4	The message is larger than 25 MB. Permanent.	Host large attachments and link them. More
554 5.6.0	The message has no From header field, or contains a NUL byte, or a header line ends in a bare carriage return or starts with a dot. Nothing was stored. Permanent.	Add a From field naming the author; encode binary data as base64; end every header line with CRLF and start it with a field name. More

What happens to your message

Mailway’s core promise is byte-for-byte fidelity: the message your app hands over is the message your provider receives, apart from the four automatic exceptions below. Mailway’s archive keeps the message with the header fixes and line endings below already applied; the other two exceptions happen only on the way to a provider. 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 byte-for-byte — the parsing never feeds back into what’s sent.
• Your DKIM signature, if you sign before handing off and sign the standard way (over CRLF line endings, below), reaches your provider intact, and the archive keeps it as received. Mailway checks it shortly after receiving the mail and keeps the result, because a signature can only be checked while its key is still published. What the provider then does to its own copy varies by provider: Amazon SES replaces Message-ID and Date; Mailtrap, Brevo, Mailjet, and MailerSend add tracking to HTML; MailerSend appends a footer; SMTP2GO’s SMTP delivered it unchanged, your signature passing; see Deliverability.

The four automatic exceptions

A missing Message-ID or Date, and Bcc. Like other submission servers, Mailway completes the header block of the message it receives. A message without a Message-ID gets one, <id@mailway.net> (@mailway.dev on the sandbox), where the id is the queue ID in the 250 … Received as reply. A message without a Date gets the time Mailway received it. A Bcc: or Resent-Bcc: field is removed, so the other recipients don’t see who was copied; the addresses still get the mail, because your app names them in RCPT TO. Added fields go at the end of the header block. Nothing else in it changes, and these fixes don’t touch the body. A DKIM signature survives them unless it signed a Bcc field, or signed a Date or Message-ID field the message didn’t have. A message with no From field is refused with 554 5.6.0 instead of the 250: the author is yours to name. Mailway’s archive keeps the message with these changes.

Bare line feeds and bare carriage returns. SMTP ends every line with a carriage return and a line feed (CRLF), and the email format (RFC 5322) allows the two only as that pair. When a line in your message ends with a line feed alone (a bare line feed), Mailway sends that line to your provider ending in CRLF, the way Postfix handles it by default. A carriage return without a line feed after it (a bare carriage return) is sent as CRLF too. Amazon SES makes the same change when it delivers a mail (tested in 2026 Q4). The conversion touches nothing but line endings. The DKIM standard has a signer convert both to CRLF before signing, so a signature made the standard way survives the conversion; one computed over the bare characters themselves doesn’t. After the conversion, neither a bare line feed nor a bare carriage return can end your message early at a provider’s mail server, where the rest could pass as a second, forged message (the attack known as SMTP smuggling). Mailway’s archive keeps the message with CRLF line endings, as it was sent to your provider. Mail received before 12 October 2026 keeps the line endings your app sent.

Above a provider’s recipient cap. Providers cap recipients per message (Amazon SES: 50, counting every To/Cc/Bcc header address). A send above the cap is fanned out BCC-style: the visible recipient headers are collapsed to To: undisclosed-recipients:; and the recipient list is split across envelope chunks under the cap. The body and its DKIM body hash are untouched, and recipients of a 50+ blast no longer see each other’s addresses. Sends at or under the cap are never modified.

Provider instruction headers. A few providers take instructions through headers, and Mailway adds them at the top of the message: Amazon SES’s X-SES-CONFIGURATION-SET, Postmark’s X-PM-Metadata-mw and Mailjet’s X-MJ-CustomID. The provider reads and removes them before delivery, so your recipient never sees them. If your message already has one of these headers, Mailway’s value replaces yours: inside the provider (Mailjet’s message history, say) you’ll see Mailway’s value, not your app’s. Mailway’s archive keeps your original. Details: What Mailway sends the provider.

One other case can change what a provider receives, and it is opt-in, per project, off by default: a provider account that can only send over an API that can’t accept a raw message (one set to Send via: API only, say) can relay only by re-encoding — which an admin must explicitly enable, accepting that the delivered copy may not be 100% identical to the original. Relayed mail skips such an account otherwise. Accounts that can send over SMTP relay over SMTP. 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

Your app gets its 250 (Received as …) when Mailway receives and stores the message — then routing happens asynchronously. If the first provider refuses the send (a rejected key, exhausted credits, a throttle), Mailway retries through the project’s provider chain; your app doesn’t see provider failures, and the console shows every attempt. One ordering is specific to relayed mail: accounts that relay over SMTP are tried first, then accounts that relay over a raw-capable API, and re-encoding accounts last, whatever the project’s routing strategy — byte-fidelity outranks strategy preference.

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. Mail there is captured: 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 HTTP API sandbox if you’re testing over HTTP.