The Anatomy of an SMTP Session: What Happens Between Send and Delivery

• March 2022
• Engineering Memo · External Release

Every message that leaves a sending MTA and arrives at a recipient's inbox has traversed an SMTP conversation — a structured protocol exchange between the sending server and the receiving server that determines whether the message is accepted, deferred, or rejected. Most email practitioners know the outcomes (delivered, bounced, deferred) without knowing the mechanism that produces them. This note documents the complete anatomy of an SMTP session, phase by phase, so that the accounting log's response codes and session timing data become interpretable rather than opaque.

Phase 1: DNS Lookup and MX Resolution

Before a single SMTP command is issued, the sending MTA must determine where to deliver the message. This begins with a DNS MX (Mail Exchanger) lookup for the recipient domain: the sending MTA queries DNS for the MX records of the recipient's domain, which return the hostnames of the servers that accept email for that domain, each with a priority value. Lower priority values indicate higher preference — the sending MTA attempts delivery to the lowest-priority MX first, falling back to higher-priority MX servers if the lower-priority server is unavailable.

DNS lookup failures at this stage — NXDOMAIN (the domain does not exist) or SERVFAIL (DNS query failed) — produce specific bounce types in the accounting log. NXDOMAIN for the recipient domain produces a bad-domain bounce: the domain itself does not exist, which is a permanent failure indicating a data quality problem in the recipient list. SERVFAIL produces a temporary failure: the DNS query failed due to a transient DNS infrastructure issue, and the message should be retried after a delay. Distinguishing NXDOMAIN from SERVFAIL requires looking at the specific DNS resolution error in the accounting log, not just the SMTP response code (since both may produce similar failure indicators without the DNS error detail).

