What is the difference between ESMTPS and ESMTPSA in email headers?
Updated on 21 Oct 2026: We clarified ESMTPS and ESMTPSA header interpretation and added steps to find full headers and verify authenticated accounts.
ESMTPS means the SMTP hop used TLS (Transport Layer Security). ESMTPSA means the SMTP hop used TLS and SMTP AUTH. The extra A is the important part: it says the server that wrote that Received header accepted the message after successful SMTP authentication in addition to using an encrypted connection.
That difference matters when reading headers, but it is not a complete trust decision on its own. ESMTPSA is a clue that a client, application, or SMTP system authenticated before handing mail to the receiving mail transfer agent (MTA). ESMTPS is a clue that the transport was encrypted between two SMTP systems. Neither token proves that SPF, DKIM, or DMARC passed, and neither token proves the visible From domain was authorized.
ESMTPS vs ESMTPSA at a glance
When a Received header says with ESMTPSA, read it as encrypted ESMTP with successful SMTP authentication. When it says with ESMTPS, read it as encrypted ESMTP without a claim that SMTP AUTH succeeded on that hop.
- ESMTPS: The S records encrypted ESMTP. RFC 3848 defines it around successful STARTTLS.
- ESMTPSA: The extra A adds successful SMTP AUTH to the encrypted ESMTP session.
- Trust: Only trust the token if you trust the server that added that Received line.
- Scope: These tokens describe one hop, not the full path or the domain authentication result.
|
|
|
|
|---|---|---|---|
ESMTP | Extended SMTP | Relay | No TLS or AUTH claim |
ESMTPS | ESMTP with TLS | Relay | Encrypted hop |
ESMTPA | ESMTP with AUTH | Authenticated SMTP | AUTH claim; no TLS claim |
ESMTPSA | TLS plus AUTH | Authenticated SMTP | TLS and AUTH claim |
Common Received header protocol tokens
ESMTPS without A does not report an AUTH failure. Header conventions vary, so check the accepting server's logs when a token is unexpected. RFC 4954 recommends ESMTPA or ESMTPSA after successful authentication. An ESMTP or ESMTPA label alone is not conclusive evidence that TLS was absent.
What the letters mean
ESMTP means Extended Simple Mail Transfer Protocol. RFC 3848 registered protocol types for the with clause of a Received field. Its formal definitions use S for successful STARTTLS and A for successful SMTP authentication. In real-world headers, S is also used by some MTAs for an ESMTP session secured through TLS on connect. Put them together and ESMTPSA records encrypted ESMTP with successful SMTP AUTH.
ESMTPS
This is common when one SMTP server hands mail to another SMTP server over TLS.
- Signal: The transport channel was encrypted for that hop.
- Missing: The token does not say an SMTP identity authenticated.
- Typical: MTA to MX delivery after TLS negotiation.
ESMTPSA
This is common when a mail client, app, or SMTP system authenticates to the server accepting the message.
- Signal: The hop had TLS and successful SMTP AUTH.
- Identity scope: An SMTP identity authenticated to the stamping server.
- Typical: Client submission or another authenticated SMTP handoff.
The A does not mean the human sender is safe, the message is wanted, or the From domain is legitimate. It means the server says the SMTP session authenticated successfully. If an account was compromised, or an application used valid credentials for abusive mail, the header can still show ESMTPSA.
The S describes hop-by-hop transport encryption, not end-to-end encryption of the message body. With only transport TLS, each SMTP system handling the message can process its plaintext contents. The token does not report whether the peer certificate was validated or TLS was required. End-to-end protection requires a message-level encryption method rather than a Received-header protocol token.
The token also does not identify a port. Some MTAs use S for STARTTLS and for TLS on connect, so ESMTPSA alone does not distinguish STARTTLS on port 587 from implicit TLS on port 465. Check explicit TLS details and the trusted server's configuration when that distinction matters.
ESMTPSA email submission using TLS and SMTP AUTH, followed by relay to the recipient MX.
How to find ESMTPS and ESMTPSA in full headers
Open the message's full email headers to see its Received fields. The steps depend on the mail client:
- Gmail in a browser: Open the message, select More beside Reply, then Show original. See Gmail's header instructions.
- New Outlook: Open the message, select More actions, then View > View message details. See Microsoft's header instructions.
- Classic Outlook for Windows: Open the message in its own window, select File > Properties, then copy the Internet headers box. See Microsoft's classic Outlook steps.
- Find the token: Search the header text for with ESMTPSA or with ESMTPS. Check the server named after by to identify which server recorded that hop.
Keep the complete original header block for investigation, including folded continuation lines and timestamps. A normal forwarded message adds another delivery path, so inspect the original message when investigating its route.
How to read it in a Received header
A Received header records the server that accepted a message, the server or client it accepted it from, the protocol token, optional TLS details, and a timestamp. Each receiving server adds its own Received line at the top, so the oldest hop is usually near the bottom of the header block.
Example of ESMTPSA in a Received headertext
Received: from Mac-Pro.local (ec2-35-172-110-93.compute-1.amazonaws.com [35.172.110.93]) by smtp.example.net with ESMTPSA id abc123 for <recipient@example.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 05:14:35 -0700
In that example, the important part is with ESMTPSA. It says smtp.example.net accepted the message after TLS and successful SMTP authentication. The Mac-Pro.local name is not proof of a Mac on a desk, and the cloud hostname is not proof of a legitimate sender. The header shows what the accepting server recorded, which must then be checked against the rest of the trusted chain.
Example of ESMTPS in a Received headertext
Received: from mail.example.net (mail.example.net [203.0.113.10]) by mx.example.org with ESMTPS id mx42 for <user@example.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Mar 2024 14:22:49 +0000
In this second example, the accepting MX says the previous mail server used TLS. There is no claim of SMTP AUTH. That fits normal server-to-server delivery. A receiving MX normally does not ask every outside sender to authenticate with SMTP AUTH before delivering mail.
How ESMTPS and ESMTPSA affect deliverability
Within a trusted Received line, ESMTPSA records that SMTP authentication succeeded on that session. It often distinguishes a user or application submission from a normal unauthenticated server relay. It also helps explain why one hop in the chain shows ESMTPSA and the next shows ESMTPS: the first was an authenticated handoff, while the second was an encrypted relay without an AUTH claim. ESMTPS on an ordinary relay hop is expected; ESMTPSA is not an inbox-placement guarantee.
How much trust to give the token
The same token has different value depending on who added the Received line.
Low
Untrusted chain
A Received line below your trust boundary can be forged or rewritten before delivery.
Medium
Known relay
A known relay gives useful transport context but still needs authentication results.
Higher
Trusted MSA
An ESMTPSA line from your own submission system points to a successfully authenticated session.
Do not treat ESMTPSA as a sender reputation score. Treat it as a session and routing clue, then compare it with authentication results, source IP, reverse DNS, sending domain, and known internal systems. Avoid allowlist or spam-filter rules based on the token alone, as RFC 3848's security guidance explains.
- Useful clue: ESMTPSA from a server you control points to successful SMTP authentication.
- Bad shortcut: ESMTPSA does not prove the visible From address belongs to that SMTP identity.
- Forgery risk: A line added by an untrusted system can contain almost any token.
SMTP AUTH vs SPF, DKIM and DMARC
SMTP AUTH authenticates an SMTP client to a server, while TLS encrypts the connection. SPF checks whether the connecting IP is authorized for the envelope sender domain. DKIM checks a domain's signature. DMARC requires a passing SPF or DKIM result with the required domain relationship to the visible From domain.
Compare an ESMTPSA hop with Authentication-Results added by a trusted receiving system. An ESMTPS hop can still have a valid DKIM pass, and TLS details can appear on a message that fails DMARC. These facts are related during investigation, but they are not substitutes for each other.
ESMTPSA does not reveal the authenticated account. A submission server can publish auth=pass smtp.auth=sender@example.net in Authentication-Results to report its SMTP authorization identity, as defined in RFC 8601. If that result is absent, use the Received queue ID and timestamp to locate the session in the accepting server's logs. The account identity is separate from the visible From address.
For a live message, send a new sample through your usual mail client or application to Suped's email tester. Its report checks the delivered message's headers and authentication results, including TLS on the connection to Suped. Use the domain health check to inspect your published authentication DNS.
Email tester sample report showing total score, email preview, issue summary, and per-section results
For recurring failures across campaigns or systems, use Suped's DMARC monitoring to compare SPF and DKIM results by sending source and verify changes in subsequent aggregate reports. These reports do not identify the SMTP account or show every hop's TLS session.
A practical header reading workflow
Avoid treating a single line as the whole story. Start with the newest trusted Received line, then work backward until the chain leaves systems you trust. After that point, treat older lines as claims, not facts.
- Find trust: Identify the newest Received line added by your own MX, trusted mailbox provider, or gateway, and note its by server.
- Read tokens: Note whether that trusted hop says ESMTP, ESMTPS, ESMTPA, or ESMTPSA.
- Check TLS: Look for version, cipher, and bits details when the header includes them.
- Check auth: Read SPF, DKIM and DMARC in trusted Authentication-Results; use the submission server's logs to identify the SMTP account.
- Check source: Compare the IP, hostname, EHLO/HELO name, and sending domain with expected systems.
When identifying the system behind a message, the Received chain, DKIM selector, return path, and Message-ID often provide better clues together than any one field alone. The same method helps determine the sending platform or inspect Gmail authentication headers.
Common mistakes
The most common mistake is giving the protocol token more authority than it has. ESMTPSA is useful, but the server that stamped it can be wrong, compromised, misconfigured, or outside your trust boundary. ESMTPS is useful, but encryption does not say anything about sender permission.
Watch for these patterns when a header looks suspicious:
- Unknown hosts: Missing IP details can occur on internal handoffs; check the trusted relay's logs before treating them as evidence of abuse.
- Private names: A .local hostname on a cloud IP is a clue to verify, not a conclusion.
- Wrong boundary: A forged lower Received line can copy legitimate-looking TLS and AUTH language.
- Mixed facts: SMTP AUTH, DKIM signing, and DMARC domain checks answer different questions.
A clean header reading method keeps those facts separate. ESMTPSA answers whether authenticated SMTP was used on that hop. DKIM answers whether a domain signed the message and whether the signature survived. SPF answers whether the connecting IP was authorized for the envelope sender domain, or the HELO domain when the envelope sender is empty. DMARC answers whether SPF or DKIM passed with the required domain relationship to the visible From domain.
Views from the trenches
Best practices
Read Received headers from the trusted edge first, then work backward through each added hop.
Use trusted SMTP AUTH results or submission logs to identify the authenticated account.
Keep raw headers intact when sharing examples, because mail clients often reorder display views.
Common pitfalls
Trusting every old Received line just because it contains TLS version details causes errors.
Confusing SMTP AUTH with DKIM signing hides whether the visible From domain was authorized.
Chasing the hostname string before checking IP, rDNS, SPF, DKIM, and DMARC wastes time.
Expert tips
Use ESMTPSA as a submission clue, then look for account compromise or relay misuse signals.
Flag .local hostnames on cloud IPs for review, but verify against the full delivery path.
Build header annotations that show the protocol token and the trust boundary together.
Marketer view
Marketer from Email Geeks says ESMTPS indicates TLS was used, while ESMTPSA indicates TLS plus SMTP AUTH on that hop.
2024-03-27 - Email Geeks
Marketer view
Marketer from Email Geeks says ESMTPSA has more value when the stamping server is trusted because someone authenticated to submit the message.
2024-03-27 - Email Geeks
