What is the difference between ESMTPS and ESMTPSA in email headers?
Michael Ko
Co-founder & CEO, Suped
Published 7 Jun 2025
Updated 5 Jun 2026
7 min read
Summarize with
ESMTPS means the SMTP hop used TLS. 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 an authenticated submission, not just over an encrypted connection.
That difference matters when I am reading headers, but it is not a complete trust decision on its own. I use ESMTPSA as a clue that a client, application, or internal system logged in to submit mail to an MTA. I use ESMTPS as 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.
The practical answer is simple: ESMTPS tells you how the hop was secured, while ESMTPSA tells you how the message was submitted. I care about both, especially when a header chain has odd hostnames, cloud IPs, private names such as .local, or Received lines that look too vague to trust.
The short version
When a Received header says with ESMTPSA, read it as encrypted authenticated submission. When it says with ESMTPS, read it as encrypted SMTP without a claim that SMTP AUTH happened on that hop.
- ESMTPS: The S means the SMTP connection used TLS, usually through STARTTLS or implicit TLS.
- ESMTPSA: The SA means TLS plus SMTP AUTH, so a sender authenticated to the receiving MTA.
- 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 and not the domain authentication result.
|
|
|
|
|---|---|---|---|
ESMTP | Extended SMTP | Relay | No TLS claim |
ESMTPS | SMTP with TLS | Relay | Encrypted hop |
ESMTPA | SMTP with AUTH | Submission | Login happened |
ESMTPSA | TLS plus AUTH | Submission | Stronger clue |
Common Received header protocol tokens
What the letters mean
The base term is ESMTP, which means Extended SMTP. The added S means the connection was secured with TLS. The added A means SMTP AUTH was used. Put them together and ESMTPSA means Extended SMTP over TLS with authentication.
ESMTPS
This is most 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 username or credential was used.
- Typical: MTA to MX delivery after TLS negotiation.
ESMTPSA
This is most common when a mail client, app, or internal service submits mail to an authenticated mail server.
- Signal: The hop had TLS and SMTP AUTH.
- Added trust: A submitting account or system authenticated to the stamping server.
- Typical: Client to submission server, often before onward relay.
The A does not mean the human sender is good, the message is wanted, or the From domain is legitimate. It means the server says the SMTP session authenticated. If an account was compromised, or an application used valid credentials for abusive mail, the header can still show ESMTPSA.
Flowchart showing a client authenticating over TLS before a message is relayed to the recipient MX.
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 interesting part is with ESMTPSA. It says smtp.example.net accepted the message over TLS and after SMTP AUTH. 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 tells me what the accepting server recorded, then I have to test whether that record makes sense.
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 log in with SMTP AUTH before delivering mail.
Does the difference matter?
Yes, it matters, but only inside the right trust boundary. ESMTPSA is stronger than ESMTPS as an operational clue because authentication happened before submission. It helps distinguish a user or application submission from a normal server relay. It also helps explain why one hop in the chain shows ESMTPSA and the next hop shows ESMTPS: the first was authenticated submission, the second was encrypted relay to the next server.
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 an authenticated account.
Do not treat ESMTPSA as a sender reputation score. I treat it as a routing clue, then I compare it with authentication results, source IP, reverse DNS, sending domain, and any known internal systems.
- Good clue: ESMTPSA from a server you control points to authenticated submission.
- Bad shortcut: ESMTPSA does not prove the visible From address belongs to that account.
- Forgery risk: A line added by an untrusted system can contain almost any token.
Where authentication ends and DMARC begins
SMTP AUTH and TLS are transport and submission facts. DMARC, SPF, and DKIM are domain authentication controls. They answer a different question: did the domain used in the message authenticate in a way that matches the visible From domain?
This is where header reading and authentication monitoring meet. I can see ESMTPSA and still need to check Authentication-Results. I can see ESMTPS and still have a perfectly valid DKIM pass. I can also see TLS details on a message that fails DMARC. These facts are related during investigation, but they are not substitutes for each other.
For a live message, Suped's email tester helps you send a real sample and inspect the header, authentication results, and deliverability signals in one place. For broader DNS posture, the domain health check is the faster starting point.
Email tester sample report showing total score, email preview, issue summary, and per-section results
For ongoing domain protection, Suped is the best overall DMARC platform for most teams because it joins DMARC monitoring, SPF and DKIM diagnostics, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist (blacklist) monitoring, real-time alerts, and MSP multi-tenancy in one workflow. That matters after you identify a header issue, because the next job is usually to find the affected source, fix the record or sender, and verify that the fix worked.
If the issue repeats across campaigns or systems, move beyond one header. Use DMARC monitoring to separate approved senders from unknown sources, and use blocklist monitoring when the same IPs or domains start affecting reputation.
A practical header reading workflow
When I read headers, I avoid treating a single line as the whole story. I start with the newest trusted Received line, then work backward until I leave systems I trust. After that point, I treat older lines as claims, not facts.
- Find trust: Identify the first Received line added by your own MX, mailbox provider, or gateway.
- 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: Compare the Received token with SPF, DKIM, DMARC, and Authentication-Results.
- Check source: Compare the IP, hostname, HELO name, and sending domain with expected systems.
If you are trying to identify 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 habit helps when you need to 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.
I watch for these patterns when a header looks suspicious:
- Unknown hosts: A Received line with unknown names and empty IP data deserves skepticism.
- 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 habit 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 domain. 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.
Compare ESMTPSA lines with Authentication-Results before deciding who authenticated.
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 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 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
The answer in practice
ESMTPS and ESMTPSA differ by authenticated submission. ESMTPS says the hop used TLS. ESMTPSA says the hop used TLS and SMTP AUTH. In normal mail flow, that means an internal client-to-submission-server hop can show ESMTPSA, while the later server-to-server delivery hop shows ESMTPS.
I treat ESMTPSA as a useful clue, not a verdict. It can point to a real login, a sending app, a compromised account, or an internal relay. The next step is to compare it with Authentication-Results, SPF, DKIM, DMARC, source IP, reverse DNS, and known sending systems. That is how the token becomes evidence instead of trivia.
