SMTP relay for outgoing mail: smarthosts explained

An SMTP relay - also called a smarthost - is a mail server that delivers your outgoing mail for you. Instead of your server looking up each recipient's MX and connecting to it on port 25, it hands every outbound message to one fixed host on port 587 or 465, logs in with a username and password, and lets that host do the delivery from addresses that already have a reputation. You need one when your network blocks outbound port 25, when your server's IP has no usable reverse DNS, or when a new IP would otherwise spend weeks in spam folders. You still receive mail directly, still hold your own mailboxes, and still sign with your own DKIM key. The relay is only the last hop.

Setting one up takes a quarter of an hour. Getting authentication right so DMARC still passes takes understanding which domain each check is looking at, and that is most of this post.

What a relay changes and what it does not#

Without a relay, your server is the sending server as far as the world is concerned. The recipient sees your IP connect, checks its blocklist status and reverse DNS, and judges the message on your server's reputation.

With a relay, the recipient sees the relay's IP connect. Blocklist checks, reverse DNS and connection-level reputation now belong to the relay. Everything inside the message - your From: address, your DKIM signature, your content - is still yours, and domain reputation still attaches to your domain.

What stays the same: your users submit to your own server, mailboxes and storage stay on your server, inbound mail arrives at your MX exactly as before, and spam filtering of inbound mail is unaffected. A relay is purely an outbound change.

When you need one#

• Outbound port 25 is blocked. The most common reason by far. Your server cannot connect to anyone's port 25, but it can connect to a relay on 587 or 465. Port 25 and outbound mail blocks explains why that block exists and how to confirm it.
• You cannot set reverse DNS. Large receivers expect the sending IP to have a PTR record that matches forward DNS. If your provider cannot set one for your address, a relay's IPs already have it. Reverse DNS and PTR for mail servers has the detail.
• Your IP is new, shared or tainted. A fresh IP has no reputation; a recycled one may carry someone else's. A relay sends from IPs with a history.
• You send application mail at volume - password resets, receipts, notifications. Dedicated transactional services handle bounces, suppression lists and per-message logs better than a general mail server.
• You want one place to watch delivery. Relay dashboards show per-message delivery, bounces and complaints, which a self-hosted queue does not.

When you do not need one: a server on a network with outbound 25 open, a correct PTR, a clean IP with some history, and low-volume person-to-person mail. Plenty of self-hosters send directly for years.

Choosing a relay#

Relays come in three broad kinds.

For a self-hosted mail server, a transactional service is usually the right choice. They accept mail for any From: on domains you have verified with them, they offer custom envelope domains and DKIM with your own domain, and their free or low tiers comfortably cover a small organisation's outbound volume. Check current pricing yourself - it changes, and it is the kind of number that is wrong in any article older than a few months.

What to check before signing up:

1. Domain verification and DKIM with your domain - so DMARC can align on DKIM.
2. A custom return path or MAIL FROM domain - so SPF can align as well.
3. Bounce and complaint handling - suppression of addresses that hard-bounce, and feedback loops from receivers.
4. Submission on 587 and 465, and ideally 2525, for networks that block the standard ports.
5. Rules about content. Most transactional services forbid purchased lists and some forbid marketing mail on transactional plans. Read the acceptable use policy; accounts are suspended for breaching it.

Authenticating to the relay#

The connection from your server to the relay is an ordinary SMTP submission:

1. Your server connects to the relay's host on port 587 and issues EHLO, then STARTTLS to upgrade the connection - or connects on 465 and starts TLS immediately.
2. Over the encrypted connection it authenticates with AUTH PLAIN or AUTH LOGIN, using a username and password the relay issued. Transactional services usually call these SMTP credentials and keep them separate from your account login; some use a literal username like apikey with the API key as the password.
3. It sends the message with MAIL FROM, RCPT TO and DATA, exactly as it would to any server.

Never authenticate over an unencrypted connection - the password crosses the network in base64, which is encoding, not encryption. Configure the server to require TLS to the relay, not merely to try it.

In Stalwart, a relay is configured in the web admin's outbound settings. Recent versions model it as a route of the Relay type with an address, a port, whether TLS is implicit (true for 465, false for 587 with STARTTLS), and the username and secret to authenticate with; the outbound strategy then chooses that route for remote recipients while local mail is delivered locally. Other servers express the same thing differently. For comparison, Postfix:

relayhost = [smtp.relay.example]:587smtp_sasl_auth_enable = yessmtp_sasl_password_maps = hash:/etc/postfix/sasl_passwdsmtp_sasl_security_options = noanonymoussmtp_tls_security_level = encrypt

The square brackets around the host name tell Postfix not to look up MX records for it - connect to that host directly. The same idea applies everywhere: a relay is a fixed destination, not an MX lookup.

SPF, DKIM and alignment through a relay#

This is where relays go wrong. DMARC passes when SPF or DKIM passes for the domain in the visible `From:` header. A relay changes which IP sends and may change the envelope sender, so each check needs thinking through. The background is in SPF, DKIM and DMARC explained.

DKIM is the reliable one. Your mail server signs each message with your own key (d=example.com) before handing it to the relay. The relay must not modify the signed headers or body, and reputable relays do not. The signature arrives intact, verifies against your public key, and aligns with your From:. Many relays also add their own signature with their domain; that is harmless - one aligned passing signature is enough. If your server does not sign, have the relay sign with your domain instead, using the DKIM records it gives you to publish.

SPF depends on the envelope sender. Two cases:

