Stand with Ukraine 🇺🇦 Donate to support

List of All SMTP Commands and Response Codes

On August 14, 2019
9min read
Zakhar Yung Technical Content Writer @Mailtrap

In the blog post SMTP vs. IMAP vs. POP3, we explained that an SMTP session is a sort of a conversation between an SMTP client and an SMTP server. The client talks using commands that consist of alphabetical characters. The server responses with numerical codes. Today, we’ll touch upon this in detail. You’ll find out the valid SMTP commands and the obsolete ones. Also, we’ll shed light on which response codes correspond to each command. 

Essential SMTP commands in the order they may be used

Each SMTP command defines a particular function within the SMTP session, which consists of three steps: 

  • handshake – establishing a TCP connection 
  • email transfer – manipulations with the email
  • termination – closing a TCP connection

Therefore, we decided to list the SMTP commands according to this flow.


The HELO command initiates the SMTP session conversation. The client greets the server and introduces itself. As a rule, HELO is attributed with an argument that specifies the domain name or IP address of the SMTP client.

Example: HELO

EHLO is an alternative to HELO for servers that support the SMTP service extensions (ESMTP). If the server does not support ESMTP, it will reply with an error. 

Example: EHLO

In any case, HELO or EHLO is a MUST command for the SMTP client to commence a mail transfer.


The MAIL FROM command initiates a mail transfer. As an argument, MAIL FROM includes a sender mailbox (reverse-path). For some types of reporting messages like non-delivery notifications, the reverse-path may be void. Optional parameters may also be specified.

Example: MAIL FROM ""


The RCPT TO command specifies the recipient. As an argument, RCPT TO includes a destination mailbox (forward-path). In case of multiple recipients, RCPT TO will be used to specify each recipient separately.

Example: RCPT TO ""


With the DATA command, the client asks the server for permission to transfer the mail data. The response code 354 grants permission, and the client launches the delivery of the email contents line by line. This includes the date, from header, subject line, to header, attachments, and body text. 

A final line containing a period (“.”) terminates the mail data transfer. The server responses to the final line.

354 (server response code)
Date: Wed, 30 July 2019 06:04:34
Subject: How SMTP works
Body text


The NOOP command is used only to check whether the server can respond. “250 OK” reply in response

Example: NOOP


With the HELP command, the client requests a list of commands the server supports. HELP may be used with an argument (a specific command). If the server supports this, it will provide the information accordingly to this request. 

Example: HELP 


VRFY is used to verify whether a mailbox in the argument exists on the local host. The server response includes the user’s mailbox and may include the user’s full name. 

VRFY user2<br>250 Samantha Smith (server response)

EXPN is used to verify whether a mailing list in the argument exists on the local host. The positive response will specify the membership of the recipients. 

EXPN mail-list<br> (server response)<br> (server response)<br> (server response)

The hyphen (-) between the numerical code and the user’s mailbox indicates that the response is continued on the next line.

VRFY and EXPN implement SMTP authentication.  Also, they are useful to perform an internal audit of the server. On the other hand, these commands are considered a security risk. Spammers can use them to harvest valid email addresses from the server. Therefore, messaging systems either install corresponding protections or disable the commands. 


The RSET command resets the SMTP connection to the initial state. It erases all the buffers and state tables (both sender and recipient). RSET gets only the positive server response – 250. At the same time, the SMTP connection remains open and is ready for a new mail transaction. 

Example: RSET


The QUIT command send the request to terminate the SMTP session. Once the server responses with 221, the client closes the SMTP connection. This command specifies that the receiver MUST send a “221 OK” reply and then closes the transmission channel.

Example: QUIT

Extended SMTP commands that some SMTP servers may support


The <a href="">STARTTLS</a> command is used to start a TLS handshake for a secure SMTP session. STARTTLS resets the SMTP protocol to the initial state. Once the response 220 is received from the server, the SMTP client should send HELO or EHLO to launch the session. In the case of a negative response (454), the client must decide whether to continue the SMTP session or not.



