What is SMTP? How email actually gets delivered

What SMTP is, and what it does#

SMTP, the Simple Mail Transfer Protocol, is how email moves across the internet. Its current specification, RFC 5321, describes it as “the basic protocol for Internet electronic mail transport”.^[1] It replaced RFC 2821, which had replaced RFC 821, published in August 1982 — so the conversation your mail takes part in today is one that servers were already having more than four decades ago.

SMTP does one job: it carries a message from one computer to the next, until it reaches the server that holds the recipient’s mailbox. It does not decide what an email looks like — that is RFC 5322, the message format, with its From, To and Subject header fields^[2] — and it does not let a person read their mail, which is the job of IMAP and POP3. If email were the post, SMTP would be the vans between sorting offices, not the letter and not the letterbox.

The other thing to know at the start is what SMTP leaves out. The specification is unusually frank about it: “SMTP mail is inherently insecure”, because it is “feasible for even fairly casual users to negotiate directly with receiving and relaying SMTP servers and create messages that will trick a naive recipient into believing that they came from somewhere else.”^[1] Almost everything else in modern email — encryption, sender authentication, the bulk-sender rules — is built on top of SMTP to fill that gap.

The SMTP conversation: EHLO, MAIL FROM, RCPT TO, DATA#

An SMTP session is a conversation of short text commands from the client (the server sending the mail) and numbered replies from the server (the one receiving it). In the basic protocol the client sends a command, waits for the reply, and decides what to do next from the reply’s code.^[1]

1. 1

   Connect and wait for the greeting

   The client opens a TCP connection to the server — port 25 between servers, 587 or 465 to submit new mail — and waits. The server speaks first, with a 220 reply that names it.

2. 2

   Introduce yourself with EHLO

   The client sends EHLO followed by its own domain name. The server answers 250 and lists the extensions it supports, one per line, such as SIZE, STARTTLS and AUTH.

3. 3

   Upgrade to TLS, then log in if submitting

   If the server offers STARTTLS, the client sends it, completes a TLS handshake and sends EHLO again over the encrypted connection. On a submission port the client then authenticates with AUTH.

4. 4

   Name the sender with MAIL FROM

   MAIL FROM carries the envelope sender, the address that bounces and delivery reports go back to. It can differ from the From line the reader sees. The server answers 250 if it accepts it.

5. 5

   Name each recipient with RCPT TO

   The client sends one RCPT TO per recipient, and the server accepts or refuses each one on its own, so one bad address does not stop the rest of the message.

6. 6

   Send the message after DATA

   The client sends DATA, the server answers 354, and the client sends the headers and the body, ending with a line that holds only a full stop. A 250 reply means the server has taken responsibility for the message.

7. 7

   Close with QUIT

   The client sends QUIT and the server answers 221 and closes the connection. A client with more mail for the same server can start another transaction with MAIL FROM instead.

Written out, the same exchange looks like this — C is the client, S the server:

S: 220 mx.example.net ESMTP ready
C: EHLO mail.example.com
S: 250-mx.example.net
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250 STARTTLS
C: MAIL FROM:<bounces@example.com>
S: 250 OK
C: RCPT TO:<ana@example.net>
S: 250 OK
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: From: Example Shop <orders@example.com>
C: To: ana@example.net
C: Subject: Your order has shipped
C:
C: Your parcel is on its way.
C: .
S: 250 OK: queued as 7A1F3
C: QUIT
S: 221 mx.example.net closing connection

A few details in that transcript carry more weight than they look. EHLO superseded the original HELO — servers must still accept both — and the difference is the list it gets back: the server answers with the extensions it supports, which is how a client learns whether it can encrypt, authenticate or send 8-bit text.^[1] Recipients are accepted one by one, so one mistyped address is refused without stopping the rest; a client sending to many people must be ready to send them in groups of a hundred if the server will not take more in one message.^[1] And the message ends at a line containing only a full stop, which is why a line in the body that starts with a dot is sent with a second dot in front of it.^[1]

The envelope and the message are different things#

SMTP carries what RFC 5321 calls a mail object, which “contains an envelope and content”. The envelope is the MAIL FROM and RCPT TO commands: an originator address “to which error reports should be directed” and one or more recipients. The content is everything after DATA — the header section and the body.^[1]

The two are not required to agree. The From: line a reader sees is part of the content, defined by RFC 5322;^[2] the envelope sender is often a separate bounce address at the sending service, and the envelope recipients decide where the message actually goes, whatever the To: line says. That is how a blind copy works, and also how a forged From address gets through: nothing in SMTP checks the content against the envelope.

