SMTP protocol keywords in Received headers

The word after with in a Received: line names the protocol the receiving server used for that one hop. The letters stack: ESMTP is modern SMTP, an S suffix means the connection was encrypted with STARTTLS, and an A suffix means the client logged in with SMTP AUTH. So with ESMTPS is an encrypted server-to-server hop, and with ESMTPSA is typically a person's mail app or a sending service authenticating to submit mail. None of it tells you whether the other hops were encrypted, or whether the message itself is genuine.

Where the keyword lives

RFC 5321 §4.4 defines the optional with clause of a Received: line and says the protocol names come from an IANA registry; servers are asked not to invent unregistered ones. A typical line:

Received: from mail.example.net (mail.example.net [198.51.100.23])
        by mx1.example.com with ESMTPS id 4Xb7Qm2zLp; Mon, 26 Oct 2026 09:14:07 -0400

For how the rest of the line works, see how to read Received headers.

The registered keywords

The IANA registry "Mail Transmission Types", sub-registry "WITH Protocol Types", currently lists these values (checked October 2026):

RFC 3848 §1 is where the A, S and SA suffixes were first registered, and it is specific about meaning: A means authentication succeeded, S means STARTTLS was successfully negotiated. RFC 6531 §3.7.3 says that when the SMTPUTF8 extension is used for a transaction, the with value is one of the UTF8 forms it registers (RFC 6531 §4.3). In practice these show up on mail involving internationalized (non-ASCII) addresses; how readily a given server requests the extension varies by software.

Keywords you'll see that aren't in the registry

Real headers contain plenty of values that aren't registered. Common ones:

• HTTP or HTTPREST. Some providers record that a message was submitted through a web or API front end rather than SMTP. You'll often see it on the bottom line of mail sent from a webmail interface. It is not a registered value, and the providers that use it don't publish a definition, so read it as "submitted over HTTP(S) by the provider's own software" and nothing more specific.
• Microsoft SMTP Server. Exchange and Microsoft 365 write lines like:

Received: from AM0PR02MB1234.eurprd02.prod.outlook.com (2001:db8:208:12::34)
        by DB9PR02MB5678.eurprd02.prod.outlook.com with Microsoft SMTP Server
        (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1234.5;
        Mon, 26 Oct 2026 13:14:07 +0000

The parenthesized part tells you the TLS version and cipher suite used on that hop. version=TLS1_3 and TLS1_2 are both fine today. Those outlook.com host names are typical of Microsoft's internal routing; long chains of them are normal. - with SMTP from a big provider's internal relay. Inside a data center, hops may be unencrypted or use other protection the line doesn't show. Internal behavior is the provider's business and is not documented. - with local, with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim's style), or a cipher name in a comment. Different mail servers add their own detail in parentheses. Treat these as informative comments.

Keywords are case-insensitive in practice, so esmtps and ESMTPS mean the same thing.

What TLS on a hop does and does not mean

ESMTPS means the connection between two servers was encrypted. That protects the message from anyone eavesdropping on the network between those two machines. It does not mean:

• End-to-end encryption. Each server decrypts the message, handles it in the clear, and re-encrypts it (or doesn't) for the next hop. If any hop says plain ESMTP or SMTP, that leg was not encrypted with STARTTLS.
• That the sender is genuine. A spammer's server can use TLS as easily as anyone. TLS on a hop identifies nothing about the From address.
• That the certificate was checked. Opportunistic STARTTLS between mail servers commonly accepts any certificate. Whether the receiving server validated the sender's certificate is not recorded by the keyword. (Mechanisms such as MTA-STS and DANE exist to require validation, but the with keyword won't tell you if they were applied.)
• That the keyword is accurate. RFC 3848 §3 points out that these keywords travel unprotected, can be altered by an active attacker, and shouldn't be used for filtering decisions. Lines below your provider's first inbound hop were written by the sender's side and could say anything.

RFC 5321 §7.1 makes the broader point: transport-level protections only cover one server talking to another, and real assurance about a message comes from end-to-end signatures. In practice the end-to-end checks people rely on are DKIM signatures and the results your provider records in Authentication-Results.

Reading the letters in practice

• Bottom line says ESMTPSA. Someone authenticated to their provider and submitted the message over TLS. That's the usual pattern for a person sending from a mail app or for an application sending through a relay service with a password or API key.
• Your provider's inbound line says ESMTPS. The sender's outbound server encrypted the connection to your provider. Expected for nearly all legitimate bulk and business mail today.
• Your provider's inbound line says plain ESMTP or SMTP. The message reached your provider unencrypted. That was common years ago and is unusual for major senders now. It doesn't prove anything is wrong, but it's a mild signal worth combining with the authentication results.
• Top lines say LMTP. The provider's final hand-off to the mailbox store. Normal.

Paste a header into the analyser to see every hop laid out as a timeline, then check the with value on each line using the table above.