SMTP Error 221

Is SMTP 221 actually an error?

No. SMTP 221 is a positive completion reply, not a failure. Per RFC 5321 §4.2.3 it is defined as:

221 <domain> Service closing transmission channel

It is the response a server sends after the client issues the QUIT command. RFC 5321 §4.1.1.10 specifies:

This command specifies that the receiver MUST send a "221 OK" reply, and then close the transmission channel.

In other words, seeing 221 means your SMTP conversation ended cleanly — the server processed everything it was given in this session and is closing the TCP connection as expected.

A typical healthy transcript looks like this:

C: QUIT
S: 221 2.0.0 smtp.example.com Service closing transmission channel
(connection closed)

The 2.0.0 is the RFC 3463 enhanced status code ("Success / Other or undefined status"), which many servers prepend to the 221.

Then why am I seeing SMTP 221 in my logs?

Because every successful SMTP session normally ends in 221. If your message was actually delivered (or accepted with a 250 2.0.0 OK after DATA), the trailing 221 is just confirmation of a clean shutdown — there is nothing to fix.

The original premise that 221 is an authentication failure is incorrect. Authentication problems surface as 535 5.7.8 (bad credentials) or 530 5.7.0 (authentication required), not 221. Do not chase username/password or "less secure apps" settings on the strength of a 221.

When does a 221 indicate a real problem?

The code itself is never the failure, but its position in the transcript can reveal one:

1. A failure occurred earlier in the session. Scroll up in the log. If you see a 4xx (transient — retry later) or 5xx (permanent) reply before the 221, that earlier line is the real error. For example, a 550 5.7.1 rejection followed by 221 means the recipient server refused the mail and then closed the channel normally.
2. The server closed before you sent QUIT. Some servers drop idle connections or enforce per-session limits, returning 221 (or, on forced shutdown, 421 per RFC 5321 §3.8) before you finished. If you were mid-transaction, treat this as a connection-handling issue: reduce idle time between commands, lower concurrent connections, or add reconnect-and-retry logic.
3. You parsed 221 as a delivery confirmation. Acceptance is signaled by 250 after DATA, not 221. If your code keys success off 221, fix it to check for 250 on the message-acceptance step.

How to verify what really happened

Capture the full SMTP transcript and inspect the reply before the 221:

S: 250 2.0.0 OK: queued as 9F2C1...   <-- message accepted here
C: QUIT
S: 221 2.0.0 Bye                       <-- clean close, no action needed

If the line before 221 is a 250, delivery to that hop succeeded. If it is anything in the 4xx/5xx range, look that code up instead — that is where your fix lives.

When sending through Courier, you don't manage the raw SMTP QUIT/221 handshake yourself; Courier's provider integrations report delivery status (accepted, delivered, bounced) through the message logs and webhooks, so you can rely on those events rather than parsing raw reply codes.