Understanding TLS Connections and Insecure Ciphers in Email Gateway Defense
Transport Layer Security (TLS) provides secure transmission of email content, both inbound and outbound, over an encrypted channel. Outdated protocols and weak ciphers present security vulnerabilities. To ensure maximum security, Email Gateway Defense (EGD) disables weak cipher suites and prioritizes modern TLS encryption.
How Email Gateway Defense Handles TLS Connections
TLS connections to EGD may originate from an EGD customer sending outbound, another EGD outbound server, or an external MX server. Connection behavior depends on domain-level TLS requirements:
Inbound Connections (Recipient Requires TLS):
If the receiving customer domain is configured to require TLS for incoming connections (excluding any custom exemptions), EGD MX servers negotiate using TLS 1.2 and only permit TLS 1.2 ciphers over the connection.Inbound Connections (Recipient Does Not Require TLS):
If the receiving customer domain does not require TLS, EGD MX servers advertise STARTTLS. If the sending server does not upgrade the connection to TLS, plain text will be accepted.Outbound Connections (Sender Requires TLS):
If a sending customer domain is configured to require TLS for outgoing connections (excluding any custom exemptions), EGD enforces that a TLS connection is used rather than plain text. (Note: This enforces the presence of TLS encryption over plaintext, but does not strictly limit outbound negotiation solely to TLS 1.2.)
Unsupported Insecure Cipher Suites
Email Gateway Defense does not support the following insecure cipher suites:
ECDHE-ECDSA-DES-CBC3-SHA
ECDHE-RSA-DES-CBC3-SHA
DHE-RSA-DES-CBC3-SHA
AES256-GCM-SHA384
AES128-GCM-SHA256
AES256-SHA256
AES256-SHA
AES128-SHA256
AES128-SHA
DES-CBC3-SHA
Troubleshooting Connection Failures
Devices or mail servers sending mail through EGD that rely on insecure ciphers or deprecated protocols may encounter handshake errors or connection failures.
Resolving Handshake Errors
Update SSL/TLS services – Ensure sending/receiving servers and client applications support TLS 1.2 or higher.
Route through a modern mail server – If legacy devices (such as scanners or multi-function printers) cannot negotiate modern TLS, route their mail through an internal relay server that supports TLS 1.2 before sending to EGD.
Microsoft Exchange Server Configuration
Inbound Connections – To disable TLS 1.0 for inbound connections on Microsoft Exchange Server, use the Receive connector in the Exchange Admin Center.
Outbound Connections – To disable TLS 1.0 for outbound connections on Microsoft Exchange Server, run the following PowerShell command:
Get-SendConnector -Identity 'SendConnectorName' | Set-SendConnector -IgnoreSTARTTLS: $trueFor guidance on updating Microsoft Exchange to support TLS 1.2, see Microsoft's article: Exchange Server TLS guidance.
Best Practices & Support
Best Practice – Configure all sending and receiving mail servers, relay devices, and clients to support TLS 1.2 or higher to maintain standard security and compliance.
If you have questions about your domain's TLS settings or need assistance troubleshooting connection issues, contact Barracuda Networks Technical Support.