SMTP relay: what it is and how to set one up

An SMTP relay is a mail server that accepts a message from your application and forwards it on to the recipient's mail server on your behalf. It authenticates the sender, applies the sending domain's reputation and authentication records, and hands the message to the destination over the public internet. That relaying step is what separates sending mail at scale from running your own mail server, and it is the piece a transactional email provider replaces.

What an SMTP relay actually does

SMTP (Simple Mail Transfer Protocol) is the protocol mail servers use to pass messages to each other. A relay is a server that speaks SMTP on both sides: it accepts a message from an authenticated sender, then opens its own SMTP connection to the recipient's mail server and delivers the message there. The application never talks to the recipient's server directly.

The reason to route mail through a relay instead of connecting to each recipient server directly is reputation and reach. Inbox providers judge mail by the IP and domain it came from, and a relay run by a sending provider maintains warmed IPs, published authentication records, and feedback loops with the major mailbox providers. A message sent from a random server IP with no sending history usually lands in spam or is refused outright.

Relay vs. a mailbox SMTP server

A single machine can run SMTP for two different purposes, and the confusion between them is common. A mailbox server receives mail addressed to its own users and stores it; a relay accepts mail from authenticated senders and forwards it elsewhere. The provider you use to read your inbox runs the first kind. The service that sends your app's password resets runs the second.

This is also why a relay does not replace IMAP. IMAP is the protocol a mail client uses to read and manage messages already sitting in a mailbox, so it handles the receiving and storage side. SMTP handles sending. A full email account uses both: SMTP (through a relay) to send, IMAP to read. They cover opposite halves of the same round trip.

How relay authentication works

An open relay that forwards mail from anyone is a spam engine, so every usable relay requires the sender to authenticate. The standard mechanism is SMTP AUTH: after opening the connection, the client presents a username and a secret, and the relay refuses the MAIL FROM command until they check out.

For a managed provider the secret is an API key rather than a mailbox password. Lettr's relay uses the literal word lettr as the username and a Lettr API key (prefixed lttr_) as the password. An API key can be scoped and revoked without touching the rest of the account, which a shared mailbox password cannot.

When authentication fails, the relay returns a 535 reply and rejects the message before it is ever queued:

535 5.7.8 Authentication credentials invalid

The 5.7.8 enhanced status code specifically means the credentials were rejected, distinct from a 530, which means no authentication was attempted at all. A bad API key or the wrong username is the first thing to check when a previously working relay starts refusing mail.

The ports and TLS

A relay listens on a small set of ports, and the choice between them is about how TLS encryption starts, not about the mail itself. Two ports carry almost all modern relay traffic:

• Port 465 (implicit TLS). The connection is encrypted from the first byte. This is the recommended default because there is no unencrypted phase to misconfigure.
• Port 587 (STARTTLS). The connection opens in plaintext, then the client issues a STARTTLS command to upgrade to an encrypted channel before authenticating. It works everywhere but depends on the client actually requesting the upgrade.

Port 25 is the original SMTP port and still carries server-to-server delivery, but most networks and cloud providers block outbound 25 to limit spam, so it is not used for application relay. When a firewall also blocks 465 and 587, providers often expose alternates such as 2465 and 2587 (Lettr) or 2525 (a common industry fallback) that behave identically on a non-standard port.

Setting up a relay, step by step

A relay needs four values: the host, the port, the username, and the secret. Everything below is the complete configuration for the Lettr relay, and the shape is identical for any provider; only the values change.

1. Get the four connection values

Create a free account, verify a sending domain so the relay can apply the domain's authentication records, and generate an API key. The four values then read as follows:

SMTP_HOST=smtp.lettr.com
SMTP_PORT=465            # implicit TLS (587 STARTTLS; 2465/2587 alt)
SMTP_USERNAME=lettr      # always the literal word "lettr"
SMTP_PASSWORD=lttr_your_api_key_here   # your Lettr API key

2. Point your application at the relay

Any SMTP-capable code path uses the same four values. In an application that sends through a library, they go into the transport config. Nodemailer with implicit TLS on 465 looks like this:

import nodemailer from 'nodemailer';

const transport = nodemailer.createTransport({
  host: 'smtp.lettr.com',
  port: 465,
  secure: true, // implicit TLS on 465
  auth: {
    user: 'lettr',
    pass: process.env.LETTR_API_KEY
  }
});

await transport.sendMail({
  from: 'orders@yourapp.com',
  to: 'user@example.com',
  subject: 'Your order shipped',
  html: '<p>Tracking number: 1Z999AA1</p>'
});

For an off-the-shelf system with no code path to edit, the same values go into its SMTP settings screen. A WordPress plugin, a CRM, or a network appliance needs only the host, port, username, and API key, entered once, and it sends through the relay from then on. This is the case a relay exists for, since the sending code cannot be modified.

3. Send a test and read the reply

The relay acknowledges a successful submission with a 250 reply and a queued message ID. Any other reply is worth reading in full before sending real traffic: a 535 means the credentials are wrong, a 5xx on the recipient address means the address was rejected, and a timeout usually means the chosen port is blocked and another (587 or an alternate) should be tried.

When a relay is the right tool

A relay is the correct choice whenever the sending code speaks SMTP and cannot be rewritten. Legacy CRMs, ERP systems, WordPress and other CMS plugins, and appliances that email alerts typically expose an SMTP configuration screen and nothing else. Pointing that screen at a managed relay upgrades the deliverability of the whole system without a single line of new code.

For new application code, the tradeoff is different. A relay moves a message but does not understand it, so server-side templates, idempotency keys, structured metadata, and scheduled sending are not part of the protocol. A REST email API exposes those features because it accepts structured data rather than a finished message. The full SMTP vs. REST API comparison covers when to pick each and how to migrate.

Choosing a provider that offers both keeps a mixed stack unified. A serverless function sends over the API while a legacy plugin sends over the relay, and both flows feed the same analytics and suppression list instead of splitting the sending history in two.

FAQ

Bottom line

A relay is the right choice for any SMTP-speaking system you can point at a host but can't rewrite. Setup is four values (host, encrypted port, username, API key), and deliverability comes from the provider's warmed IPs and the sending domain's own authentication records. For new code that can send structured requests, a REST API adds templates, idempotency, and scheduling that the relay protocol cannot.

For both transports from a single provider (a drop-in SMTP relay and a REST email API), create a free Lettr account and point each part of your stack at the one that fits.