# What is SMTP and how does it deliver email?

URL: https://iblockspam.com/blog/what-is-smtp
Last updated: 2026-10-10
Published: 2026-10-10
Topic: Email security basics
Author: iBlockSpam Team

> How SMTP moves email between servers: the EHLO, MAIL FROM, RCPT TO and DATA dialogue, envelope vs header From, relays, retries and what reply codes mean.

## Short answer

SMTP (Simple Mail Transfer Protocol, RFC 5321) is the protocol mail servers use to hand messages to each other. The sending server connects to the recipient domain's MX host, introduces itself with EHLO, names the sender with MAIL FROM and each recipient with RCPT TO, sends the message after DATA, and gets a numeric reply code for every step.

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](https://www.rfc-editor.org/rfc/rfc5321.html), 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](https://www.rfc-editor.org/rfc/rfc6409.html) 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](https://iblockspam.com/blog/what-is-an-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](https://iblockspam.com/blog/smtp-ports-25-587-465).

## What does an SMTP conversation look like?

RFC 5321 includes a sample session in [Appendix D](https://www.rfc-editor.org/rfc/rfc5321.html#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](https://iblockspam.com/blog/starttls-email-encryption-in-transit) 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](https://www.rfc-editor.org/rfc/rfc5598.html), the mail architecture document, gives them separate names:

| Name in RFC 5598 | Where it appears | Who sees it | Used by |
|---|---|---|---|
| `RFC5321.MailFrom` | `MAIL FROM` command (envelope) | Servers; later copied into the Return-Path header | Bounces and SPF |
| `RFC5321.RcptTo` | `RCPT TO` command (envelope) | Servers only | Deciding where to deliver |
| `RFC5322.From` | From: header (content) | The person reading | Display, DMARC alignment |
| `RFC5322.To` | To: header (content) | The person reading | Display only |

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](https://iblockspam.com/blog/spf-vs-dkim-vs-dmarc) guide explains how they fit together, and [what is email spoofing](https://iblockspam.com/blog/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](https://iblockspam.com/blog/how-to-read-email-headers) shows how, and the [Email Header Analyzer](https://iblockspam.com/tools/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](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.2.1) defines four classes:

| First digit | Meaning | What the client does |
|---|---|---|
| 2yz | Positive completion | Carries on. `250 OK` is the common one. |
| 3yz | Positive intermediate | Sends more information. `354` after DATA means "send the message". |
| 4yz | Transient negative completion | Keeps the message and tries again later. |
| 5yz | Permanent negative completion | Stops and returns a bounce to the sender. |

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](https://iblockspam.com/blog/what-is-greylisting) use 4yz. Unknown users and policy rejections use 5yz.

Many servers add an enhanced status code from [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463.html) 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](https://iblockspam.com/smtp-errors/451-4-7-1) for a temporary policy deferral. Look up any code in the [SMTP error code lookup](https://iblockspam.com/tools/smtp-error-codes). For how senders should treat each class, see [hard bounce vs soft bounce](https://iblockspam.com/blog/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](https://www.rfc-editor.org/rfc/rfc5321.html#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](https://iblockspam.com/blog/how-spam-filters-work) covers those checks in order.

## Next steps

- Look up your own domain's receiving servers with the [MX Lookup](https://iblockspam.com/tools/mx-lookup), or run the full [Email Health Check](https://iblockspam.com/tools/email-health-check) to see MX, SPF and DMARC together.
- Keep the [SMTP error code lookup](https://iblockspam.com/tools/smtp-error-codes) 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](https://iblockspam.com/how-it-works).

## Frequently asked questions

### Is SMTP used for receiving email?

SMTP carries mail between servers, so your provider's servers use it to receive mail for your domain. Your mail app doesn't use SMTP to read messages, though. It downloads or syncs them from your mailbox with IMAP, POP or a provider's own protocol. SMTP is only used by the app when it sends.

### What is the difference between SMTP and IMAP?

SMTP moves a message from the sender's side to the recipient's mail server. IMAP lets a mail app read and manage messages already stored in a mailbox. A typical email uses SMTP twice (app to sending server, then server to server) and IMAP or a similar protocol once, when the recipient opens it.

### Does SMTP check who the sender really is?

No. RFC 5321 itself says SMTP mail "inherently cannot be authenticated" at the transport level. Anyone can type any address after MAIL FROM or in the From header. SPF, DKIM and DMARC were added later so receivers can check whether a domain authorized the message.

### Is SMTP encrypted?

Not by default. Plain SMTP sends commands and message text in the clear. The STARTTLS extension (RFC 3207) upgrades a connection to TLS, and most large providers use it between servers. Submission from mail apps should always use TLS, either STARTTLS on port 587 or implicit TLS on port 465.

### What happens if the receiving server is down?

The sending server keeps the message in its queue and tries again later. RFC 5321 says retries should generally wait at least 30 minutes and that the give-up time generally needs to be at least 4 to 5 days. Only after that does the sender get a bounce.

## Sources

- [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html)
- [RFC 5598: Internet Mail Architecture](https://www.rfc-editor.org/rfc/rfc5598.html)
- [RFC 6409: Message Submission for Mail](https://www.rfc-editor.org/rfc/rfc6409.html)
- [RFC 3207: SMTP Service Extension for Secure SMTP over TLS](https://www.rfc-editor.org/rfc/rfc3207.html)
- [RFC 3463: Enhanced Mail System Status Codes](https://www.rfc-editor.org/rfc/rfc3463.html)
- [RFC 8314: Cleartext Considered Obsolete: Use of TLS for Email Submission and Access](https://www.rfc-editor.org/rfc/rfc8314.html)

## Free tools for this guide

- [SMTP Error Code Lookup](https://iblockspam.com/tools/smtp-error-codes): Paste a bounce or type a code like 550 5.7.26: plain-English meaning, likely causes and fixes, with sources.
- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.
- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.

---

Source: iBlockSpam, https://iblockspam.com/blog/what-is-smtp (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt