SMTP vs. ESMTP: what the difference actually is, and why it still matters

SMTP is the original protocol, and it's genuinely limited

The Simple Mail Transfer Protocol (SMTP), formally defined in RFC 821 and later RFC 5321, describes the basic conversation a sending mail server has with a receiving one: identify yourself, specify the sender, specify the recipient, transmit the message body, and close. It has no built-in concept of authentication, no way to negotiate message size limits in advance, and no standard mechanism for encrypting the connection - all things modern mail sending depends on.

ESMTP extended the protocol without breaking it

Extended SMTP (ESMTP), defined in RFC 1869 and extended since, added a negotiation step at the start of the conversation: instead of the sending server just announcing itself with HELO, it uses EHLO, and the receiving server responds with a list of extensions it supports. This is why EHLO matters practically - it's the single change that opened the door for every capability that followed, while remaining backward-compatible with plain SMTP servers that only understand HELO.

A sample exchange showing the difference

Plain SMTP:
HELO mail.example.com
250 mail.example.com

ESMTP:
EHLO mail.example.com
250-mail.example.com
250-AUTH LOGIN PLAIN
250-STARTTLS
250-SIZE 35882577
250 8BITMIME

The 250- lines after EHLO are the receiving server advertising what it supports: authentication methods, STARTTLS for encrypting the connection, a maximum message size, and 8-bit MIME support for handling non-ASCII content properly.

What ESMTP extensions actually enable

Why this distinction matters for deliverability work, specifically

AUTH and STARTTLS are the two extensions that matter most practically: virtually no legitimate receiving mail server today accepts bulk mail over an unauthenticated, unencrypted plain-SMTP connection, which is part of why basic SMTP relay without these extensions gets treated with heavy suspicion. When troubleshooting a connection-level delivery failure (distinct from a content or reputation-based filtering issue), the specific ESMTP extension involved - an AUTH failure versus a STARTTLS negotiation failure versus a SIZE limit rejection - points to a different, specific fix, rather than a generic "connection failed" diagnosis.

Checking a server's ESMTP support directly

You can see exactly what a receiving mail server supports by connecting to it directly and issuing an EHLO command, which is a useful first troubleshooting step when a connection-level delivery problem is suspected rather than a reputation or content issue:

openssl s_client -starttls smtp -connect mail.example.com:25
EHLO test.example.com

The response lists every extension that server advertises - compare it against what your own sending infrastructure expects to use (AUTH, STARTTLS, SIZE) to confirm the receiving server actually supports what you're attempting, rather than assuming a generic connection failure must be reputation-related when it might simply be a protocol-level mismatch or a server that doesn't support an extension your sending setup requires.

This kind of direct check is most useful early in diagnosing a delivery failure, before spending time on reputation or content investigation that assumes the connection itself is working correctly. Keep a note of which extensions your actual sending and receiving infrastructure rely on day to day, since this short list is usually enough to diagnose the large majority of connection-level issues quickly, without needing to re-derive the full extension set from scratch each time something goes wrong. Keep this note alongside your broader deliverability documentation rather than in a separate technical wiki only your infrastructure team checks, since a marketing-side team member troubleshooting a delivery issue benefits from knowing these basics exist, even if they're not the one running the actual check.

What not to do

Do not assume "SMTP" and "ESMTP" are interchangeable terms when debugging a connection issue - checking which extensions a server actually advertises (via its EHLO response) can isolate the problem faster than assuming the whole protocol stack is misbehaving. Do not disable STARTTLS to "simplify" a connection issue - most receiving servers now require or strongly prefer an encrypted session, and disabling it tends to make delivery worse, not better. Do not confuse an ESMTP-level failure (connection, authentication, size) with a reputation or content-based filtering decision - they happen at different stages and need different troubleshooting.

MailPilot connects to mailboxes over both OAuth (Gmail, Outlook) and direct SMTP/IMAP (SendGrid, Amazon SES, Mailgun, Postmark, custom SMTP), handling the ESMTP-level connection details so warm-up and deliverability tracking work the same regardless of which protocol path a given mailbox uses.