Keeping the two apart explains most of the authentication puzzle later in this guide, and why a custom bounce address on your own domain matters — the post custom return path, explained goes through it.

SMTP ports: 25, 465 and 587#

Three port numbers come up whenever SMTP is configured, and they are not interchangeable. They separate two jobs that share one protocol: relay, which is servers passing mail to one another, and submission, which is a person’s app or your application handing a new message to its own outgoing server.

Port 25: relay and delivery#

A server receiving mail for its domain listens on “the SMTP port (specified by IANA as port 25)”.^[1] It has to be 25, because the MX records that tell a sender where to deliver have no way to name a port.^[4] Port 25 is also where spam from infected home computers would go, so some network providers block outbound port 25 for everything except their own mail servers.^[5] If an app on a laptop or a cloud machine cannot connect out on port 25, that is usually why — and it is a sign the app should be submitting, not relaying.

Port 587: submission#

RFC 6409 reserves port 587 “for email message submission”,^[3] and says a submission server must by default refuse a message from a session that has not authenticated.^[3] The operating best practice for submission goes further: servers “MUST listen on port 587 by default”, must require a login on it, and must never relay unauthenticated mail to other domains — “they must not be open relays”.^[5] On 587 the connection starts in plain text and is upgraded with STARTTLS before the login.

Port 465: submission over implicit TLS#

Port 465 has a confusing history. It was briefly registered as “smtps”, the registration was revoked, and for years the port was used for TLS submission without an official blessing. RFC 8314 settled it in 2018 by registering 465 as “submissions”: message submission where “a TLS handshake begins immediately” after the connection opens.^[4] The same document recommends implicit TLS in preference to STARTTLS for submission, and asks clients and servers to support both 587 and 465 during a transition of several years.^[4] If a tutorial tells you 465 is deprecated, it predates 2018.

STARTTLS and encryption in transit#

SMTP itself sends everything in the clear. STARTTLS, defined in RFC 3207, is an extension a server advertises in its EHLO reply; the client sends STARTTLS, both sides negotiate TLS, and the conversation starts again — from EHLO — over the encrypted connection.^[6]

Between servers on port 25, STARTTLS is opportunistic: used if both sides support it, skipped if not. RFC 3207 names the weakness itself — an attacker who can delete the “250 STARTTLS” line from the server’s reply makes the client believe encryption is unavailable.^[6] MTA-STS, RFC 8461, closes that gap: a receiving domain publishes a policy over DNS and HTTPS saying its servers support TLS. When the policy’s mode is enforce, a sending server that honours it must not deliver to a host that does not support STARTTLS or fails certificate validation; in testing mode it only reports the failure and delivers anyway.^[7] The glossary entry on MTA-STS covers the records.

Submission, relay and delivery#

A message usually crosses several SMTP hops on its way, and the standards give each kind its own rules. RFC 6409 exists precisely to split “message submission from message relay, allowing each service to operate according to its own rules”.^[3]

1. Submission. Your email app, or your application’s code, connects to its outgoing server on 587 or 465, logs in, and hands over a new message. The submission server may fix up the message — completing a domain name, adding a missing Date or Message-ID — because it is the first server to see it.^[3]
2. Relay. The outgoing server looks up the MX records for each recipient’s domain and connects to the receiving server on port 25. There may be more hops inside either organisation, each one another SMTP transaction.^[1] The MX record glossary entry explains how the lookup works.
3. Delivery. The server holding the recipient’s mailbox accepts the message, runs its filters, and files it — inbox, spam or a tab.
4. Retrieval. The recipient’s app collects the message with IMAP, on port 143 or 993,^[12] or the older POP3 on port 110,^[13] with 995 as POP3’s TLS port.^[4] None of this is SMTP: SMTP only pushes mail toward a mailbox, it never fetches from one.

The handover in the middle is a transfer of responsibility. When the receiving server answers 250 after the message, RFC 5321 says it accepts responsibility for delivering it, retrying it, or sending a failure notice back to the envelope sender.^[1] From then on, the sending server is done with it.

SMTP reply codes: what 2xx, 4xx and 5xx mean#

Every SMTP reply starts with three digits, and the first one tells the client what to do next.^[1] Most of what you will see in delivery logs and bounce messages comes from this single digit.

RFC 5321’s rule of thumb for telling the two failure classes apart: a reply is 4xx if the same command could succeed later “without any change in command form or in properties of the sender or receiver”. A 5xx means repeating the request unchanged will fail again.^[1]

421, 450 and 550#

