# ESMTPS: What It Means in an Email Header

> ESMTPS in an email header means ESMTP crossed a TLS-protected hop. Learn how it differs from ESMTP, ESMTPSA, STARTTLS, and implicit TLS connections.

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.

## 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](/learning/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](https://www.rfc-editor.org/rfc/rfc3848.html#section-1). 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](https://www.rfc-editor.org/rfc/rfc5321.html#section-2.2). 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](/learning/what-is-smtp). 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](https://www.rfc-editor.org/rfc/rfc3207.html). 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](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.4). Each server adds its own line, so a multi-hop message can contain several different transmission types.

```text
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](/images/editorial/esmtps/esmtps-transmission-types.svg "1200x676")

*Source: Palisade diagram based on [RFC 3848 transmission types](https://www.rfc-editor.org/rfc/rfc3848.html#section-1).*

## 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](/learning/what-is-an-email-header) 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](/tools/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.

## Sources and further reading

- [RFC 3848: ESMTP and LMTP Transmission Types Registration](https://www.rfc-editor.org/rfc/rfc3848.html)
- [RFC 3207: SMTP Service Extension for Secure SMTP over TLS](https://www.rfc-editor.org/rfc/rfc3207.html)
- [RFC 5321: Simple Mail Transfer Protocol](https://www.rfc-editor.org/rfc/rfc5321.html)
- [Secure email server standards](/learning/secure-email-server)

## Frequently asked questions

### 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"](https://www.rfc-editor.org/rfc/rfc3848.html#section-3). Rely on lines added by servers you trust and compare them with server logs when the distinction matters.