Inbound Email Delivery Issue – STARTTLS Not Advertised by Recipient Mail Server
search cancel

Inbound Email Delivery Issue – STARTTLS Not Advertised by Recipient Mail Server

book

Article ID: 416007

calendar_today

Updated On:

Products

Email Security.cloud

Issue/Introduction

Inbound emails sent through Symantec Email Security.cloud (ESS) was temporarily delayed or stuck in the retry queue. This occurred when ESS attempted to deliver messages to the customers’ on-premise mail server but was unable to establish a secure TLS connection.

Environment

Mail Flow:

Internet → Symantec Email Security.cloud → On-Premise Mail Server

Observed Error:

During the delivery attempts, ESS reported the following error:

451 4.7.6 [internal] STARTTLS required but not advertised

This indicates that ESS attempted to initiate a secure (TLS) connection, but the recipient mail server did not advertise support for the STARTTLS command.

Cause

When Symantec Email Security.cloud tried to deliver messages to your mail server, it expected the server to advertise STARTTLS — the standard command used to initiate a secure, encrypted SMTP connection.
However, during multiple delivery attempts, the recipient mail server responded without advertising STARTTLS support. Because the ESS configuration requires TLS for delivery, messages could not be handed off and remained in the retry queue.

A TLS connectivity test confirmed that the recipient mail server was reachable but did not advertise STARTTLS. This caused the ESS service to delay delivery attempts until a secure session could be established.

 

Impact:

  • Inbound emails were delayed or queued on ESS for extended periods.
  • Senders might have experienced deferred delivery notifications.
  • No messages were lost — queued messages are retried periodically until they are delivered successfully.

Resolution

To restore normal email delivery, please review the TLS configuration on your mail server:

  1. Enable STARTTLS support for inbound SMTP connections on port 25.
    This ensures that the server can accept secure TLS sessions from ESS.

  2. Verify your SSL/TLS certificate:

    • Ensure the certificate installed on the mail server is valid and issued by a trusted Certificate Authority (CA).

    • Avoid using self-signed certificates.

    • Common trusted issuers include DigiCert, GeoTrust, and Thawte.

  3. If TLS is enforced on ESS:

    • Temporarily disable enforcement until STARTTLS is enabled on the mail server.

    • Once the TLS configuration is corrected, re-enable enforcement to maintain secure message delivery.

  4. Connectivity Verification (optional):
    You can confirm TLS support by running the following test from any external system:

openssl s_client -connect <your-mail-server>:25 -starttls smtp

The response should include “250-STARTTLS” in the EHLO output if TLS is correctly configured.

Additional Information

Once STARTTLS is enabled and a valid certificate is installed:

  • ESS will automatically detect the change.
  • Queued emails will be retried and delivered successfully.
  • Future emails will be processed securely over TLS.

This issue was caused by the recipient mail server not advertising STARTTLS, which prevented ESS from completing a secure TLS handshake.
Enabling STARTTLS and ensuring the mail server uses a valid, trusted SSL certificate will resolve the delivery delays and restore normal inbound email flow.