SMTP is a conversation, not a single send button. A client opens a connection, identifies itself, supplies an envelope, transfers message content and reads the server's responses. Each response belongs to a specific command and server. Understanding that sequence makes it possible to explain why one recipient failed while another was accepted and why an initial success does not prove final delivery.
Start with the connection and greeting
The server sends a greeting, commonly beginning 220. The client uses EHLO to identify itself and request extension information; HELO provides the older basic greeting form. A multiline EHLO reply uses continuation lines before its final line. After a successful STARTTLS handshake, RFC 3207 requires both sides to discard SMTP knowledge learned before TLS; the client should send EHLO first to discover the protected session’s capabilities. Do not reuse the earlier extension list.
The protocol sequence and reply rules are defined by RFC 5321. Authentication, TLS and submission policy are additional concerns, not evidence that the visible From address is automatically authorized. Log the peer, time and negotiated features without retaining passwords or reusable authentication tokens.
Keep the envelope separate
MAIL FROM supplies the reverse path used for transport handling and failures. RCPT TO supplies a recipient for the current transaction. Neither command is the visible From or To header inside the message. A transaction can contain several RCPT commands, and the server can accept some while rejecting others.
Consider this synthetic sequence, not a captured exchange. MAIL FROM receives 250. RCPT TO for missing@receiver.test receives 550 5.1.1, while RCPT TO for accepted@receiver.test receives 250. The accepted recipient can remain eligible for the subsequent DATA transfer; the rejected recipient has not been accepted by that server. These fictional addresses and replies do not describe a public service.
Transfer the message and read the final response
After at least one recipient is accepted, DATA requests content transfer. A 354 response invites the client to send the headers and body, ending with the required dot line. Dot transparency prevents a content line beginning with a dot from being mistaken for the terminator. For example, a content line beginning .example is transmitted with an extra leading dot as ..example; the receiving SMTP layer removes that added dot. A line consisting only of the terminating dot has a different role.
The decisive message-acceptance response comes after the content, not at 354. In the synthetic sequence, suppose the server returns 250 after the terminating dot, with a server-local queue identifier. A real accepting SMTP server assumes responsibility as described by RFC 5321, but acceptance is still not a guarantee of inbox placement, reading or success at a later downstream hop. If the connection disappears before the final reply, the client may not know whether acceptance happened; account for possible duplicate delivery when investigating retries.
Interpret failures in context
A 4xx reply is a transient negative completion; a 5xx reply is a permanent negative completion for the request. Preserve the full reply and any enhanced code, because a bare 550 does not identify DMARC as the cause. Retry behavior also depends on queue policy and the usefulness of the message. Repeating an invalid recipient indefinitely does not repair it.
If AUTH is unsupported or rejected, record that as a separate command outcome. It does not by itself describe recipient validity, final DATA acceptance or a downstream domain-authentication result. For a real investigation, correlate the transcript with sender queue logs, recipient trace and the applicable policy, and label any stage for which evidence is missing. This guide’s examples are hypothetical; no login, socket exchange or mail delivery was performed for them.
Build a command and outcome ledger
- Connection: record the actual peer, time and greeting.
- Capabilities: save EHLO results separately before and after any TLS negotiation.
- Envelope: retain MAIL FROM and each RCPT TO result separately.
- Content: distinguish the 354 invitation from the final reply after the terminating dot.
- Uncertainty: if the final reply is missing, mark acceptance unknown and inspect receiver/queue evidence before claiming failure.
- Closure: record the final message disposition and unresolved downstream stages, without logging credentials.