The sending system logged SMTP 250 OK, but the recipient says nothing arrived. What does that acceptance prove, and which server should you investigate next?
Read 250 at the right point
SMTP’s 250 is a positive reply, but its meaning depends on the command it answers. In a typical transaction, the client identifies itself, issues MAIL FROM, proposes recipients with RCPT TO, then sends message content after DATA. A server may reply 250 at several stages: a 250 to MAIL FROM or RCPT TO is not acceptance of the complete message. Preserve the reply after <CRLF>.<CRLF>, the end-of-data decision point [1].
After complete DATA, a positive 2yz—commonly 250 OK—means this receiving SMTP server accepted responsibility for the message. RFC 5321 describes that as delivering it if the recipient mailbox exists, retrying transient failures, or reporting a failure through the proper mechanism [1]. It is a protocol handoff, not proof the message has been placed in the Inbox, displayed in a mail app, or read. The reply establishes acceptance at one boundary, not the eventual mailbox outcome.
Find out which server said yes
Start by naming the system that answered. An application may submit through an authenticated Message Submission Agent (MSA), often on port 587, which can deliver locally or relay to another mail transfer agent. The standards distinguish message submission from relay [2]. If the submission host returned the final 250, you know that host accepted the message for its next processing step; you do not yet know that the recipient-domain MX was contacted.
Follow actual handoffs, not assumptions from a dashboard label. The sending relay may hold a queue item, choose a route, and later connect to an MX for the recipient’s domain. That MX may be a filtering gateway, not the mailbox store. A final 250 after DATA from that receiving host establishes acceptance at that later SMTP hop [1]; internal transport and mailbox handling can still follow. Record the peer host/IP and queue identifiers so a relay’s 250 is not mistaken for the recipient MX’s response.
Acceptance is not inbox placement
Neither SMTP’s final 250 nor an outbound status called accepted names a folder or proves visibility. After SMTP handoff, the receiving service can apply authentication, reputation, spam, quarantine, routing and recipient rules. Google says unauthenticated messages may be marked as spam or rejected, and that authentication makes messages less likely to be rejected or spam-marked—not guaranteed to reach the Inbox [3]. A sender’s acceptance log does not disclose which later decision occurred.
Use recipient-side evidence for recipient-side questions. Microsoft 365 message trace, for example, distinguishes receive, send, deliver, fail and defer events, and exposes statuses for quarantine or filtered-as-spam outcomes [4]. An administrator can use that evidence to distinguish service receipt from mailbox delivery or quarantine; those events are not encoded in the sender’s earlier 250. Likewise, no bounce in your own logs is not affirmative proof of inbox placement.
Build the evidence trail
Begin with the original evidence, not a paraphrase: capture the responding hostname and IP, port, UTC timestamp, recipient, message identifier, transaction stage, exact SMTP reply (including any enhanced code and text), and queue ID. Retain enough transcript to show DATA, the end marker, and the reply that followed. Redact credentials and sensitive content before sharing logs. For multiple recipients, record acceptance and later status per recipient; SMTP outcomes can differ [1].
Next, classify the reply and identify the responder’s role. Did 250 follow MAIL FROM, a RCPT TO, or only the end-of-data marker? Did your application connect to its configured submission relay, or did a sending MTA connect to a recipient-domain MX? Save the relay’s queue record and actual next-hop host and reply. A live DNS lookup may explain routing, but contemporaneous connection logs show which system actually accepted that hop.
Trace onward, then check the recipient side
Ask the sending-relay operator to match its queue ID, envelope recipient, time and Message-ID to an attempted next hop. Record whether the item is queued, deferred/retrying, failed, or handed to a receiving host, and preserve that host’s final-DATA reply. Until that later handoff is evidenced, scope the finding to acceptance by the submission relay—not acceptance by the recipient MX. The server that accepted the message is the right place to investigate its subsequent handling [1][2].
If a recipient-domain MX gave the final 250, ask the recipient’s mail administrator to trace the message by recipient, time, Message-ID and provider trace ID; then check the recorded status and intended mailbox, spam/quarantine, aliases, forwarding and rules. Microsoft trace is one example of evidence that can separate mailbox delivery from filtering outcomes [4]. If no trace is available, ask the recipient to search and involve their administrator. Recheck authentication where relevant: it is a diagnostic clue, not proof of placement [3].
Fictional example (synthetic .invalid domains; no real delivery data)
Example only. No customer message, real mailbox or live account data is shown.
10:02:11Z app → relay.sender.invalid:587 | after DATA terminator | 250 2.0.0 queued RLY-104210:02:16Z relay log → mx.recipient.invalid:25 | after DATA terminator | 250 2.0.0 accepted MX-558Recipient administrator’s fictional trace | MX-558 / Message-ID | quarantined by policy; no Inbox deliveryThe first reply proves acceptance by the submission relay. The second proves that the recipient-domain MX/gateway accepted the SMTP message at the next hop. The fictional recipient-side trace supplies the later disposition: quarantine. Neither 250 alone says what folder the recipient can see.
What to check next
- 01Preserve the raw SMTP transcript and UTC time, endpoint host/IP and port, envelope recipient, Message-ID, exact reply text/code, and queue ID; redact credentials and sensitive content.
- 02Mark which command received each 250. Confirm that a final positive reply followed the DATA terminator; a MAIL FROM or RCPT TO reply is a different stage.
- 03Identify the responder: configured submission relay/MSA or the actual recipient-domain MX/gateway. Save the peer host/IP from logs rather than inferring it from a current DNS lookup.
- 04Match the sending relay’s queue ID to the envelope recipient and next-hop attempt; record retries, deferrals, failure notices, and the next host’s final DATA reply.
- 05If the recipient MX accepted the message, ask the recipient administrator to search provider trace by recipient, time, Message-ID and trace ID, and record the actual disposition.
- 06Check the intended mailbox, spam/quarantine, aliases, forwarding and recipient rules. Treat authentication results as diagnostic evidence, not a guarantee of Inbox placement.
Check the source
Standards and provider documentation are linked beside the claims they support. Provider policies can change; check the current document before changing a live sending program.
- [1]RFC 5321: Simple Mail Transfer Protocol SMTP command sequence; meaning of a positive completion after end-of-data; accepting server’s responsibility to deliver, retry transient failures or report delivery failure.
- [2]RFC 6409: Message Submission for Mail Distinction between message submission and relay; an MSA accepts messages and either delivers them or relays them to an MTA.
- [3]Email sender guidelines - Gmail Help Google’s guidance that unauthenticated messages may be spam-marked or rejected and authentication can reduce those risks, without guaranteeing Inbox placement.
- [4]Message trace in the new EAC in Exchange Online - Microsoft Learn Microsoft 365 message-trace events and statuses, including receive, deliver, fail, defer, quarantine and filtered-as-spam outcomes.