What is the primary difference between ESMTPS and ESMTPSA?

ESMTPS means the email was transferred using Extended SMTP with a secure TLS connection . ESMTPSA means it used ESMTP with both TLS encryption and SMTP authentication, providing an additional layer of sender verification.

Is ESMTPSA better than ESMTPS for email deliverability?

Yes, both are good. ESMTPS shows encryption, which is crucial for privacy. ESMTPSA adds authentication, which can enhance trust, particularly for the first hop of an email. While both contribute positively, ESMTPSA offers a stronger signal of legitimacy.

How can I check if my emails are being sent with ESMTPS or ESMTPSA?

You can find these in the Received header within the full email source. Look for the 'with' clause, which will specify the protocol type used for that particular hop in the email's journey.

Does the lack of ESMTPS or ESMTPSA impact email deliverability?

Yes, the absence of encryption (TLS) can negatively affect deliverability. Many major email providers prioritize and expect encrypted connections. Emails sent without TLS may be viewed with suspicion, potentially leading to delivery to spam folders or even outright rejection.

What is the difference between ESMTPS and ESMTPSA in email headers? - Technical - Email deliverability - Knowledge base

When you look at the raw source of an email, you'll often see a series of email headers. These headers provide a detailed log of the email's journey from sender to recipient, much like a postmark on a physical letter. One of the most informative lines in these headers is the Received header, which chronicles each server an email passed through.

Within these Received lines, you might notice acronyms like ESMTPS and ESMTPSA. These terms indicate how the email was transmitted between servers and the security measures employed during that transfer. Understanding their differences is crucial for email deliverability, as it sheds light on whether your messages are being sent securely and authenticated, which can impact inbox placement and sender reputation.

Understanding ESMTPS

ESMTPS and ESMTPSA are extensions of ESMTP (Extended Simple Mail Transfer Protocol), which is the standard protocol for sending email over the internet. ESMTP itself is an enhancement of the basic SMTP, adding capabilities like larger message sizes, better error handling, and most importantly for this discussion, support for service extensions.

The 'S' in ESMTPS stands for STARTTLS. This indicates that the email transfer occurred over a secure TLS (Transport Layer Security) connection. TLS encrypts the communication channel between two mail servers, protecting the email content from eavesdropping and tampering during transit. When you see ESMTPS in a Received header, it means that the server receiving the email successfully negotiated a TLS encryption layer with the sending server. This is a fundamental security practice for modern email.

Securing email in transit with TLS is paramount for maintaining privacy and preventing unauthorized access. Without TLS encryption, email messages are transmitted as plain text, making them vulnerable to interception. This is why mail servers prioritize encrypted connections, and the presence of ESMTPS is a positive sign for email security.

The significance of ESMTPSA

The distinction becomes clearer when we introduce the 'A' in ESMTPSA. This 'A' stands for AUTH, indicating that the email transfer not only occurred over a secure TLS connection but also involved SMTP Authentication. SMTP AUTH is a mechanism where the sending client or server authenticates itself to the receiving mail server using a username and password (or other credentials) before transmitting the email. This is typically how your email client (like Outlook or Gmail) sends emails through your provider's outgoing mail server.

ESMTPSA implies a higher level of trust. When a server reports ESMTPSA, it's not just saying that the connection was encrypted, but also that the sender was verified. This is especially relevant for the first hop of an email, when a user's mail client connects to their outgoing mail server, or when an application sends email via a dedicated SMTP service. It signifies that the sender had legitimate access to send mail through that particular server.

The RFC 3848, which registers these mail transmission types, defines ESMTPSA as the use of ESMTP when both STARTTLS and SMTP AUTH are successfully negotiated. This combination provides a robust layer of both transport encryption and sender verification, contributing significantly to the overall security and legitimacy of the email flow. For inbound email, knowing that a message came via an authenticated TLS connection can influence spam filters and reputation systems, often in a positive way.

Why the distinction matters for deliverability

Understanding ESMTPS and ESMTPSA is crucial for email administrators and marketers focused on deliverability and security. Here's a quick comparison:

ESMTPS

Encryption: Indicates that the connection between two mail servers was encrypted using TLS, ensuring the privacy of the email content in transit.
Authentication: Does not explicitly state that the sending client or server authenticated itself to the receiving server. This is common for server-to-server transfers.
Use Case: Primarily seen in later hops of an email's journey, where one mail transfer agent (MTA) relays the email to another MTA securely.

ESMTPSA

