Does ESMTPS mean the message used TLS?

Yes. RFC 3848 defines ESMTPS as ESMTP "when STARTTLS is also successfully negotiated to provide a strong transport encryption layer" on that hop. Note that the registry defines the keyword in terms of STARTTLS, while common MTAs emit it for any TLS-protected ESMTP session, including implicit TLS on port 465.

What is the difference between ESMTPS and ESMTPSA?

Only the authentication half. ESMTPS records TLS alone. ESMTPSA records TLS plus successful client authentication, which RFC 3848 describes as the combination of the two keywords.

Does ESMTPS mean the SMTP client authenticated?

No. ESMTPS records TLS without the authentication suffix. ESMTPSA records both qualifying TLS and successful client authentication.

Is ESMTPS the same as SMTPS on port 465?

No. ESMTPS is a Received transmission-type keyword. It does not by itself identify the TCP port or say whether TLS began implicitly or through STARTTLS.

Does one ESMTPS line prove end-to-end encryption?

No. One line describes one server-to-server hop. Review every relevant trusted hop and the sending system's transport evidence.

Can an ESMTPS Received line be forged?

Yes. RFC 3848 says so itself: these keywords "are not normally protected in transport which means they can be modified by an active attacker". Rely on lines added by servers you trust and compare them with server logs when the distinction matters.

ESMTPS: What It Means in an Email Header

ESMTPS in a Received email header means the receiving server says that message hop used Extended SMTP after a successful TLS negotiation. The final S means secure transport for that hop. ESMTPA means the client authenticated, while ESMTPSA records both TLS and authentication. ESMTPS is a trace keyword, not an SMTP command, a delivery verdict, or proof that every hop from sender to recipient used TLS.

At a glance

Quick takeaways

ESMTP is SMTP used with its extension framework.
ESMTPS records ESMTP over a TLS-protected hop.
ESMTPA adds client authentication without asserting TLS.
ESMTPSA records both TLS and client authentication.
The keyword describes one transfer recorded in one Received field.
A trace line is useful only when you trust the server that added it.

Who is affected?

Anyone reading raw headers during a delivery, security, or transport investigation can encounter ESMTPS. It commonly appears after with in a Received field, beside the servers, queue identifier, recipient, and timestamp for one SMTP handoff.

The term belongs to the email infrastructure layer. It describes transport between mail systems. It does not report SPF, DKIM, or DMARC results, and it does not say whether the recipient placed the message in the inbox.

What are the requirements?

RFC 3848 registers the Received keywords

RFC 3848 registers seven new transmission types for the with clause of a Received header. The registry already held SMTP and ESMTP; these are the four ESMTP forms worth reading:

ESMTP: Extended SMTP.
ESMTPA: Extended SMTP with successful client authentication.
ESMTPS: RFC 3848's wording is ESMTP "when STARTTLS is also successfully negotiated to provide a strong transport encryption layer".
ESMTPSA: both STARTTLS and SMTP AUTH successfully negotiated, the combination of ESMTPS and ESMTPA.

These labels describe the receiving server's account of that hop. They do not replace the separate Authentication-Results field used for message-authentication methods.

ESMTP begins with EHLO and advertised extensions

RFC 5321 defines EHLO and SMTP service extensions. A client uses EHLO to identify itself and receive the server's extension list. An ESMTP trace label alone does not assert that TLS was used.

For a protocol-level introduction, see what SMTP is. The extra S in ESMTPS is the signal that narrows this particular trace to protected transport.

TLS can be negotiated with STARTTLS

RFC 3207 defines STARTTLS for SMTP. The server advertises the STARTTLS extension, the client requests it, and both sides begin a TLS negotiation. After TLS starts successfully, each side discards knowledge obtained from the earlier plaintext phase and the client sends EHLO again.

ESMTPS records the resulting protected ESMTP hop. It does not state which cipher, certificate decision, or transport policy another server used unless the header includes separate details.

A Received field covers one hop

RFC 5321 requires an SMTP server that accepts a message for relaying or delivery to insert a Received trace record. Each server adds its own line, so a multi-hop message can contain several different transmission types.

Technical exampletext

Received: from outbound.example.net (outbound.example.net [192.0.2.25])
        by mx.example.org with ESMTPS id ABC123
        for <recipient@example.org>; Tue, 25 Aug 2026 00:30:00 +0000

This is an illustrative header. It says mx.example.org recorded a TLS-protected ESMTP transfer from the named source. It does not prove that an earlier or later hop used TLS.

Map of ESMTP, ESMTPA, ESMTPS, and ESMTPSA as combinations of TLS and client authentication — Source: Palisade diagram based on RFC 3848 transmission types.

When does the requirement take effect?

RFC 3848 has registered these trace keywords since 2004. RFC 3207 defines the STARTTLS extension and RFC 5321 defines modern SMTP trace behavior. There is no mailbox-provider deadline attached to the meaning of ESMTPS.

A server can still choose a different registered transmission type or add implementation-specific comments. Read the complete field and the surrounding trace chain instead of treating the keyword as the whole investigation.

How do I implement the requirement?

1. Find ESMTPS inside a Received field

Open the raw message source and locate the Received lines. The article on what an email header is explains the difference between sender-supplied message fields and server-added trace fields.

2. Identify the server that added the line

Read the host after by. That server is asserting the transmission type for the connection it accepted. Decide whether it is part of infrastructure you trust before relying on the claim.

3. Separate TLS from client authentication

Use the exact keyword. ESMTPS includes the TLS signal but not the authentication suffix. ESMTPSA includes both. Neither one is an SPF, DKIM, or DMARC result.

4. Compare every relevant hop

Read the trace from the oldest trusted handoff upward. One ESMTPS line proves nothing about a different transfer. A message can cross a mix of protected and unprotected hops.

How do I validate compliance?

Use a controlled message sent through the production route. Export its raw source, keep the complete Received chain, and compare timestamps and hosts with the sending system's logs. Do not paste unredacted headers into a public ticket because they can contain email addresses, internal hostnames, IP addresses, and message identifiers.

The email header analyzer can structure the header for review. It cannot prove whether an untrusted trace line is truthful, inspect a TLS session that was not recorded, or guarantee that future hops will use the same transport.

Evidence