• The relay keeps your envelope sender (MAIL FROM:<anna@example.com>). Receivers check SPF for example.com against the relay's IP. You must add the relay to your SPF record, typically with the include: value the relay documents - for example include:amazonses.com, include:mailgun.org or include:sendgrid.net.
• The relay rewrites the envelope sender to its own bounce domain, so it can process bounces. SPF is then checked against the relay's domain, passes, and does not align with yours. That is fine if DKIM aligns. Better: configure a custom MAIL FROM or return-path domain such as bounces.example.com, published as the relay instructs, so SPF aligns too.

example.com.  IN  TXT  "v=spf1 mx include:mailgun.org -all"

Keep one SPF record per name and stay within ten DNS lookups; every include: spends at least one. If you used -all before adding the relay, add the include first and send a test, or every relayed message fails SPF in the meantime.

Bounces, limits and the queue#

Some practical behaviour to expect once mail flows through a relay.

• Bounces go to the envelope sender. If the relay rewrites it, the relay receives bounces and usually suppresses those addresses automatically - a later send to a suppressed address is dropped by the relay and never reaches the recipient. Check its suppression list when someone says they never get your mail.
• Sending limits. New relay accounts often start with a daily cap or in a sandbox that only delivers to verified addresses. A server that exceeds the cap gets 4xx deferrals from the relay; your queue holds the mail and retries. Request a higher limit before a planned send, not during it.
• Message size. Relays have a maximum message size, often in the 10 MB to 50 MB range including encoding overhead. Base64 makes attachments about a third larger than the files.
• Your queue is still the first queue. If the relay is unreachable or rejects the login, mail waits in your server's queue. A growing queue with authentication errors means wrong or expired credentials; with timeouts, the relay port is blocked or the relay is down.

Relaying only some mail#

A relay does not have to take everything. Common splits:

• Remote mail through the relay, local mail delivered locally. The default arrangement: messages between accounts on your own domains never leave the server.
• Only certain destinations through the relay. For example, deliver directly to most domains but relay mail to one large provider that throttles your IP. Stalwart's outbound routing chooses a route per recipient with expressions, so this kind of split is possible, though the simple all-remote-mail-through-the-relay rule is easier to reason about.
• Applications through the relay, people direct. If your server sends directly but your application sends receipts at volume, point the application straight at the transactional service and keep the mail server for people. Transactional email from your app covers that side.

Testing the relay#

# Can the server reach the relay at all?$ nc -vz -w 5 smtp.relay.example 587# A full authenticated test from the command line$ swaks --server smtp.relay.example:587 --tls \    --auth LOGIN --auth-user 'relay-user' --auth-password 'relay-secret' \    --from anna@example.com --to you@gmail.com

Then send a real message through your mail server to an outside mailbox you control and read Authentication-Results. You want dkim=pass with header.d=example.com (or header.i=@example.com), dmarc=pass and header.from=example.com. spf=pass is a bonus if you set up a custom return path. The Received: headers will show the relay's servers as the last hop before the recipient - that is expected.

When the test fails, the error usually says which layer is wrong:

• `535 5.7.8` authentication failed - wrong credentials, or credentials for a different region or account. Transactional services often issue SMTP credentials per region; the host name and the credentials must match.
• `530` must issue STARTTLS first - the server tried to log in on 587 before upgrading. Turn on STARTTLS for the relay, or switch to 465 with implicit TLS.
• TLS handshake errors on 465 - the server is speaking STARTTLS to an implicit-TLS port. Flip the TLS mode.
• `554` sender address not verified or "domain not verified" - the relay only accepts From: domains you have verified with it. Finish domain verification in the relay's dashboard.
• `dkim=fail` after relaying - something on the way modified the message. Check the relay is not set to rewrite links or add footers, both of which some services do for click tracking.

Relays on a RE:NODE Mail Server#

The Mail Server line runs Stalwart, and the relay lives in its web admin. If a network on the way refuses your outgoing port 25, you set a relay there and Stalwart hands remote mail to it on 587 or 465, still signing with the DKIM keys it generated for your domain. Inbound mail is separate: support forwards port 25 to your server on request, one mail server per address. Whether a PTR record can be set for your server's address is something to ask support about rather than assume - and if the answer does not suit you, a relay is exactly the tool that makes it not matter for outbound mail. Stalwart mail server setup covers the rest of the configuration.

FAQ#

Is a relay the same as an open relay?

No. An open relay accepts mail from anyone for any destination and is a spam tool; servers found running one are blocklisted quickly. A smarthost only relays for clients that authenticate with credentials it issued.

Will recipients see the relay's name?

Only in the technical Received: headers. The From: address, display name and DKIM signature are yours, and mail clients show your domain. Some relays add a small "via" note in Gmail if DKIM is not signed with your own domain - signing with your domain removes it.

Does a relay fix mail going to spam?

It fixes IP-level problems: blocklisted or new IPs and missing reverse DNS. It does not fix poor content, unwanted mail or a domain with a bad reputation. Why email goes to spam covers the rest.

Should I use port 587 or 465 to reach the relay?

Either. 465 uses TLS from the start; 587 upgrades with STARTTLS. Use whichever the relay documents and set the matching TLS mode in your server. If both are blocked, many relays also accept 2525.

Can I use my Gmail account as a relay?

For one address, sort of: it will rewrite or restrict the From: to that account and has low daily limits. It is not suited to relaying a whole domain's mail from your own server. Use a transactional service instead.