ESMTP vs SMTP: EHLO, extensions, TLS, authentication, and SIZE

ESMTP means Extended Simple Mail Transfer Protocol. In practice, modern SMTP clients say EHLO to ask the server which extensions it supports. The server returns capabilities such as STARTTLS, AUTH, SIZE, 8BITMIME, SMTPUTF8, PIPELINING, and DSN. The client may then use only the extensions advertised for that connection.

SMTP vs ESMTP in one table

SMTP                              ESMTP
HELO identifies the client             EHLO identifies client and requests extensions
Base command set                        Base SMTP plus advertised extension keywords
No capability list after HELO           Multiline 250 EHLO capability response
Client uses base behavior               Client selects supported extensions as needed
Still valid as fallback                 Normal mode for modern interoperable SMTP

ESMTP extends SMTP; it does not replace the underlying mail-transfer model.

How EHLO capability negotiation works

S: 220 mx.example ESMTP ready
C: EHLO sender.example
S: 250-mx.example greets sender.example
S: 250-PIPELINING
S: 250-SIZE 52428800
S: 250-STARTTLS
S: 250-8BITMIME
S: 250 SMTPUTF8
C: STARTTLS
S: 220 Ready to start TLS
... TLS negotiation ...
C: EHLO sender.example
S: 250-mx.example greets sender.example
S: 250-SIZE 52428800
S: 250 AUTH PLAIN LOGIN

Each 250- line continues the EHLO response and the final 250 line ends it. After STARTTLS, RFC 3207 requires the client to discard prior knowledge from the session and issue EHLO again because capabilities can change inside the protected channel. Authentication may be advertised only after TLS.

Common ESMTP extensions

EHLO vs HELO

EHLO asks for Extended SMTP and should receive the server's extension list. HELO uses base SMTP behavior and does not negotiate that list. RFC 5321 describes fallback when a server does not implement EHLO, but a modern client should not downgrade silently when doing so would violate required TLS, authentication, internationalization, or message-format policy.

• Use a stable, syntactically valid client identity in EHLO. Mail servers commonly use a fully qualified hostname when one is available.
• Parse multiline responses correctly; do not treat only the first capability line as the whole result.
• Issue EHLO again after STARTTLS and use the post-TLS capability set.
• Do not send an extension command or parameter unless the server advertised it for the current session.
• If fallback to HELO removes a required security or content capability, fail safely rather than changing message semantics invisibly.

Does ESMTP mean the connection is encrypted?

No. A server banner may say ESMTP even before TLS. STARTTLS is an ESMTP extension used to negotiate encryption on an established connection. Implicit TLS wraps the connection from its start and then SMTP commands run inside it. In either design, encryption depends on successful TLS negotiation and policy—not on the letter E in an email header or greeting.

Does ESMTP mean the sender authenticated?

No. Server-to-server SMTP commonly transfers mail without logging in as a mailbox user. Authenticated submission uses the AUTH extension when the server advertises it and policy permits it. Received headers sometimes contain tokens such as ESMTP, ESMTPS, or ESMTPSA, but these are server-generated trace conventions: S often indicates a secured connection and A often indicates authentication. Interpret them with the receiving system's documentation and surrounding header evidence.

ESMTP, MIME, and email authentication are different layers

Troubleshooting ESMTP negotiation

• Preserve the greeting, EHLO identity, every capability line, port, TLS mode, certificate result, and response codes.
• If STARTTLS is missing, verify the correct endpoint and port and whether a middlebox altered the session. Do not transmit credentials to investigate.
• If AUTH is missing before TLS, negotiate TLS and issue EHLO again. If still missing, check the route and account policy.
• If the server rejects an extension parameter, confirm that it was advertised and that the client syntax follows that extension's RFC.
• If a message exceeds SIZE, calculate the encoded message size—including MIME and base64 overhead—not just the original attachment bytes.
• If only HELO succeeds, decide whether base SMTP can carry this message safely and correctly; otherwise use a supported endpoint.

Frequently asked questions

Is ESMTP still used?

Yes. EHLO and extensions are normal modern SMTP behavior. People often say “SMTP” for the overall protocol even when the session is using Extended SMTP capabilities.

What port does ESMTP use?

ESMTP has no dedicated universal port. Port choice follows the service: typically 25 for server-to-server transfer, 587 for message submission with explicit TLS policy, or 465 for implicit-TLS submission. Follow the provider's exact configuration.

Can I see ESMTP in an email header?

A server may record a transport token in a Received header, but the original live EHLO response is the authoritative capability negotiation for that hop. Headers are useful trace evidence, not a complete transcript of every advertised extension.