Every time an email containing sensitive data leaves your organization, is it safe to assume it is secure? The answer is, it depends. While you might know about TLS (Transport Layer Security) – the protocol that encrypts your data – it's crucial to understand that not all encryption is created equal, particularly when it comes to email. 

That's where Opportunistic TLS and Forced TLS come in. If improving your email security is on your radar, knowing the critical distinction between these two is essential. Let's dive straight into what they are, how they work, and why the choice matters for protecting your data. 

Opportunistic TLS vs. forced TLS

A high-level overview 

Before we get into the specifics, here's a quick comparison to set the scene and help you grasp the core distinction between opportunistic TLS and forced TLS: 

What is opportunistic TLS? 

Opportunistic TLS is like agreeing to meet someone for a private conversation in a busy public place. If a private corner is available, you can have your sensitive conversation safely; however, if a quiet spot isn’t free, you'll have the conversation in the open and take the chance that you may be overheard. The communication happens, but its privacy isn't guaranteed. 

How does opportunisitc TLS work? 

In the world of email, when one email server (like your company's server) sends a message to another server (like a recipient's Gmail server), it attempts to establish a TLS-encrypted connection. This is typically done using a command called STARTTLS within the SMTP protocol. If the receiving server supports STARTTLS and the negotiation is successful, the email content is encrypted during transit. However, if the receiving server doesn't support TLS, or if an issue prevents the encryption handshake, the email will simply be sent in plain text – meaning it's unencrypted and potentially readable by anyone who intercepts it. 

Benefits and risks of opportunistic TLS: 

• High compatibility: TLS ensures that emails can be delivered to virtually any server, regardless of whether that server supports TLS or not. This prevents email delivery failures. 

• Easy setup: It's generally straightforward to enable on most email systems. 

• Better than nothing: While not perfect, it offers a baseline level of security where possible, being an improvement over sending all emails unencrypted. 

• Vulnerability to eavesdropping: If an attacker can interfere with the TLS handshake (e.g. through a downgrade attack), they can force the connection to become unencrypted without either the sender or receiver being explicitly aware. 

• No guarantee of privacy: You can't be certain that your email was encrypted during transit unless you specifically verify the mail headers after delivery. 

• "Best effort" security: It provides a "best effort" at encryption but doesn't guarantee it. 

Use cases for opportunistic TLS: 

• General email communications between unrelated domains: This is the default mode for most standard email traffic on the internet. It is likely that your personal emails often rely on opportunistic TLS. 

• Public or open web services: Where universal accessibility is prioritized over guaranteed encryption for every single connection. 

• Backwards compatibility between legacy environments: Essential for ensuring communication with older systems that may not fully support modern TLS standards. 

Examples of opportunistic TLS: 

• Sending a casual email from your personal Gmail account to a friend's Outlook.com account: the servers will try to use TLS, but if it fails, the email will still go through unencrypted. 

• Most standard inter-domain email delivery on the internet relies on Opportunistic TLS via the STARTTLS command within the SMTP protocol. 

Does Office 365 use opportunistic TLS? 

Yes, by default, M365 uses opportunistic TLS, which attempts to encrypt messages using TLS if the receiving server supports it, but will fall back to unencrypted delivery if not. However, administrators can configure Forced TLS (also known as TLS with encryption requirements) through mail flow rules or connector settings to ensure that email is only delivered if a secure TLS connection can be established—failing otherwise. This makes Forced TLS in M365 a configurable, not default, option, with the big drawback of undeliverability when TLS is not supported by the receiving server. 

Does Gmail use opportunistic TLS? 

Yes, Gmail uses Opportunistic TLS by default. When sending or receiving email, Gmail will attempt to establish a secure TLS connection with the other mail server. If the recipient’s server supports TLS, the message is encrypted in transit. However, if TLS is not supported, Gmail will deliver the message unencrypted. This approach improves email security without requiring strict configuration, but it does not guarantee encryption—making it less secure than Forced TLS in scenarios where encryption is mandatory. 

What is forced TLS? 

Forced TLS is a much stricter approach towards encryption. Forced TLS is insisting on your conversation being held in a private place; if there is no room available, the conversation simply will not happen.  

How does forced TLS work? 

Forced TLS (also known as "Strict TLS" or "Required TLS") dictates that the sending email server demands an encrypted connection with the receiving server. If the TLS handshake fails, or if the receiving server doesn't support TLS at all, the email will not be delivered. The connection is simply dropped, and the sender typically receives a bounce-back message indicating delivery failure. This ensures that the email is never transmitted in plain text. 

Forced TLS often involves pre-configured policies, sometimes called "TLS policies" or "connectors" in email systems, where you explicitly specify that communication with certain domains must use TLS. This is a common feature in services like Opportunistic TLS Office 365 configurations when setting up strict mail flow rules. 

Benefits and risks of forced TLS: 

• Maximum security: Guarantees that sensitive information is always encrypted in transit, eliminating the risk of unencrypted transmission. 

• Prevents downgrade attacks: An attacker cannot force a connection to become unencrypted. 

• Essential for compliance: Crucial for meeting stringent regulatory requirements in various industries such as HIPAA and GDPR. 

