Visual RFC.
ALL RFCs / RFC 5321
Read the RFC ↗

RFC 5321 / START HERE

SMTP, before the details

SMTP: Simple Mail Transfer Protocol

SMTP moves email from a sending system toward a receiving mail server. It handles the delivery conversation, rather than how your inbox displays the message.

The idea in one picture

  1. A sender submits mail

  2. Mail servers relay it

  3. The receiving server accepts it

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

Mail systems run by different organizations need a common way to accept, relay, and report problems delivering messages.

A familiar example

An email sent to a colleague travels from your mail provider to the server responsible for the colleague's address.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Envelope vs messageSMTP transports an envelope and message content. Visible To and From headers do not define the transport envelope.
  2. DNS & the next hopA recipient domain leads to DNS mail exchangers, then usable host addresses for a delivery attempt.
  3. Greeting & extensionsThe server greets the client. EHLO establishes the client identity and discovers optional capabilities.
  4. MAIL, RCPT, DATAA transaction sets one reverse-path, one or more recipients, then transfers the message content.
  5. Lines & dot transparencySMTP uses CRLF line endings and a single-dot line to mark the end of DATA. Dot-stuffing preserves literal leading dots.
  6. Replies & later changesReply classes tell the client whether to proceed, send more information, retry later, or treat an attempt as permanently rejected.
  7. Relays, aliases & tracesMail can pass through relays, gateways, aliases, and mailing lists before final delivery.
  8. Queues, retries & timeoutsA sender keeps undelivered mail with its envelope, delays retries, and uses stage-specific timeouts.
  9. Acceptance & failure reportsA positive completion after DATA means the receiver accepts responsibility to deliver, relay, or report a later failure.
  10. Security & scopeBase SMTP does not prove the author named in a header. Transport protections, relay policy, and message authentication solve different problems.
Start with chapter one →

This introduction explains RFC 5321 (2008). Read the original RFC ↗