What is an SMTP relay?

An SMTP relay is a mail server that accepts a message from your application, authenticates you, and takes responsibility for delivering it to the recipient’s mail server. Your application makes one connection to a machine it trusts, instead of connecting to every recipient’s mail server itself.

It is the oldest way to send mail from software, and for a great deal of existing software it is the only way — anything with an “SMTP settings” screen is expecting a relay.

What it replaces

Delivering mail yourself means, for every message: looking up the recipient domain’s MX records, connecting to a stranger’s server on port 25, negotiating TLS, handling a rejection you have never seen before, queuing and retrying on temporary failures, and being judged on the reputation of whatever IP you happened to send from.

Almost nothing has a reason to do this. A relay does it once, from infrastructure configured for it.

The settings, and what they mean

host:      smtp.provider.example
port:      587
security:  STARTTLS
username:  <credential>
password:  <credential>

Port 587 is the submission port, defined in RFC 6409, for authenticated clients sending mail. Port 25 is for server-to-server transfer and is blocked outbound by most hosting providers and consumer ISPs — if a send hangs and times out, this is usually why.

STARTTLS opens a plaintext connection and upgrades it to TLS before authentication. Port 465 with implicit TLS negotiates TLS first. Both are fine; they are not interchangeable, and selecting the wrong one for the port is the second most common connection failure. Pick the pair your provider documents.

The credentials are not your account password. A relay credential authorises sending and nothing else, which is what makes it safe to put in a config file, and what makes it revocable on its own.

Relay versus API

Most transactional providers offer both. The choice is usually decided by what you already have.

A relay is the right answer for code that already sends mail, for anything with an SMTP settings page, and for platforms you do not control. An API is the right answer for new code, where structured errors and an idempotency key are worth having.

What matters more than the choice is that both paths behave identically — same authentication, same suppression, same event log. When they do not, you end up with two classes of mail in one system and no way to compare them.

Checking a relay before you rely on it

Test the credentials from the machine that will use them, before wiring anything into an application:

swaks --to you@example.com \
      --from noreply@yourapp.com \
      --server smtp.provider.example:587 \
      --auth --tls

That separates four failures a framework will report as one generic error: wrong credentials, a blocked port, the wrong TLS mode, and a rejected sender address. The last one is worth checking specifically — a relay bound to a verified domain may substitute or refuse a From: address on a different domain, and a 250 is not confirmation that the address you intended was the address used.

Pharos runs an SMTP relay and a REST API over one pipeline, with the same signing, the same suppression and the same events. The SMTP relay documentation has the exact settings.