# SMTP Commands and Response Codes (Practical Reference)

Use this SMTP commands and response codes reference to debug authentication, TLS, recipient, and delivery issues in production email workflows.

An SMTP error is easier to diagnose when you know which command failed. This reference follows a message from the opening greeting to server acceptance, with the replies that tell you whether to continue, retry or fix the request.

## Quick answer

SMTP is a command/response protocol:

- client sends commands (`EHLO`, `MAIL FROM`, `RCPT TO`, `DATA`)
- server replies with numeric codes (`220`, `250`, `354`, `550`)
- response classes show whether to continue, retry, or fix configuration

## Minimal SMTP session example

The TLS exchange and credential payload are abbreviated below. This is a reading guide, not a script to paste into a live server.

```text
S: 220 smtp.example.com ESMTP ready
C: EHLO app.example.com
S: 250-smtp.example.com
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
[TLS handshake and certificate verification]
C: EHLO app.example.com
S: 250-smtp.example.com
S: 250 AUTH PLAIN
C: AUTH PLAIN [redacted credential payload]
S: 235 2.7.0 Authentication successful
C: MAIL FROM:<sender@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<test@example.net>
S: 250 2.1.5 OK
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: sender@example.com
C: To: test@example.net
C: Subject: SMTP authentication test
C:
C: Test message
C: .
S: 250 2.0.0 Message accepted
C: QUIT
S: 221 Bye
```

## Core SMTP commands

| Command     | What it does                               | Typical use                      |
| ----------- | ------------------------------------------ | -------------------------------- |
| `EHLO`      | Announces client and requests capabilities | Start modern SMTP session        |
| `HELO`      | Legacy greeting                            | Fallback where ESMTP unsupported |
| `STARTTLS`  | Upgrades connection to TLS                 | Secure transport before auth     |
| `AUTH`      | Authenticates client identity              | Submission through provider      |
| `MAIL FROM` | Sets envelope sender                       | Start transaction                |
| `RCPT TO`   | Adds recipient                             | One call per recipient           |
| `DATA`      | Sends message headers/body                 | Transfer message content         |
| `RSET`      | Clears current transaction state           | Recover from input mistakes      |
| `NOOP`      | Health/keepalive command                   | Connection checks                |
| `QUIT`      | Ends session                               | Clean disconnect                 |

Legacy or restricted commands (`VRFY`, `EXPN`) are commonly disabled for security reasons.

## SMTP HELO vs EHLO

`HELO` introduces an SMTP client. `EHLO` also requests the server's Extended SMTP capabilities, such as `STARTTLS`, `AUTH` and `SIZE`. Modern clients begin with `EHLO`; use `HELO` only when the server rejects the extended greeting and the required security policy still allows the session.

For example, `EHLO app.example.com` identifies the connecting client. It does not select the recipient domain, authenticate the sender or set the visible From address. Those jobs happen later. Use the client's fully qualified hostname, or a valid address literal when it has no suitable hostname.

A `250` reply to `HELO` means the greeting succeeded. It does not show that authentication or sending will succeed. If `AUTH` is missing, check the full `EHLO` response after TLS instead of guessing a login command. See [RFC 5321's greeting rules](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.1.1.1) and the [SMTP authentication walkthrough](/blog/smtp-authentication/).

## SMTP response code reference

### Success (`2xx`)

- `220`: service ready
- `235`: authentication successful
- `250`: requested action completed
- `221`: session closing

### Intermediate (`3xx`)

- `334`: auth challenge
- `354`: start message input

### Temporary failures (`4xx`)

- `421`: service unavailable / connection closing
- `450`: mailbox unavailable (temporary)
- `451`: local processing error
- `452`: insufficient system storage

Temporary failures usually require retry with backoff.

### Permanent failures (`5xx`)

- `500`: syntax error, command unrecognized
- `501`: syntax error in parameters
- `503`: bad sequence of commands
- `530`: authentication required
- `535`: auth credentials rejected
- `550`: mailbox unavailable / policy rejection / relay denied
- `551`: user not local
- `552`: mailbox exceeded storage allocation
- `553`: invalid mailbox syntax
- `554`: transaction rejected

Permanent failures usually require config/policy/address fixes before retry.



### Got a 250? Check the email next

The server accepted your message. Send it to a MailSlurp test inbox to check arrival, content and links, then rerun the test when your SMTP settings change.

[Test real email delivery](/product/email-integration-testing/)



## SMTP command-level troubleshooting workflow

1. Confirm port and TLS mode pairing (`587` + STARTTLS, `465` implicit TLS).
2. Validate capability advertisement after `EHLO`.
3. Validate auth mechanism offered by server (`AUTH` variants).
4. Validate envelope sender/recipient syntax.
5. Inspect response class and exact code to choose retry vs fix.
6. Validate inbox outcomes with receive-side tests.

Useful follow-on guides:

- [SMTP port guide](/blog/which-smtp-port-should-i-use/)
- [SMTP authentication](/blog/smtp-authentication/)
- [STARTTLS vs SSL/TLS](/blog/starttls-ssl-tls/)
- [Fixing SMTP 550 errors](/blog/fixing-smtp-550-errors/)

## Testing checklist before release

- Run command-level checks in [Email Sandbox](/product/email-sandbox/).
- Add delivery assertions in [Email integration testing](/product/email-integration-testing/).
- Observe failure events via [Email Webhooks](/guides/email-webhooks/).
- Run [Email deliverability tests](/testing/email-deliverability-test/) before campaign launches.

SMTP acceptance proves a server accepted the message at one hop. It does not prove the final email is readable, linked correctly, or safe to send after tracking, personalization, and footer logic run.

## FAQ

### What is the most important SMTP command?

`EHLO` is critical because it starts capability negotiation for TLS and auth.

### Does `250` always mean delivery success?

No. It means SMTP acceptance at that hop, not guaranteed inbox placement.

### Should I retry `5xx` responses?

Usually no until root cause is fixed. Retry logic is mainly for `4xx` temporary failures.

## Next steps

- [Everything you need to know about SMTP](/blog/everything-you-need-to-know-about-smtp/)
- [What is an SMTP server?](/guides/what-is-an-smtp-server/)
- [Test SMTP servers with Telnet](/blog/test-smtp-servers-with-telnet/)