Understanding TLS Connections and Insecure Ciphers in Email Gateway Defense

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: $true
  • For 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.


We value your feedback.
If you have questions, suggestions, or feedback on our documentation, contact the Campus Product Documentation team.
For general product inquiries or technical support, please contact the global Barracuda Support team.