What is SMTP and how does it deliver email?

Every email you send crosses the internet using SMTP, the Simple Mail Transfer Protocol. It's a plain-text conversation between two servers, and once you can read it, bounce messages, header traces and delivery problems start to make sense. This guide walks through that conversation step by step.

What is SMTP?

SMTP is the protocol mail servers use to transfer messages to each other. The current specification is RFC 5321, published in 2008. It defines a client (the side that connects and sends) and a server (the side that listens and receives). The same machine can be both: it receives a message as a server, then passes it on as a client.

SMTP only moves mail. It doesn't store it for reading or show it to users. Your mail app reads messages with IMAP, POP or a provider's own protocol. SMTP is the delivery truck, not the mailbox.

A typical message touches SMTP at two points:

1. Submission. Your mail app hands the message to your provider's outgoing server. RFC 6409 calls this "message submission" and reserves port 587 for it, with authentication required.
2. Relay. Your provider's server looks up the recipient domain's MX record and delivers the message to that host on port 25.

Which port to use for each step is a topic of its own; see SMTP ports 25, 587 and 465.

What does an SMTP conversation look like?

RFC 5321 includes a sample session in Appendix D. Here is a shortened version of the same pattern. S: is the receiving server and C: is the sending client.

S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-8BITMIME
S: 250-SIZE
S: 250 HELP
C: MAIL FROM:<Smith@bar.com>
S: 250 OK
C: RCPT TO:<Jones@foo.com>
S: 250 OK
C: RCPT TO:<Green@foo.com>
S: 550 No such user here
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: (headers and body of the message)
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel

Each line from the client is a command. Each line from the server starts with a three-digit reply code. Here is what each step does.

1. Greeting and EHLO

When the connection opens, the server sends a 220 greeting. The client answers with EHLO and its own host name. The server replies with a list of the extensions it supports, one per line. A modern server usually lists STARTTLS here, which lets the client upgrade the connection to TLS before sending anything sensitive. Older clients use HELO, which doesn't ask for extensions.

2. MAIL FROM

MAIL FROM starts a new mail transaction and gives the return address. RFC 5321 calls this the reverse-path: the address "to which error reports should be directed". It's where bounces go.

3. RCPT TO

RCPT TO names one recipient. The client repeats it for each recipient on that server. The server can accept or refuse each one separately. In the example, Green doesn't exist, so the server replies 550 and the client carries on with the others.

4. DATA

After DATA, the server replies 354 and the client sends the message itself: the headers (From, To, Subject, Date and so on), a blank line, then the body. A line containing a single period ends the message. The server's 250 reply here is the moment of handover. RFC 5321 says that by sending this positive reply, "the receiver takes full responsibility for the message".

5. QUIT

The client says goodbye and the server closes the connection with 221.

What is the difference between the envelope and the header From?

This is the single most useful idea in SMTP, and the source of most spoofing confusion.

RFC 5321 says SMTP transports a "mail object" that contains an envelope and content. The envelope is what the client says in MAIL FROM and RCPT TO. The content is everything sent after DATA, including the headers your mail app displays.

The two don't have to match. RFC 5598, the mail architecture document, gives them separate names:

A newsletter platform might use bounces@mailer.example as the envelope sender while the header says news@yourcompany.com. A BCC recipient appears in RCPT TO but in no header at all. Both are normal.

The same freedom is what lets attackers forge the visible From address. RFC 5321's security section is blunt about it: SMTP mail "inherently cannot be authenticated, or integrity checks provided, at the transport level." That gap is why SPF, DKIM and DMARC exist. SPF checks the envelope domain, DKIM signs the content, and DMARC ties the result to the header From. Our SPF vs DKIM vs DMARC guide explains how they fit together, and what is email spoofing shows the attack side.

What does an SMTP relay do?

A relay is any server that receives a message and passes it on to another SMTP server rather than delivering it to a mailbox. Most messages go through several:

• your provider's submission server,
• an outbound filter or smart host,
• the recipient's inbound gateway or spam filter,
• the recipient's mailbox server.

RFC 5321 requires each server that accepts a message to add a trace record, the Received: header, at the top of the message. It records who handed the message over, who received it and when. "Relayed messages will have multiple time stamp lines," so reading them from the bottom up shows the route. Our guide on how to read email headers shows how, and the Email Header Analyzer lays the hops out for you in the browser.

What is an open relay?

An open relay accepts mail from anyone on the internet and forwards it to anyone else. RFC 5321 notes that hosts "are not required to relay mail at all", and a server can refuse with a 550 reply. A well-run server relays only for authenticated users or known internal networks, because an open relay quickly becomes a tool for spammers. RFC 6409 says a submission server must, by default, reject MAIL from a session that hasn't authenticated, unless it has established authorization another way, such as a protected internal network.

What do SMTP reply codes mean?

Every server reply starts with a three-digit code. The first digit tells the client what to do next. RFC 5321 section 4.2.1 defines four classes:

The rule of thumb in RFC 5321: a reply is 4yz if the same command could succeed later with no change by the sender or receiver. Full mailboxes, rate limits and greylisting use 4yz. Unknown users and policy rejections use 5yz.

Many servers add an enhanced status code from RFC 3463 after the basic code, such as 550 5.1.1. The second part names the subject (1 for addressing, 7 for security or policy) and the third gives the detail. That's why you see 550 5.1.1 for a mailbox that doesn't exist and 451 4.7.1 for a temporary policy deferral. Look up any code in the SMTP error code lookup. For how senders should treat each class, see hard bounce vs soft bounce.

How long does SMTP keep trying?

When delivery fails temporarily, the sending server holds the message in its queue. RFC 5321 section 4.5.4.1 sets the expectations:

• "the retry interval SHOULD be at least 30 minutes", though smarter strategies are encouraged when the client knows the reason for the failure;
• "the give-up time generally needs to be at least 4-5 days".

This is why a temporary outage on the receiving side rarely loses mail. It's also why delays happen: a message refused once may wait half an hour or more before the next attempt. If a server bounces mail it accepted earlier, the bounce goes to the envelope sender, which is how forged senders end up receiving backscatter.

How can you see SMTP in action?

You don't need special tools to start.

1. Find the receiving servers. Look up a domain with an MX lookup. The hosts listed are the SMTP servers that accept its mail.
2. Read a bounce. Open any non-delivery report and find the line with a three-digit code and the server that sent it. It tells you which step of the conversation failed: RCPT TO problems point to the address, DATA problems usually to content or policy.
3. Trace a delivered message. View the full headers of a message, then read the Received: lines from the bottom up. Each one is an SMTP handover.
4. Check the TLS hops. Many Received: lines show whether TLS was used for that hop, for example with ESMTPS. A hop without it was sent in plain text.

Where does SMTP fit with your spam filter?

An inbound filter is an SMTP server that sits in front of your mailbox. Your MX record points senders to it, and it decides during the conversation whether to accept each message. It can refuse a recipient that doesn't exist at RCPT TO, defer an unknown sender with a 4yz code, or reject a message after DATA once it has scored the content. Clean mail is then relayed onward to your mailbox server over SMTP. How spam filters work covers those checks in order.

Next steps

• Look up your own domain's receiving servers with the MX Lookup, or run the full Email Health Check to see MX, SPF and DMARC together.
• Keep the SMTP error code lookup handy for the next bounce you need to read.
• If your devices or apps send mail, confirm they use authenticated submission on the right port (587 or 465).
• To see how an inbound filter sits in the SMTP path, read how iBlockSpam works.