SMTP relay: what it is, when you need one, and how to set one up

An SMTP relay is a mail server that accepts a message from a client and sends it on to another server. RFC 5321, the standard that defines SMTP, describes a relay as a system that receives mail from an SMTP client and transmits it to another SMTP server without changing the message beyond adding trace information. In everyday use the word means something slightly narrower: the server your application logs in to so that it can hand over mail and forget about it.

Your application could, in principle, look up the recipient’s mail server and deliver to it directly. In practice that fails for reasons that have nothing to do with your code. The address it connects from has no sending reputation, the outbound port is often blocked, nothing signs the message for your domain, and when the receiving server says “try later” there is no queue to try later from. A relay exists to own those problems.

So the shape is always the same. Your software opens one authenticated, encrypted connection to the relay, offers the message, and gets a reply. Everything after that reply — finding the recipient’s server, retrying, signing, recording what happened — is the relay’s job.

The three terms get used interchangeably, and the difference matters when you are choosing what to point an application at.

• An MTA (mail transfer agent) is mail server software: the program that speaks SMTP to other servers, queues mail and retries it. Every relay is built on one. The glossary entry covers the role in more depth.
• A relay is an MTA in a particular role: it accepts mail from clients it trusts and moves it on. Strictly, the port an application logs in to is a submission service, which RFC 6409 puts on port 587 and allows to require a login and to fix up a message before it moves on. Most people call that a relay too, and so does this post.
• An email API is the same job behind an HTTPS endpoint: you POST a message as JSON and get an id back in the response. Email API vs SMTP weighs the two side by side.

An SMTP relay service is a relay someone else runs for you, with a username, a password and a domain you have proved you own. That last part is what separates it from an open relay, which accepts mail from anyone for anyone and is the reason most mail servers refuse to relay at all without a login.

If you are writing the sending code yourself, an HTTP API is usually the better door: the message id comes back in the response and a retry is safe by construction. A relay is for everything that sends mail and cannot be taught to make that call.

• Auth services. Supabase Auth sends sign-up confirmations, magic links and password resets. Its built-in mail is meant for trying things out: it delivers only to addresses on the project’s team and has a small hourly cap. Production needs custom SMTP settings, and those settings are a relay.
• WordPress and other CMSs. WordPress hands mail to PHPMailer, which by default relies on the web server’s own mail setup — usually unauthenticated and from an address no one verified. Contact forms, order notifications and password resets are the mail that goes missing first.
• Framework mailers. Laravel, Rails Action Mailer, Django and Nodemailer all speak SMTP out of the box. Pointing them at a relay is a settings change; replacing them with an API call is a code change.
• Everything else that only knows SMTP. A help desk, an internal tool, a monitoring system, a printer that emails scans. None of these will learn HTTP.

In each case the value is the same: the mail comes from your own domain, signed and accounted for, rather than from whatever server the software happens to run on.

Two ports carry almost all application mail today, and they differ only in when the encryption starts.

RFC 8314 recommends implicit TLS for mail submission and asks clients and servers to support both for a transition period, which is why every serious relay offers both. Pick 465 when the client supports it, and 587 when it does not or when its documentation only describes STARTTLS. Port 25 is for relays talking to each other, and many hosting networks block it outbound.

Most mailers name the setting confusingly. In Nodemailer, secure: true means implicit TLS on 465, and secure: false on 587 lets STARTTLS upgrade the connection. In Django it is EMAIL_USE_SSL versus EMAIL_USE_TLS. Setting the implicit mode on the STARTTLS port, or the other way round, is the most common reason a first connection hangs and then times out.

Moving bytes is the easy part. Whether a message reaches the inbox depends on the work a relay does around the transport, and that is what you are really choosing when you choose one.

• An authenticated domain. The relay should only send From an address on a domain you have verified, and should publish SPF and DKIM for it through records you add once. Receiving servers check those records, and a DMARC policy uses them to decide whether mail claiming to be from you really is. DKIM, SPF and DMARC explained walks through all three.
• A DKIM signature on every message. The relay signs each message with a key whose public half sits in your DNS, so a receiver can prove the message came from your domain and was not changed on the way.
• Bounce handling. When a recipient’s server refuses a message after the relay accepted it, someone has to notice. A bare relay mails a bounce to the return path and leaves the parsing to you; a relay with an API behind it turns the bounce into an event you can read.
• A suppression list. An address that hard-bounced or complained should not be mailed again, and nothing in SMTP remembers that. The relay has to, and has to enforce it on the next send even though your application never heard about the first.