Encryption: Also indicates a secure TLS encrypted connection, just like ESMTPS.
Authentication: Additionally signifies that the sending party authenticated itself using SMTP AUTH.
Use Case: Commonly seen when an email client or an authorized application sends an email to the first mail server (the submission server). This provides an additional layer of trust and accountability.

For email deliverability, the presence of either ESMTPS or ESMTPSA is generally a good sign. It indicates that your messages are being transmitted securely, reducing the chances of them being flagged as suspicious or spam. Modern mail servers, like those run by

Google and

Microsoft, prefer and often require encrypted connections, and emails lacking this can face deliverability challenges, even ending up on a blocklist (or blacklist).

The RFC 3848 and other IANA mail parameters further define these and other transmission types, ensuring a standardized way to interpret email headers across various systems. The presence of ESMTPSA is particularly beneficial for the initial submission of an email, as it confirms both encryption and authentication, building a stronger trust signal from the very first hop.

Analyzing received headers and other protocol types

You'll find ESMTPS and ESMTPSA in the Received header, specifically in the 'with' clause. This clause specifies the protocol used for the transfer. Here's an example of what these headers might look like:

Example ESMTPS headertext

Received: from mail.example.com (mail.example.com [192.0.2.1])
        by mx.recipient.com with ESMTPS id abc123def456;
        Tue, 23 Jan 2024 10:00:00 +0000 (GMT)

Example ESMTPSA headertext

Received: from [198.51.100.10] (host.sender.org [198.51.100.10])
        by smtp.provider.com with ESMTPSA id ghi789jkl012;
        Tue, 23 Jan 2024 09:55:00 -0500 (EST)

The interpretation is straightforward: if you see ESMTPS, the connection was encrypted. If you see ESMTPSA, the connection was both encrypted and authenticated. When troubleshooting email issues, inspecting these headers can quickly reveal if there are any issues with your TLS configuration or authentication setup, which are critical for deliverability.

These are not the only protocol types, as the email ecosystem has evolved to include various methods of transmission. Here's a brief overview of other common types you might encounter:

Protocol Type	Description
ESMTP	Extended Simple Mail Transfer Protocol, providing basic mail transfer without specified encryption or authentication.
ESMTPS	ESMTP with STARTTLS, meaning the session was encrypted using Transport Layer Security.
ESMTPA	ESMTP with AUTH, indicating the sender authenticated to the server, but without guaranteed TLS encryption.
ESMTPSA	ESMTP with STARTTLS and AUTH, combining both encryption and authentication.
LMTP	Local Mail Transfer Protocol, used for delivery between systems, often to a local mailbox delivery agent.

Conclusion

In the complex world of email deliverability, every detail in the headers can provide valuable insights. ESMTPS and ESMTPSA serve as important indicators of the security and authenticity of email transmissions. By understanding these nuances, you gain a clearer picture of how your emails are being handled, which is essential for ensuring they reach the inbox safely and reliably.

Views from the trenches

Best practices

Always prioritize setting up TLS encryption for all email sending, as it's a baseline expectation for good deliverability.

Ensure your email sending processes, especially for outbound mail, include SMTP authentication.

Regularly review your email headers, particularly the Received lines, to verify secure and authenticated transmission.

Implement DMARC, SPF, and DKIM to further strengthen email authentication and prevent spoofing.

Common pitfalls

Overlooking warnings about weak TLS versions or cipher suites in email logs or DMARC reports.

Sending emails from systems that do not authenticate, which can reduce sender trustworthiness.

Ignoring generic 'Received' headers without proper hostnames or IP addresses, as they may indicate issues.

Not configuring authentication for internal email relays or application-sent emails.

Expert tips

Use email deliverability tools to automatically parse headers and highlight potential security or authentication issues.

For transactional emails, ensure the initial connection uses ESMTPSA for maximum trust with recipient mail servers.

Pay attention to the sequence of Received headers, as they tell the full story of an email's path.

A mismatch between the stated 'with' protocol and actual transport security can be a red flag for spam filters.

Marketer view

Marketer from Email Geeks says they cringe at Received headers that show 'unknown' hosts and empty brackets, as they provide no useful information for tracing the email's origin.

2024-03-27 - Email Geeks

Marketer view

Marketer from Email Geeks says they encountered a suspicious Received header where a 'Mac-Pro.local' hostname was associated with an AWS EC2 IP address, indicating a potentially forged or misconfigured header.

2024-03-27 - Email Geeks