• Potential for delivery failures: If the recipient's server doesn't support the required TLS version or has configuration issues, the email won't be delivered. 

• Configuration overhead: Requires careful setup and ongoing management to ensure all target domains support and are configured for forced TLS.  

Use cases for forced TLS: 

• Healthcare (HIPAA-compliant comms): Absolutely essential for transmitting Protected Health Information (PHI) to comply with regulations like HIPAA, which mandate the security of patient data. 

• Financial institutions: Used for secure communication involving sensitive financial data, account details, and transactions to meet compliance standards like PCI DSS. 

• Government agencies: For exchanging classified or sensitive government information that requires strict confidentiality. 

• Internal corporate emails: Many organizations enforce Forced TLS between their own internal mail servers or with trusted partners to ensure all internal communications remain secure. 

• Highly sensitive B2B communication: When exchanging confidential business information between two companies that have a mutual agreement to ensure maximum security.  

Examples of forced TLS: 

• A hospital sending patient records to an insurance company, where both parties have agreed to use forced TLS for all communications between their domains. If the TLS connection cannot be established, the record is not sent. 

• A bank's email system often uses forced TLS when sending account statements or sensitive notifications, ensuring that these emails are encrypted during transit to your email provider (assuming your provider also supports the necessary TLS). 

• Companies using Microsoft 365 can set up forced TLS rules (often called "Connectors") to ensure that emails sent to or from specific partner domains must use TLS, otherwise, they are rejected. This helps ensure compliance and strong email security.  

Does Office 365 use forced TLS? 

Not by default, but it is configurable. By default, Microsoft 365 (M365) does not use forced TLS. Instead, it uses Opportunistic TLS, which attempts to encrypt email in transit if the receiving server supports it. If TLS isn’t available, messages are sent unencrypted.  

However, M365 can be configured to use forced TLS through connectors or mail flow rules. When properly set up, forced TLS in M365 ensures that email is only sent if a secure TLS connection can be established—otherwise, delivery fails. In short, forced TLS is a configurable option, not the default behavior. 

Does Gmail use forced TLS? 

Gmail does not use Forced TLS by default. Gmail relies on opportunistic TLS, meaning it will attempt to encrypt email in transit if the receiving server supports TLS; if TLS is not availabile, the message is delivered unencrypted.   

While Google does support enforcing TLS for specific domains using Gmail’s advanced settings (primarily in Google Workspace), forced TLS is not the default behavior and must be explicitly configured. Additionally, when TLS is not supported and forced TLS is setup, the alternative is that messages will not be sent, which is a problem that Zivver's secure email solution can overcome. 

Do I need forced TLS? 

Both opportunistic TLS and forced TLS play roles in email security. However, for organizations dealing with sensitive data and compliance requirements, Forced TLS is the clear winner because it provides a guarantee of encryption during transit. While opportunistic TLS offers a "best effort" approach, it doesn't eliminate the risk of unencrypted transmission if the conditions aren't met; with traditional email solutions, if the recipient’s server does not support TLS, your message cannot be sent.  

For truly robust email security that goes beyond the basic capabilities of TLS, a dedicated email encryption solution such as Zivver enhances email clients such as Microsoft 365 and Gmail with advanced encryption protocols, ensuring that sensitive emails are protected and can be read in a secure web portal, protected by strong 2FA. In addition to advanced encryption, Zivver protects sensitive emails further with user-friendly data loss prevention features, helping to prevent human error – all crucial elements for safeguarding your information. 

Ready to take your email encryption and data protection to the next level? Discover how Zivver can enhance your email security. 

Frequently Asked Questions (FAQs) about transport layer security:

Q1: What is the main difference between opportunistic TLS and forced TLS? 

A1: The main difference is whether encryption is mandatory. Opportunistic TLS attempts encryption but will send the email unencrypted if TLS fails. Forced TLS requires encryption; if TLS cannot be established, the email will not be sent at all. 

Q2: When should I use forced TLS? 

A2: You should use Forced TLS when transmitting sensitive data, such as patient records (HIPAA compliance), financial information, government communications, or internal corporate emails where guaranteed encryption is critical to meet security and compliance requirements. 

Q3: Does Microsoft 365 support opportunistic TLS and forced TLS? 

A3: Yes, Microsoft 365 supports both. By default, Opportunistic TLS is used for outbound email. However, administrators can configure mail flow rules (connectors) to enforce Forced TLS for specific domains or partners, ensuring a higher level of security for those communications. 

Q4: Is opportunistic TLS secure enough for my business emails? 

A4: For general, non-sensitive business emails, Opportunistic TLS offers some protection. However, for sensitive data, confidential information, or anything requiring regulatory compliance, it is generally not secure enough due to its fallback to unencrypted communication. For these scenarios, Forced TLS or a dedicated email encryption solution is recommended. 

Q5: What are the risks of using opportunistic TLS for email? 

A5: The primary risk of Opportunistic TLS is that an attacker could potentially downgrade or interfere with the TLS handshake, forcing the email to be sent in plain text without the sender or recipient knowing. This makes the content vulnerable to eavesdropping and interception.