The AUTH command is used to authenticate the client to the server. For this, it uses an argument that specifies different levels of security and login methods: PLAIN, LOGIN, and CRAM-MD5. The session is considered authenticated once the server provided a positive response. For more on this, read the SMTP authentication blog post.

Example: AUTH CRAM-MD5


The ATRN command replaced the obsolete TURN command. It was used to reverse the connection between the local and external SMTP servers (sender and receiver). TURN lacked authentication and hence was deprecated. ATRN is devoid of this drawback. Besides, it is available for dynamically assigned IP addresses. 

ATRN,<br>250 OK now reversing the connection (server response)


The BDAT command is used to submit mail contents. It can be an alternative to the DATA command. BDAT has two arguments. The first one defines the length of the data chunk in octets. The second one indicates that the data chunk is terminating. No need for a period to terminate mail transfer as it is in the DATA command. BDAT is widely used in Microsoft Exchange Server. At the same time, DATA is a must to support command for all servers. 

BDAT 67 LAST<br>To:<br>From:<br>Subject: How SMTP works<br>250 Message OK, 67 octets received (server response)


The ETRN command is the request to start SMTP queue processing of a specified server host. 

ETRN<br>250 OK, queuing for started (server response)

Private-use SMTP commands 

The client and the server may use private-use SMTP commands through a bilateral agreement. These are proprietary service extensions and should start with “X”. They must not be registered or standardized. Here are some of them:

  • XADR – releases status of the channel an address matches (how an address is routed internally)
  • XCIR – releases status of the circuit checking facility.
  • XSTA – releases status of  the number of messages in channel queues
  • XGEN – releases status of whether a compiled configuration and character set are in use.

Obsolete SMTP commands 

On the web, there are many outdated sources where you can encounter obsolete SMTP commands. Not to waste your time for invalid options, here is a list of the commands you can’t use anymore:

  • SEND
  • SOML 
  • SAML
  • TLS
  • TURN

SMTP response codes 

The SMTP server responses to the client using a three-digit code. Each digit has a special significance:

  • First (2 to 5) – denotes whether the request is accepted, incomplete, or declined
  • Second (0 to 5) – denotes the type of error occurred (syntax, information, connections, mail system, or unspecified (two options)). 
  • Third (0 to 5) – provides finest description (together with textual explanation)

The numerical code is followed by a text meant for a human user to get the point. Different servers can use a modified textual description of the response, while the numerical code is permanent. So, here is what your SMTP server can reply with:

Code What it means
101Server connection error (wrong server name or connection port)
211System status (response to HELP)
214Help message (response to HELP)
220The server is ready (response to the client’s attempt to establish a TCP connection)
221The server closes the transmission channel
235Authentication successful (response to AUTH)
250The requested command is completed. As a rule, the code is followed by OK
251User is not local, but the server will forward the message to <forward-path> 
252The server cannot verify the user (response to VRFY). The message will be accepted and attempted for delivery
334Response to the AUTH command when the requested security mechanism is accepted
354The server confirms mail content transfer (response to DATA). After that, the client starts sending the mail. Terminated with a period ( “.”)
421The server is not unavailable because it closes the transmission channel
422The recipient’s mailbox has exceeded its storage limit
431File overload (too many messages sent to a particular domain)
441No response from the recipient’s server
442Connection dropped
446Internal loop has occurred
450Mailbox unavailable (busy or temporarily blocked). Requested action aborted
451The server aborted the command due to a local error 
452The server aborted the command due to insufficient system storage
454TLS not available due to a temporary reason (response to STARTTLS)
455Parameters cannot be accommodated
471Mail server error due to the local spam filter
500Syntax error (also a command line may be too long). The server cannot recognize the command
501Syntax error in parameters or arguments
502The server has not implemented the command
503Improper sequence of commands
504The server has not implemented a command parameter
510Invalid email address
512A DNS error (recheck the address of your recipients)
523The total size of your mailing exceeds the recipient server limits
530Authentication problem that mostly requires the STARTTLS command to run
535Authentication failed
538Encryption required for a requested authentication mechanism
541Message rejected by spam filter
550Mailbox is unavailable. Server aborted the command because the mailbox was not found or for policy reasons. Alternatively: Authentication is required for relay
551User not local. The <forward-path> will be specified
552The server aborted the command because the mailbox is full
553Syntactically incorrect mail address 
554The transaction failed due to an unknown error
No SMTP service here as a response to the client’s attempts to establish a connection
555Parameters not recognized/ not implemented (response to MAIL FROM or RCPT TO)


