Sending email over SMTP

Postwing exposes a standard SMTP relay. Point any SMTP-capable application or library at it — set the host, a port, and your token credentials — and your existing code keeps working, no SDK required. The relay accepts three connection modes: SSL/TLS (implicit), STARTTLS, and plain (no encryption). Pick the port that matches the mode your client uses.

Connection settings

Encryption modes

The same server handles every mode — only the port and the client-side flag differ. If you are unsure, use SSL/TLS on port 465: it is the simplest to configure and encrypted from the first byte.

Credentials

The username and password are the SMTP token for your domain. Generate one on the token management page in the dashboard. For security a token's password is shown only once, at the moment it is created, and is never stored in plain text — copy it immediately and keep it safe.

Where bounces go (return path)

The envelope sender — what our servers put in MAIL FROM, and where a mail server sends a delayed bounce — is your message's own From address by default. That is unusual and deliberate: it means the envelope is entirely yours, SPF is checked against your domain, and it aligns with your From for DMARC. Most providers bounce through a domain of their own.

The catch is noreply@. If you send from an address nobody reads, every bounce that arrives after we handed the message over lands there. Set a return path on the domain and we use that address instead — a mailbox you actually monitor.

It has to be an address at the domain itself, not a subdomain: SPF is checked against the envelope sender's domain, and the SPF record you published is at your apex. A subdomain would be checked at a name with no SPF record, quietly turning passing mail into failing mail.

Nothing about this writes a Return-Path header. That field is written by the mail server that finally delivers your message, from the envelope — a message that arrives carrying one it wrote itself is malformed.

Several recipients

A message addressed to more than one person becomes one message per recipient in our system — To, Cc and Bcc alike. Each gets its own Message-ID, its own delivery webhook and its own place in your plan's allowance, which is what lets a bounce, an open or an unsubscribe be attributed to the person it happened to. Up to 100 recipients per message; the recipient past that is answered 452 4.5.3 Too many recipients, which tells your client to send the rest in a second transaction rather than that the message failed.

We remove the Bcc header at submission, as a submission server is required to (RFC 5321 §7.2). The envelope already carries the blind recipients, so a Bcc that survived would tell every reader who else was on the message. Most mail libraries strip it themselves — which is exactly why the ones that do not go unnoticed, since the leak reaches your readers and never you. Your blind recipients still get their copies; only the header is gone.

Verifying the connection

To confirm sending works you can use the swaks command-line utility. The examples below send the same test message over each mode — replace the addresses and token credentials with your own.

SSL / TLS (port 465)

swaks --to recipient@your-domain.com \
      --from sender@your-domain.com \
      --server smtp.postwing.app:465 \
      --tls-on-connect \
      --auth-user token_login@your-domain.com \
      --auth-password token_password

STARTTLS (port 587)

swaks --to recipient@your-domain.com \
      --from sender@your-domain.com \
      --server smtp.postwing.app:587 \
      --tls \
      --auth-user token_login@your-domain.com \
      --auth-password token_password

Plain, no encryption (port 8025)

swaks --to recipient@your-domain.com \
      --from sender@your-domain.com \
      --server smtp.postwing.app:8025 \
      --auth-user token_login@your-domain.com \
      --auth-password token_password