• 421 — service not available, closing transmission channel. The server is shutting down, overloaded or limiting your connections, and hangs up.^[1] It is temporary: the sending server reconnects later.
• 450 — mailbox unavailable, for now. RFC 5321 gives “mailbox busy or temporarily blocked for policy reasons” as examples.^[1] A common practice called greylisting uses 4xx replies on purpose, refusing mail from an unfamiliar sender once on the reasoning that real servers retry and many spam tools do not.
• 550 — mailbox unavailable, permanently. The examples are “mailbox not found, no access, or command rejected for policy reasons”.^[1] In practice that is a mistyped or deleted address, or a receiver that has decided not to take your mail — which the text after the code usually says.

After the three digits, many servers add an enhanced status code from RFC 3463, written as class, subject and detail: 5.1.1 is a bad destination mailbox, x.2.2 a full mailbox and 5.7.1 delivery not authorised.^[8] The enhanced code is usually more precise than the three-digit reply, so read both. How these replies turn into hard and soft bounces is in hard bounce vs soft bounce.

How long a server keeps retrying#

A 4xx reply does not lose the message: the sending server keeps it in a queue and tries again. RFC 5321 gives the shape of that schedule.

Where SPF, DKIM and DMARC sit#

Because SMTP does not check who is sending, three standards check it from outside the protocol, each looking at a different part of what the conversation carries. The post DKIM, SPF and DMARC explained covers the records themselves; here is where each one plugs into SMTP.

• SPF checks the envelope. The receiving server takes the domain from MAIL FROM (or from EHLO) and asks that domain’s DNS whether the connecting IP address is allowed to use it.^[9] It runs during the conversation, before the message arrives.
• DKIM checks the content. The sending side adds a DKIM-Signature header, signed with a key whose public half is published in DNS under the signing domain, and the receiver verifies it once the message has arrived after DATA.^[10] Because it travels inside the message, it survives forwarding as long as nobody changes the signed parts on the way. SPF usually fails when a third party forwards the message, because the forwarder’s IP address is not in your record; a mailing list that edits the subject or adds a footer breaks DKIM too.
• DMARC ties the two to what the reader sees. It passes only when SPF or DKIM passes for a domain that aligns with the domain in the From: header, and it lets that domain’s owner ask receivers to quarantine or reject mail that fails.^[11] Moving that policy to enforcement is the subject of DMARC p=reject: how to move from p=none.

A receiver that does not like the result can say so with an SMTP reply — a 550 with a 5.7.x enhanced code is the usual shape of an authentication refusal — or accept the message and file it as spam. The guide why are my emails going to spam? picks up from there.

Where SMTP relays and HTTP email APIs fit#

Very little application mail is delivered by a server the application runs itself. The usual pattern is to hand the message to a sending service, which does the relay and delivery steps above for you: it keeps the queue, retries the 4xx replies, turns 5xx replies into bounces, signs with DKIM and manages the reputation of the IP addresses it sends from. That is operating practice, not something a standard requires. There are two ways to hand a message over.

• An SMTP relay, sometimes called a smarthost: your application, mail server or device submits over 587 or 465 with a username and password, exactly as an email app would. It suits software that already speaks SMTP — a CMS, a printer, a monitoring tool — because nothing changes except the server name and the login. The relay must only accept mail from senders it has authenticated.^[5] Setting one up step by step is covered in SMTP relay: what it is and how to set one up.
• An HTTP email API: your code sends the message as JSON over HTTPS and gets back an ordinary HTTP status and an ID. There is no connection to hold open and no multi-step conversation, and results come back later as events or webhooks.

Either way the last hop is the same: the service’s servers speak SMTP on port 25 to each recipient’s MX, and every delivery or bounce you later see is an SMTP reply code that came back from that conversation. Which handover to choose is mostly a question of what your software can already do; the post email API vs SMTP weighs the trade-offs.

Myths about SMTP#

• “A 250 reply means the message reached the inbox.” It means the receiving server accepted responsibility for the message.^[1] Filtering happens after that, so an accepted message can still land in spam.
• “Port 465 is deprecated.” It was, informally, for years. Since RFC 8314 it is the registered, preferred port for submission over TLS.^[4]
• “SMTP checks who the sender is.” The protocol checks nothing; the specification calls SMTP mail “inherently insecure”.^[1] SPF, DKIM and DMARC exist because of that.
• “A 4xx error means the email bounced.” A 4xx is temporary, and the sending server retries on its own.^[1] Only a 5xx, or retries that run out, ends in a bounce.
• “STARTTLS means my email is encrypted end to end.” It encrypts one hop at a time, and between servers it can be stripped unless the receiving domain enforces it with MTA-STS.^[6][7]
• “SMTP is outdated and being replaced.” Every message between mail domains still crosses the internet over SMTP. What has changed is the layers on top — TLS, authentication and policy — and how applications hand mail over.