As you may have noticed above, some codes are command-specific. Actually, only three of them, 500, 501, and 421 can be a response to any SMTP command. Others can be categorized as positive and negative (code 354 can be considered as an intermediate response). Let’s see which commands they can refer to.

CommandPositive responseNegative response
SMTP handshake (establishing a connection)220554
EHLO or HELO250502 (response to EHLO for old-time servers)
MAIL FROM250    451
354 (intermediate response)
550 (rejection for policy reasons)

This is the list of standard response codes. It should be also mentioned that some SMTP servers can generate other three-digit codes. In this case, the SMTP client will have to interpret the first digit that must be in a range from 2 to 5 inclusive. It denotes the essence of the response (successful or not). 

Example of an SMTP session

Now, let’s have a look at the example of a typical SMTP session flow. We’ll see two scenarios: a successful and aborted transaction.

Successful transaction with verification

Server: 220 Simple Mail Transfer Service Ready

Client: EHLO

S: greets

S: 250-DSN

S: 250-VRFY

S: 250 HELP

C: VRFY Maverick

S: 250 John Maverick <>


S: 250 OK


S: 250 OK


S: 550 No such user here


S: 354 Start mail input; end with <CRLF>.<CRLF>

C: Date: Wed, 30 July 2019 06:04:34

C: From:

C: Subject: Test email

C: To:,

C: Hi John and Samantha 

C: .

S: 250 OK


S: 221 Service closing transmission channel

In this example, the client received the 550 code that said that one of the recipients is not available. Nevertheless, the transaction was not aborted like in the example below. 

Aborted transaction 

Server: 220 Simple Mail Transfer Service Ready

Client: EHLO

S: greets

S: 250-DSN

S: 250 HELP


S: 250 OK


S: 550 No such user here


S: 250 OK


S: 221 Service closing transmission channel

Benefits of using a fake SMTP server

Once an email has landed on the sender’s SMTP server, it is still in the beginning of its journey. Before reaching the recipient’s mailbox, the email has to get to the recipient’s SMTP server, which forwards it to IMAP/POP3 server. And each server implements authentication before it lets the email in. For the purpose of testing email sending, this way is better to cut twice. And that’s why development teams opt for a fake SMTP server.

Mailtrap significantly simplifies the email delivery and allows you to test how your application sends messages. It’s not a tool to test SMTP server, but to send test email via SMTP. And it is an essential part of email testing checklist. Here’s how it looks in practice:

  • Step 1: Sender’s email client handshakes with the Mailtrap’s SMTP server (

All the necessary credentials like port, authentication method, and so on are available. Also, there are ready-to-use integrations for most common programming languages and web frameworks. All you need it to copy-paste them into your app code.

  • Step 2: SMTP server transmits the message to the POP3 server (

No issues related to improper configuration, authentication, or any sort of spamming real users are expected.

  • Step 3: Open your Demo inbox and you will see the message right there (if your app functions properly, of course).

So, the main benefit of a fake or dummy SMTP server is that it does not reply negatively to any SMTP command by the client. For more on this, read the Mailtrap getting started guide.

Article by Zakhar Yung Technical Content Writer @Mailtrap