SMTP response codes 220, 221, and 250: what each one means

SMTP reply codes follow a three-digit structure defined in RFC 5321: the first digit is the broad outcome (2 = success, 3 = intermediate, 4 = temporary failure, 5 = permanent failure), and the full code marks a specific stage of the conversation. 220, 221, and 250 are all "2xx" successes, but they appear at different points and mean different things. 200 is not actually a standard SMTP reply code at all - RFC 5321 does not define it, so if you see it reported, the server is either using it loosely as a generic success in logging, or the "200" is coming from an unrelated system (HTTP, a webhook, an API wrapper around SMTP) rather than the raw SMTP dialogue itself.

A real session, annotated

$ openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf
220 smtp.example.com ESMTP ready                     <- connection banner
EHLO client.example.org
250-smtp.example.com Hello client.example.org         <- EHLO accepted
250-SIZE 35882577
250-STARTTLS
250 AUTH LOGIN PLAIN
AUTH LOGIN
334 VXNlcm5hbWU6
<base64 username>
334 UGFzc3dvcmQ6
<base64 password>
235 2.7.0 Authentication successful
MAIL FROM:<sender@example.org>
250 2.1.0 Ok                                          <- MAIL FROM accepted
RCPT TO:<recipient@example.com>
250 2.1.5 Ok                                          <- RCPT TO accepted
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Test
.
250 2.0.0 Ok: queued as A1B2C3D4                      <- message accepted
QUIT
221 2.0.0 Bye                                         <- connection closing

220 - Service ready

The very first line a server sends after the TCP (or TLS, post-STARTTLS) connection opens. It means "I am ready to receive commands," not that any email has been accepted yet. If you never see a 220, the connection itself failed - check the port, firewall, and whether the server is actually listening.

250 - Requested action completed

By far the most common code in a session. It appears after EHLO/HELO, after MAIL FROM, after RCPT TO, and after the final . that ends the DATA block. Each 250 confirms that specific command succeeded - it does not confirm final delivery to the recipient's mailbox, only that this hop accepted the message for further processing or queuing. Many servers append an enhanced status code, like 250 2.1.5, which gives more specific context per RFC 3463.

221 - Service closing transmission channel

Sent in response to QUIT, confirming the server is closing the connection cleanly. Seeing 221 before you sent QUIT (an unexpected early close) usually indicates the server is terminating the session for a policy reason - rate limiting, abuse detection, or a timeout - which is worth investigating even though 221 itself is technically a "success" code.

200 - Not a real SMTP code

RFC 5321's reply code table starts at 211 (system status) and 214 (help) within the 2xx range; 200 isn't part of the defined set. If a tool or log reports "SMTP 200," it's most often one of: a REST API wrapper (SendGrid's, Mailgun's, or similar HTTP APIs) reporting its own HTTP 200 success and mislabelling it as an "SMTP code," a custom logging layer using 200 as a generic internal success marker, or a webhook delivery-status callback conflating HTTP and SMTP status spaces. Worth tracing to the actual source before treating it as part of the SMTP dialogue.

How this differs by provider in practice

The codes themselves are standard; the enhanced status text after them is provider-specific and is often the more useful diagnostic string when something fails further down the chain.

Why these codes rarely appear alone

In practice, the three-digit code is only half the useful information - the enhanced status code and free-text message that follow it carry the actual diagnosis. A 250 2.1.5 and a bare 250 Ok both mean "recipient accepted," but only the first confirms via RFC 3463 enhanced codes that the server is reporting detail beyond the base SMTP spec, which matters when a provider later changes behaviour and you need to tell whether a reply code's meaning has shifted or whether just the surrounding text has. When reading logs, always capture the full line, not just the leading three digits - the text after it is frequently where the receiving server actually explains *why* a 250 took longer than expected, or why a 221 arrived sooner than your side initiated it.

What not to do

Do not treat a 250 on RCPT TO as proof the mailbox exists and is healthy - some servers accept all recipients at SMTP time and bounce later (a "backscatter" pattern), so a 250 here is necessary but not sufficient evidence of a good send. Do not confuse an early, unsolicited 221 with a clean quit - check what preceded it. And do not assume a reported "200" is a verified SMTP-layer success without tracing which system actually generated that number.

MailPilot's deliverability checks look past the connection-level reply codes to real per-provider inbox placement, which is the layer that actually matters once the SMTP handshake itself is confirmed healthy.