SMTP是一个对话，而不是一个发送按钮。客户端打开连接、标识自身、提供信封、传输消息内容并读取服务器的响应。每个响应都属于特定的命令和服务器。了解这一顺序可以解释为什么一个收件人失败而另一个收件人被接受，以及为什么最初的成功并不能证明最终的交付。
从联系和问候开始
服务器发送问候语，通常以 220 开头。客户端使用 EHLO 识别自己的身份并请求扩展信息； HELO提供较旧的基本问候语形式。多行EHLO回复在最后一行之前使用连续行。成功后 STARTTLS 握手， RFC 3207要求双方丢弃在TLS之前学到的SMTP知识；客户端应首先发送EHLO以发现受保护会话的功能。不要重复使用早期的扩展列表。
协议顺序和回复规则定义为 RFC 5321。身份验证、 TLS和提交策略是额外的问题，但不能证明可见的发件人地址已自动授权。记录对等点、时间和协商功能，无需保留密码或可重复使用的身份验证令牌。
将信封分开放置
邮件来自 提供用于传输处理和故障的反向路径。 RCPT TO 为当前交易提供接收者。这两个命令都不是消息内可见的 From 或 To 标头。一个事务可以包含多个 RCPT 命令，服务器可以接受一些命令，同时拒绝其他命令。
考虑这个合成序列，而不是捕获的交换。 MAIL FROM 收到 250。missing@receiver.test missing@receiver.test RCPT TO 收到 550 5.1.1， accepted@receiver.test的 RCPT TO 收到 250。接受的收件人仍然有资格进行后续的数据传输；该服务器尚未接受被拒绝的收件人。这些虚构的地址和回复并不描述公共服务。
传输消息并阅读最终回复
在至少一个接收者被接受后，DATA 请求内容传输。 354 响应邀请客户端发送标头和正文，并以所需的点行结尾。点透明度可防止以点开头的内容行被误认为终止符。例如，以 .example 开头的内容行会以额外的前导点作为 ..example 进行传输；接收SMTP层删除添加的点。仅由终止点组成的线具有不同的作用。
决定性的消息接受响应出现在内容之后，而不是在 354 处。在合成序列中，假设服务器在终止点之后返回 250，并带有服务器本地队列标识符。真正的接受SMTP服务器承担RFC 5321中所描述的责任，但接受仍然不能保证收件箱放置、阅读或稍后下游跃点的成功。如果连接在最终回复之前消失，客户端可能不知道是否已接受；在调查重试时考虑可能的重复投递。
在上下文中解释失败
4xx 回复是暂时的否定完成； 5xx 回复是对该请求的永久否定完成。保留完整回复和任何增强代码，因为裸露的 550 无法识别 DMARC 作为原因。重试行为还取决于队列策略和消息的有用性。无限期地重复无效的收件人并不能修复它。
如果 AUTH 不受支持或被拒绝，请将其记录为单独的命令结果。它本身并不描述接收者有效性、最终数据接受或下游域身份验证结果。对于真正的调查，请将记录与发件人队列日志、收件人跟踪和适用的策略相关联，并标记缺少证据的任何阶段。本指南的示例是假设的；没有为他们执行登录、套接字交换或邮件传递。
建立命令和结果分类账
- 连接：记录实际的对方、时间和问候语。
- 功能：在任何TLS协商之前和之后分别保存EHLO结果。
- 信封：单独保留 MAIL FROM 和每个 RCPT TO 结果。
- 内容：区分354邀请和终止点后的最终回复。
- 不确定性：如果最终答复丢失，则将接受标记为未知，并在声明失败之前检查接收器/队列证据。
- 关闭：记录最终消息处理和未解决的下游阶段，而不记录凭据。