In 1982, your mail server would relay mail for absolute strangers. Not as a bug — as the entire point. RFC 821 described a network where any host accepted a message destined for any other host and passed it along, on trust, no questions asked. That was SMTP. The “relay” in the name wasn’t a feature you switched on; it was what the protocol was.
Try that today and you’ll be on a dozen blocklists before lunch. An open relay — a server that accepts mail from anyone, for anyone — is now a synonym for “compromised.” The single most important thing that happened to SMTP between 1982 and now is that the word “relay” got hollowed out from the inside, and almost nobody noticed, because the word itself never changed.
Let me untangle what “relay” actually means in 2026, because the confusion costs people real debugging hours.
Submission is not relay
Here’s the distinction that resolves half of all “my email won’t send” tickets: submission and relay are two different operations that happen to speak the same protocol.
Submission is your client handing a message to your server — Thunderbird to your provider, a PHP script to SendGrid. You authenticate. The server knows you. It accepts your outbound mail because you proved you’re allowed to send it.
Relay is one server handing a message to another server across an organizational boundary — your provider’s outbound MTA to the recipient domain’s inbound MX. No login. The receiver accepts it not because the sender authenticated, but because the receiver is the final destination for that domain and is willing to take mail addressed to itself.
For the first sixteen years of SMTP, both ran over port 25 and nobody drew a line between them. That was fine right up until spam made it catastrophic. If one socket accepts authenticated submission and anonymous relay, every misconfigured server is a free spam cannon.
So in December 1998, Gellens and Klensin published RFC 2476 and split them apart. Submission moved to port 587. Relay stayed on 25. The rule that emerged — and still holds — is brutally simple: port 25 is servers talking to servers; port 587 (or 465) is humans and apps talking to their own server. If you’re configuring an app to send mail and you reach for port 25, you’re almost certainly doing it wrong. ISPs block outbound 25 from consumer networks precisely because nothing legitimate originates there anymore.
Port 465 has its own little comedy: deprecated in the late ’90s, left in limbo for two decades, then formally resurrected by RFC 8314 in 2018 for implicit-TLS submission. It and 587 do the same job — 465 just encrypts from the first byte instead of upgrading mid-conversation with STARTTLS.
What actually happens when you hit send
Trace one message end to end:
- Submission. Your client opens 587 to your provider, runs STARTTLS, authenticates, sends the message. Your provider’s MTA now owns it.
- The MX lookup. That MTA reads the recipient domain, asks DNS for its MX records, takes the lowest-priority (highest-preference) one, and resolves it to an IP.
- Relay. Your MTA opens port 25 to the recipient’s inbound MX and delivers. This is the only true relay hop in the whole journey.
- Local delivery. The receiving MTA drops the message into the mailbox; IMAP or POP hands it to the reader later.
One submission, one relay, one delivery. The thing people picture — mail bouncing through a chain of intermediate relays like a bucket brigade — basically doesn’t happen anymore for ordinary mail.
You can prove this to yourself. Open any email and read the Received: headers from the bottom up; each server that touched the message stamped one on as it went. In 1995 that stack might be five or six servers deep across three organizations. Today it’s usually two or three lines, and most of them belong to the same provider. The middle of the internet’s mail network quietly emptied out.
Where the relays went
They didn’t vanish so much as consolidate. Store-and-forward — a server holding a message and retrying later if the next hop is down — is still core to SMTP, and still the reason mail survives outages that would kill a synchronous protocol. But the number of independent hands a message passes through collapsed.
Two forces did it. Spam killed the open intermediary: once relaying for strangers got you blocklisted, every server locked down to relay only for its own authenticated users or its own domains. And consolidation finished the job — when a huge share of the world’s mailboxes sit behind a handful of providers, “server to server across an org boundary” increasingly means one giant handing off to another giant. One hop, done.
The trust model inverted
This is the part worth keeping. SMTP started as relay-by-default: trust everyone, forward anything. It is now relay-by-exception: trust no one, accept a message only if you’re the intended destination or its authenticated owner. Same verb, opposite posture.
Everything bolted on since — SPF, DKIM, DMARC, the whole authentication circus — exists to answer a question the original protocol never asked, because in 1982 it didn’t need to: should I be carrying this message at all? The open relay assumed the answer was always yes. Thirty years of abuse taught us it’s almost always no, and we’ve been encoding “no” into DNS records ever since.
So when someone tells you to “set up the SMTP relay,” stop and ask which operation they mean. If they want an app to send mail, that’s submission — authenticate, use 587 or 465, and let the provider make the one real relay hop on your behalf. If they genuinely want a box that relays mail for other servers, ask very carefully who’s allowed to use it. The internet has spent twenty-five years making sure the answer can’t be “everyone.”