After MX resolution, the sending MTA resolves the MX hostname to an IP address (A or AAAA record lookup). This second DNS lookup can also fail (if the MX hostname's A record does not exist or DNS is temporarily unavailable), producing a connection failure that appears in the accounting log as a TCP connection error rather than an SMTP response code.

Phase 2: TCP Connection and Greeting

With the receiving server's IP address resolved, the sending MTA initiates a TCP connection to port 25 (the standard SMTP port). The TCP three-way handshake (SYN, SYN-ACK, ACK) establishes the connection. Connection failures at this stage — TCP RST (connection refused), connection timeout (no response), or network unreachable — appear in the accounting log as connection errors without any SMTP response code.

Once the TCP connection is established, the receiving server sends a 220 greeting banner: 220 mail.example.com ESMTP Postfix. This banner identifies the receiving server and the SMTP protocol version it supports. The sending MTA waits for this 220 greeting before sending any SMTP commands. If the greeting does not arrive within the connect-timeout period, the connection is closed and the message is deferred.

The 220 greeting is also the receiving server's first opportunity to apply IP-based filtering. Some receiving servers — particularly those with greylisting or anti-spam pre-screening — introduce deliberate delays before the 220 greeting, or delay the first character of the greeting, to penalise senders that do not wait for the complete greeting before sending commands (a behaviour called "pipelining without EHLO"). A well-implemented sending MTA like PowerMTA always waits for the complete 220 greeting before proceeding.

Phase 3: EHLO and Capability Negotiation

After receiving the 220 greeting, the sending MTA issues the EHLO (Extended Hello) command, identifying itself by hostname: EHLO mail.sender.com. The receiving server responds with a 250 multi-line response listing the SMTP extensions it supports. Key extensions that appear in the EHLO response: STARTTLS (the server supports TLS encryption), PIPELINING (the server supports command pipelining), 8BITMIME (the server accepts 8-bit MIME content), AUTH (the server requires or supports authentication), and SIZE (the server's maximum accepted message size).

The EHLO hostname — what the sending MTA identifies itself as in the EHLO command — is evaluated by some receiving servers as a reputation signal. The EHLO hostname should match the sending IP's reverse DNS (PTR record). If the EHLO hostname is a generic or non-matching value (EHLO localhost, or EHLO mail.sender.com when the PTR record resolves to a different hostname), some receiving servers generate a soft failure or add a spam score penalty. PowerMTA's EHLO hostname configuration should always match the PTR record for the sending IP.

Phase 4: STARTTLS and TLS Negotiation

If the EHLO response includes STARTTLS and the sending MTA is configured for opportunistic TLS, the sending MTA issues the STARTTLS command. The receiving server responds with "220 Go ahead" (or a 454 error if TLS is unavailable). The TLS handshake then occurs synchronously — the session switches from plaintext to TLS-encrypted. After TLS negotiation completes, the sending MTA issues a second EHLO command to re-negotiate capabilities over the TLS connection. The capabilities available over TLS may differ from those available in plaintext.

The critical operational note about STARTTLS: no SMTP commands may be pipelined across the STARTTLS barrier. All commands before STARTTLS must complete and their responses received before STARTTLS is issued; STARTTLS must complete before any subsequent commands are issued. A sending MTA that pipelines commands across the STARTTLS barrier will encounter session errors at the receiving server.

Phase 5: MAIL FROM and Envelope Sender

The MAIL FROM command specifies the envelope sender address — the address that bounce notifications will be sent to, and the address that SPF is evaluated against. MAIL FROM: <bounce+id123@bounces.brand.com>. The receiving server evaluates this address: does the envelope sender domain have a valid SPF record? Does the SPF record authorise the sending IP? A MAIL FROM that fails SPF evaluation may be rejected (for strict SPF enforcement policies) or accepted with a negative trust signal (for most consumer ISPs).

The MAIL FROM envelope sender is separate from the From: header in the message body. The From: header is what recipients see; the MAIL FROM envelope sender is what SMTP infrastructure sees. SPF alignment (required for DMARC) means that the envelope sender domain must match the From: header domain — or the DKIM signing domain must match the From: header domain — for DMARC to pass. Using a bounce subdomain (bounces.brand.com) for the envelope sender while using the main domain (brand.com) in the From: header requires that bounces.brand.com's SPF record authorises the sending IP.

Phase 6: RCPT TO and Recipient Verification

The RCPT TO command specifies the recipient address: RCPT TO: <recipient@example.com>. The receiving server evaluates whether the recipient address exists and is accessible. A 250 response means the address is accepted; a 550 response typically means the address does not exist (hard bounce); a 452 response means the mailbox is temporarily unavailable (soft bounce). The specific response code and response text at the RCPT TO phase are the primary data points that PowerMTA's bounce classification uses to determine bounce type.

Some receiving servers implement "address verification callout" — they check the recipient address against their internal directory at the RCPT TO phase and return 550 immediately for invalid addresses rather than accepting the message and then generating a bounce. Others accept all RCPT TO commands (returning 250 for any address) and only discover invalid addresses after the message is delivered to the local system. The first approach (reject at RCPT TO) is better for senders because it produces clean, unambiguous hard bounce responses; the second approach (accept all, bounce later) produces non-delivery reports (NDR) after apparent delivery success, which are harder to process correctly.

Phase 7: DATA and Final Acceptance

The DATA command initiates message body transmission. The receiving server responds with "354 Start mail input" and the sending MTA transmits the complete message — headers and body — terminated by a line containing only a period ("."). After receiving the complete message, the receiving server performs content evaluation (spam scoring, virus scanning, policy checks) and returns a final response: 250 (accepted for delivery), 452 (insufficient storage — temporary), or 5xx (permanent rejection — policy, content, or blacklist).

The time between the end of DATA transmission and the 250 response can be seconds or minutes, depending on the receiving server's content evaluation complexity. Servers running Proofpoint or Mimecast content scanning may take 30-90 seconds to process the message. Servers with simple spam filters respond within 1-2 seconds. The data-timeout in PowerMTA's configuration must accommodate the longest expected evaluation time for each destination type — set too short, and the connection times out before the 250 arrives, causing the message to be re-queued as a temporary failure even though the receiving server actually accepted it.

The 250 response at the end of the DATA phase is the confirmation of successful delivery. Once the sending MTA receives this 250, the message is considered delivered — the receiving server has accepted responsibility for it. The SMTP conversation ends with the QUIT command and a 221 response from the receiving server, closing the session cleanly.

Reading the Accounting Log Through the Session Lens

With the complete SMTP session anatomy in mind, the accounting log becomes a session-phase diagnostic tool. A connection error (no SMTP response code, timeout or TCP RST) indicates failure in Phase 2 (TCP connection) or Phase 3 (greeting/EHLO). A 5xx response at MAIL FROM indicates Phase 5 failure — SPF evaluation or policy rejection of the envelope sender. A 5xx response at RCPT TO indicates Phase 6 failure — recipient address verification, producing a hard bounce that should trigger suppression. A 5xx response at DATA (after 250 RCPT TO) indicates Phase 7 failure — content or policy rejection, which requires investigation of the content or the sending reputation rather than recipient address suppression. Each phase of the SMTP session maps to a specific failure pattern in the accounting log; reading the log through this session-phase map converts delivery outcome data into actionable diagnosis.

Understanding the complete anatomy of an SMTP session is the protocol-layer knowledge that makes every other deliverability management practice more interpretable. The accounting log speaks in SMTP response codes and session timing data; knowing what each phase of the session looks like in normal and abnormal operation is what makes the accounting log a diagnostic tool rather than a raw data file. Build this knowledge, apply it when reading the accounting log, and the SMTP conversation that underlies every delivery outcome will speak clearly about what succeeded, what failed, and why.

Session Reuse: Delivering Multiple Messages Per Connection

A single SMTP session can deliver multiple messages to the same receiving server before closing with QUIT. After a successful DATA+250 sequence for the first message, the sending MTA can issue another MAIL FROM for the next message without closing and reopening the TCP connection. This session reuse — controlled by PowerMTA's max-msg-per-connection setting — reduces connection overhead and improves throughput for high-volume sending.

When session reuse is enabled and a RCPT TO rejection (550) occurs for one of the messages in a multi-message session, the session can continue delivering subsequent messages after handling the rejection. The rejection is recorded in the accounting log for the specific failed recipient, and the session proceeds with the next MAIL FROM without closing. This multi-message session handling is one of PowerMTA's efficiency features that requires correct accounting log processing to capture per-message outcomes correctly even when multiple messages share a session.

The session reuse limit (max-msg-per-connection) determines when the sending MTA closes a session and opens a new one. When the per-connection limit is reached, the current session closes with QUIT and a new TCP connection is established for subsequent messages. The reconnection overhead (TCP handshake, EHLO, STARTTLS, second EHLO) adds approximately 50-200ms per session — which at high message rates makes the per-connection message count a throughput-relevant configuration parameter.

What Each Session Phase Tells You About the Receiving Server

The characteristics of each SMTP session phase reveal information about the receiving server's configuration and anti-spam practices. A receiving server that delays the 220 greeting by 10-30 seconds is using a "tarpitting" approach to slow bulk senders. A server that returns 421 after accepting a connection is actively throttling the sender. A server that accepts all RCPT TO addresses without verification is using a "catch-all" or "accept-and-bounce-later" policy. A server that returns 5xx at DATA after returning 250 at RCPT TO is using post-acceptance content filtering that rejected the message.

Each of these patterns has a specific operational implication for how messages should be delivered to that server. Tarpitting requires longer RCPT TO timeouts. Active throttling requires reduced connection concurrency. Catch-all servers generate NDR bounces that must be processed separately from direct RCPT TO rejections. Post-acceptance content filtering rejections at DATA require investigation of content or reputation rather than immediate recipient suppression (the RCPT TO 250 indicates the address is valid, so the 5xx at DATA is a content/policy issue, not an address issue).

Building per-domain configuration in PowerMTA that reflects each destination's specific SMTP session characteristics is the granular configuration work that optimises delivery efficiency and minimises false interpretations of session failures. The corporate Exchange server that tarpits needs different timeout settings than the Gmail infrastructure that responds immediately. The catch-all domain that generates NDR bounces needs different bounce processing than the ISP that returns clean 550 rejections at RCPT TO. The SMTP session anatomy provides the framework for understanding these differences; per-destination configuration is the operational response.

SMTP Extensions That Affect Session Behaviour

CHUNKING (BDAT): An alternative to the DATA command that allows message body transmission in chunks using the BDAT command. Supported by some receiving servers (visible in the EHLO response as CHUNKING). For large messages, BDAT can improve transmission efficiency by eliminating dot-stuffing overhead. PowerMTA supports BDAT when the receiving server advertises CHUNKING. For most commercial email, the DATA command is sufficient and BDAT provides marginal benefit.

AUTH: Some SMTP configurations require authentication before accepting messages (used for submission ports, less common for MX delivery). When AUTH appears in the EHLO response for MX delivery, it typically indicates a misconfigured or unusual receiving server. PowerMTA handles AUTH when required for specific delivery scenarios.

SMTPUTF8: Enables UTF-8 characters in email addresses (internationalized email addresses). When the EHLO response includes SMTPUTF8, the session can handle recipient addresses with non-ASCII characters. This is relevant for sending to some international domains where recipient addresses use Unicode characters. PowerMTA's SMTPUTF8 support enables delivery to these addresses when the receiving server supports the extension.

The SMTP session is a surprisingly rich protocol conversation when examined closely. Each command and response carries information about both parties to the exchange: the sending MTA's identity and capabilities, the receiving server's policy and acceptance criteria, and the specific disposition of each message in the session. Reading that conversation through the anatomy described in this note — phase by phase, command by command — is the protocol-layer literacy that makes every accounting log entry interpretable and every delivery outcome explainable. The sending MTA speaks SMTP; learning to read what it says is how operators understand what is happening to the messages they send.

SMTP Session Metrics Worth Tracking

Several SMTP session metrics that are available in PowerMTA's accounting log provide operational intelligence beyond the basic delivery outcome. Session duration — the time from TCP connection to QUIT — reveals the typical session length for each ISP. Sessions that are consistently much longer than average for a specific ISP indicate a specific phase is slow (tarpit at RCPT TO, long content scan at DATA). Sessions that terminate early (before QUIT) indicate disconnections by the receiving server, which may be throttle-related.

The time-to-250 metric — the delay between the end of DATA transmission and the 250 final acceptance response — is particularly valuable for identifying content scanning destinations. A consistent 30-60 second time-to-250 for a specific corporate domain indicates Proofpoint or Mimecast content scanning; this information should inform the data-timeout configuration for that domain block. A variable time-to-250 that spikes above the configured timeout during specific campaigns may indicate that those campaigns' content is triggering more intensive scanning at that destination.

Retry count per message — how many SMTP session attempts were required before a message delivered or finally failed — identifies the addresses and destinations where delivery required multiple attempts. High retry counts for a specific ISP indicate persistent throttle or delivery difficulty at that ISP; high retry counts for specific recipient addresses indicate addresses that are borderline (consistently deferring without a hard rejection). Both patterns are diagnostically valuable and are captured in the accounting log's retry count field when PowerMTA is configured to log it.

The SMTP session is the email delivery system's most fundamental unit of operation. Every message delivery, every bounce, every deferral, every successful acceptance is the outcome of a specific sequence of SMTP commands and server responses. The session anatomy in this note is the map; the accounting log is the territory. When the map and territory are both understood, every delivery outcome — success, failure, deferral — can be traced to the specific session phase that produced it and addressed with the appropriate operational response. SMTP fluency is the foundation on which all email infrastructure management expertise is built. Build it.

Seven phases. Seven potential failure points. One successful delivery. The SMTP session anatomy is the infrastructure knowledge that makes each failure point identifiable and each success explainable. Master it, and the accounting log becomes transparent. Let it remain opaque, and every delivery anomaly requires guesswork rather than diagnosis. The investment in SMTP fluency is the investment that makes all other email infrastructure expertise compoundingly more useful.

Every delivery starts with DNS and ends with 250. Between those two points, seven phases of protocol exchange determine the outcome. Know each phase. Read the log through the phase lens. The SMTP session will tell you everything about why your messages arrive, are deferred, or are rejected -- if you know how to listen.