What is SMTP? Email's sending rail, explained

SMTP (Simple Mail Transfer Protocol) has moved email between servers since 1982, and in all that time it has never once verified that a sender is who they claim to be. Both halves of that sentence matter. The first explains why any two mail systems on earth can talk to each other; the second explains spam, spoofing, and the entire DNS authentication layer bolted on since.

The protocol was written down by Jon Postel as RFC 821 in 1982; the current specification is RFC 5321, from 2008, and a server from either era could still complete a delivery today. SMTP is the sending half of a working email setup. The reading half is IMAP or POP3, and if you are building mail on your own domain end to end, our business email setup guide puts both halves in order. This article stays on the rail that moves the mail.

The conversation, line by line

An SMTP session is plain text over a TCP connection. You could type one by hand into a terminal, and debugging real delivery problems sometimes still means doing exactly that. Here is a minimal delivery, client lines marked C, server lines marked S:

S: 220 mx.example.com ESMTP ready
C: EHLO mail.sender.example
S: 250 mx.example.com greets mail.sender.example
C: MAIL FROM:<news@sender.example>
S: 250 2.1.0 OK
C: RCPT TO:<pat@example.com>
S: 250 2.1.5 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: The Weekly Letter <news@sender.example>
C: To: pat@example.com
C: Subject: Issue 12
C:
C: The body goes here.
C: .
S: 250 2.0.0 OK, queued
C: QUIT
S: 221 Bye

(HELO was the original 1982 greeting; EHLO is its extended replacement and what everything sends today. People still call the whole exchange "the HELO.")

The structural detail worth memorizing is the split between the envelope and the content. MAIL FROM and RCPT TO are the envelope: they are what the receiving server actually uses to route and return the message. The From, To, and Subject lines inside DATA are content, and to SMTP they are just text. Two everyday consequences follow. BCC works because an address can ride on the envelope without appearing anywhere in the headers. And the envelope sender (delivered mail records it as the Return-Path) can be a different address from the From your reader sees. That seam is where bounce handling lives, and it is exactly where email authentication gets bolted on. Hold that thought two sections.

Submission vs relay: 587 vs 25

SMTP does two different jobs on two different ports.

Submission is you handing outgoing mail to your own provider: a mail client with a username and password, or an app with an API key. It is authenticated, always, and it belongs on 587 (formalized for this job by RFC 6409) or 465 (implicit TLS, re-standardized by RFC 8314 in 2018). Use whichever your provider documents; both are fine.

Relay is servers delivering to each other on port 25, and no login exists there. Gmail's MX servers accept mail addressed to Gmail users from any machine on the internet; what varies is how the mail is judged, and the judging is done on the sending IP's and domain's reputation rather than on credentials. This is also why you cannot send mail straight from your laptop: most residential ISPs block outbound port 25 so that infected home machines cannot spray spam, and mailbox providers would distrust a residential IP anyway.

What an SMTP relay service is, and when you need one

An SMTP relay service (Amazon SES, SendGrid, Postmark, Mailgun, Resend) accepts your mail on the submission side, over authenticated SMTP or an HTTP API, and does the port-25 delivery from its own infrastructure: IP addresses with years of accumulated reputation, correct reverse DNS, TLS, bounce processing, and complaint feedback plumbing.

You need one whenever software is the sender. App notifications, receipts, newsletters, and anything else automated all qualify. A human in a mail client already has a relay in effect, because the provider's submission server is one.

The alternative, running your own mail server on port 25, is more workable than vendors admit and worth less than self-hosters hope. The software is a solved problem: Postfix installs in an afternoon. The IP reputation is not. Mailbox providers treat an unknown sending IP as guilty until proven consistent, proving that takes weeks of steady volume, and low volume can never finish the job. We made this exact call for our own workspace and send through a relay; our position is that below tens of thousands of emails a month, self-hosting the sending rail buys you deliverability risk and nothing else. Our send path also enforces a warm-up throttle on top of the relay: roughly 150 sends on day one, raised by about 1.4x daily toward about 1,100 by day seven, capped at whatever the relay allows, which for us is 95 a day. That is Resend's documented domain ramp, and we codified it into the send path so nobody can skip it on launch day. The rest of that policy lives in our email deliverability handbook.

SMTP verifies nothing: why SPF exists

Look back at the transcript. Nothing checked whether the client was allowed to say MAIL FROM:<news@sender.example>. Any connected machine can claim any envelope sender, and in 1982, among a few hundred cooperating research hosts, that was a reasonable design. On the open internet it is an open door, and spam and spoofing walked through it.

Authentication was retrofitted next to the protocol, in DNS, rather than inside it:

• SPF (RFC 7208, published April 2014) lets a domain publish the list of IP addresses allowed to use it in MAIL FROM. Note the envelope-content split from earlier: SPF checks the envelope sender, not the From header.
• DKIM signs the message with a key published in DNS, so altered or forged content fails verification.
• DMARC ties both checks to the From header the reader actually sees and tells receivers what to do on failure.

We explain how the three interlock in SPF, DKIM and DMARC, and the SPF record syntax gets its own walkthrough. What you should carry out of this article is the deadline: Gmail (November 2025) and Microsoft (May 2025) now hard-reject unauthenticated mail with a 550 instead of quietly spam-foldering it. Authentication stopped being extra credit.

One first-hand number on what breakage looks like. Forwarding re-sends a message from the forwarder's IP, which is not in the original domain's SPF record. In June 2026 we measured Gmail rejecting about 73% of the mail we were mirroring into a Gmail mailbox via Cloudflare's forwarding, and it happened silently: no bounce reached anyone, the mail just never arrived. We replaced forwarding with an API insert the same week. If forwarded mail is vanishing somewhere in your setup, broken authentication on the forwarding hop is the first suspect, and why emails go to spam has the fuller diagnostic list.

Reading SMTP errors: 550, 421, 535

Every server reply starts with a three-digit code, and the first digit does most of the work: 2xx means done, 3xx means continue, 4xx means temporary failure (retry later), 5xx means permanent failure (stop and fix something). Modern servers append an enhanced code, like 5.7.26, plus human-readable text, and the text is usually worth reading.

The bounce-handling rule that falls out of this table: a 5xx on a recipient is a hard bounce, and that address should never be tried again. Our own send path suppresses hard bounces permanently and retries soft (4xx) bounces about three times over 14 days before giving up; the distinction matters enough that hard bounce vs soft bounce gets its own article.

You will probably never type MAIL FROM by hand outside a debugging session, and that is fine. The layer is still worth knowing, because every delivery problem you will ever have is legible from here. When something bounces, read the three-digit code first: 4xx says wait, 5xx says fix. And before real volume leaves your domain, publish SPF, sign with DKIM, and set a DMARC policy, because since November 2025 the alternative is a mailbox full of 550s.