SMTP Error 250

TL;DR: SMTP 250 is a success code, not an error. Per RFC 5321 §4.2.1 it means "Requested mail action okay, completed." If you see 250 in a log, the command worked — there is nothing to fix.

Is SMTP 250 an error?

No. SMTP reply codes in the 2yz class are Positive Completion replies — the command was received, understood, and accepted (RFC 5321 §4.2.1). 250 specifically is the most common success response in an SMTP conversation. Any documentation that describes 250 as an authentication failure or a TLS/cipher misconfiguration is incorrect; those conditions produce 4xx or 5xx codes (e.g. 535 for bad auth, 530 when auth is required), never 250.

What does 250 mean at each step of the SMTP transaction?

A server emits 250 after successfully processing most commands. The same code appears at several stages, so context matters:

• EHLO/HELO — Typical 250 response: 250-mail.example.com (+ extension lines); Meaning: Session opened; capabilities advertised
• MAIL FROM — Typical 250 response: 250 2.1.0 Sender OK; Meaning: Envelope sender accepted
• RCPT TO — Typical 250 response: 250 2.1.5 Recipient OK; Meaning: Recipient address accepted
• DATA (after the message body + .) — Typical 250 response: 250 2.0.0 OK: queued as <id>; Meaning: Message body accepted and queued

The three-part code after 250 is an enhanced status code (RFC 3463): 2.0.0 = generic success, 2.1.0 = Other/Undefined address status — RFC 3463 has no code specifically meaning "sender valid"; many MTAs (Postfix, Sendmail) conventionally reuse X.1.0 to report a clean MAIL FROM, but per the RFC it is only a generic address-status catch-all, 2.1.5 = destination address valid.

A 250 OK does not guarantee inbox delivery

This is the one thing worth understanding about 250. A 250 after DATA means the receiving (or relay) server took responsibility for the message — it does not mean the message landed in the recipient's inbox. After acceptance the message can still be:

• filtered to spam or silently dropped,
• bounced asynchronously as a Delivery Status Notification (DSN) to the envelope sender, or
• rejected downstream by a relay's own rules.

Mailbox and relay providers make this explicit: Twilio SendGrid notes that a 250 OK confirms only that the receiving server accepted the message for delivery, not that it reached the inbox — subsequent spam filtering, blocking, or DSN bounces can still occur downstream. So if a message was "accepted" but never arrived, stop looking at the 250 and instead check your provider's bounce/event webhooks, the recipient's spam folder, and your SPF/DKIM/DMARC alignment.

When you should actually investigate

You only need to act if a 250 is what you expected but the mail still didn't arrive. In that case the 250 is a red herring — the problem is post-acceptance:

1. Check delivery events, not the SMTP code. With Courier (or any provider), inspect the message event log / bounce webhook for the final status rather than the initial 250.
2. Confirm authentication aligns. Verify SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) pass for your sending domain — failures here cause silent spam-foldering even after a 250.
3. Verify your sending domain in your ESP. A configured-but-unverified domain is the most common reason a 250-accepted message never delivers.