None of this is in the protocol. Two relays that both accept your message on 465 can differ entirely in what happens next, so ask what a relay does after the 250, not only whether it answers one.

Every relay has limits, and a mailer learns them from the replies. These are the ones Rasket’s relay applies, and the reply you get when you go over each one.

Base64 makes an attachment about a third larger, so the files in a message add up to a little under 3 MB. A larger file is better sent as a link in the body. The limits in the SMTP docs include the lockout rule for failed logins.

The text after each code is the API’s own error message, so your mailer’s log says the same thing the dashboard would. The full table has every reply the relay sends.

The procedure is the same whatever is sending. Five settings go into the client, but two things have to exist before they mean anything: a verified domain and a key.

1. Add and verify a sending domain — Add the domain the mail will come from, publish the DNS records Rasket generates for it, and wait for verification to pass. The relay refuses a From address on an unverified domain with 550 5.7.1.
2. Create a key for the relay — Create an API key with sending access, restricted to that domain, and store it as an environment variable. It is the SMTP password, and a leaked one can then send from one domain and do nothing else.
3. Enter the relay settings — Set the host to smtp.rasket.com, the port to 465 with implicit TLS or 587 with STARTTLS, the username to rasket and the password to the key, in the client's SMTP settings.
4. Set the From address — Make the client send from an address on the verified domain. Auth services and CMSs ask for a sender address separately, and some default to one on their own domain.
5. Send a test message and read the reply — Send one message to an address you can read. A 250 2.0.0 reply carries the email's id; a 4xx reply means retry later and a 5xx reply means a setting or the message has to change.
6. Listen for delivery events — The relay never mails a bounce back. Point a webhook at your application, or watch the Emails page, to learn which messages were delivered, bounced or complained about.

These are the settings every client below asks for, in one place:

Host:      smtp.rasket.comPort:      465 (implicit TLS) or 587 (STARTTLS)Alternate: 2465 (implicit TLS) or 2587 (STARTTLS)Username:  rasketPassword:  an API key (rk_…) with sending access

Use 2465 or 2587 only when a network blocks the usual port; they behave the same way. Port 25 is not offered.

Each of these is one short block of configuration. The setup guides in the SMTP docs have the exact code for every one; what follows is what is easy to get wrong in each.

import nodemailer from "nodemailer";
// Port 587: connect in the clear, then upgrade with STARTTLS.const transporter = nodemailer.createTransport({  host: "smtp.rasket.com",  port: 587,  secure: false,  requireTLS: true,  auth: { user: "rasket", pass: process.env.RASKET_API_KEY },});
await transporter.verify(); // logs in and logs out, sends nothing

Send one message to an address you can read and look at the reply your client logged. Success looks like this, and the id in it is the email’s id:

250 2.0.0 Queued as 4ef9a417-02e9-4d39-ad75-9611e0fcc33c

The same message is on the Emails page with the source SMTP, and every later event about it — delivered, bounced, complained — carries that id. Rasket’s relay never mails a bounce back to you: after the 250, what happened to a message is an event, a webhook and a row on that page. Point a webhook at an endpoint if you need your application to hear about it.

If nothing arrives, the reply usually says why. In rough order of how often:

• The connection times out. The port is blocked, or implicit TLS and STARTTLS are crossed. Try the alternate port, then check the TLS setting against the port.
• 535 5.7.8. The username is not rasket, or the key was pasted with a space, revoked, or created without sending access.
• 550 5.7.1. The From address is on a domain that is not verified yet, or the key is restricted to a different domain.
• Accepted, but the recipient never sees it. Look the email up on the Emails page. A recipient on the suppression list is skipped on purpose and shows up as an email.suppressed event rather than a refusal.

Once the first message lands, everything that sends through the relay is an ordinary send: it counts against the same quota and rate limit as the email API, and shows up in the same places. If you later want the message id in your own code rather than in a log, the API is one request away.