Does using TLS matter for email deliverability or inbox placement?

Key findings

• Privacy and security: TLS is primarily a security measure, protecting email content during transmission. It encrypts the data to prevent unauthorized access or modification.
• Indirect deliverability factor: While a lack of TLS encryption does not typically result in immediate email blocking, it can be viewed as a negative signal by mailbox providers. This is because modern email security standards increasingly favor encrypted communication.
• Industry standard: Most major mailbox providers, including Gmail, transmit a vast majority of their email via TLS. Failing to use TLS makes a sender an outlier, which could be seen negatively over time. Google's own transparency report indicates high rates of TLS adoption for inbound and outbound email, illustrating the prevailing standard. You can explore these trends on the Google transparency report.
• Future implications: Although not a strict deliverability requirement for all mailboxes today, the trend is towards greater security. Mailbox providers may implement stricter policies regarding TLS encryption in the future, similar to how HTTPS became a ranking factor for websites.

Key considerations

• Opportunistic TLS: For email, TLS is often opportunistic. This means if a secure connection cannot be established, the email might still be sent in plain text. This differs from web traffic (HTTPS) where a secure connection is typically mandatory, or the connection fails. However, relying on plain text should be avoided.
• Minimum effort, maximum gain: Implementing TLS (specifically TLS 1.2 or 1.3) is generally considered a low-effort task for most modern Mail Transfer Agents (MTAs) and email service providers. The security and reputational benefits far outweigh the minimal configuration required. For detailed steps on configuration, see our guide on configuring SSL or TLS on sending domains.
• User perception: Some email clients (like Gmail) display visual cues (e.g., a red padlock) when an email is not encrypted. This can alarm recipients and potentially reduce trust in your brand.
• Overall security posture: Adopting modern TLS versions is part of a broader commitment to email security, alongside authentication protocols like SPF, DKIM, and DMARC. Neglecting basic security measures can indicate larger underlying issues that may impact your email deliverability over time.

Key opinions

• No direct deliverability boost: Many marketers believe that TLS itself doesn't directly improve inbox placement rates, but its absence can certainly create issues.
• Table stakes for professional senders: Despite the lack of direct deliverability impact, TLS is considered a basic requirement for any reputable email service provider (ESP) or high-volume sender. It is a sign of a well-configured email system, demonstrating adherence to modern email practices.
• Avoiding warning signs: The primary perceived benefit for marketers is avoiding red locks or encryption warnings in Gmail, which can erode recipient trust.
• IPv6 considerations: Some marketers note that if you're sending over IPv6, TLS becomes even more critical for successful delivery, hinting at specific technical scenarios where it has a more direct role.

Key considerations

• User experience matters: While a lack of TLS might not send your email to spam, an unencrypted email that displays a warning can negatively impact how recipients perceive your brand and interact with your emails, potentially affecting future engagement rates (which do impact deliverability).
• Low effort implementation: Given the ease of enabling opportunistic TLS, marketers generally agree there's no reason not to implement it. It's a quick win for security and perception.
• Consistency and reliability: Consistent TLS encryption rates indicate a reliable sending infrastructure. Sporadic TLS encryption rates could signal underlying issues.
• Holistic approach: Inbox placement depends on a multitude of factors. While TLS is important for security, marketers should continue to prioritize core deliverability strategies such as list quality, content relevance, and engagement. Learn more about improving your inbox placement from Mailmodo.

Key opinions

• Evolving signal: Experts widely believe that mailbox providers likely use TLS encryption data as a signal, even if it's not a direct filter today. Being an outlier in TLS adoption (not using it) could negatively impact sender reputation over time.
• Deprecate older versions: There's a strong consensus to disable older, insecure TLS versions like TLSv1 and TLSv1.1, and certainly SSLv2/v3. Focus should be on TLSv1.2 and TLSv1.3.
• Security vs. deliverability tradeoff: A key discussion point is whether to fall back to plain text if TLSv1.2/1.3 negotiation fails. Some experts advocate for this to ensure delivery, while others argue that sending in plain text or older TLS versions provides a false sense of security.
• Beyond opportunistic TLS: Forward-thinking experts suggest considering advanced protocols like MTA-STS and DANE for outbound mail, which enforce TLS and prevent downgrade attacks, reinforcing the importance of outbound TLS for email marketing.

Key considerations

• Modern infrastructure: If a sender's Mail Transfer Agent (MTA) or email system cannot properly support TLSv1.2 (released in 2008) or TLSv1.3, it signals deeper, systemic security issues that extend beyond just email encryption.
• Security theater: Using outdated TLS versions like 1.0 or 1.1 is akin to security theater, offering minimal real protection and potentially giving a false sense of security.
• Sender confidence: Implementing strong TLS protocols contributes to sender confidence and validates your commitment to secure email practices with mailbox providers.
• Industry best practices: Adhering to the latest TLS standards (1.2/1.3) aligns with broader internet security trends and sets a high bar for secure email transmission. LuxSci provides comprehensive information on how to secure SMTP email delivery with TLS.

Key findings

• Deprecation of older TLS: The IETF (Internet Engineering Task Force) has deprecated TLSv1.0 and TLSv1.1, indicating they are no longer considered secure for any application, including email. Current recommendations are to use TLSv1.2 or TLSv1.3.
• Government directives: Agencies like CISA issue directives that mandate the use of STARTTLS for government email systems, emphasizing the importance of encrypting data in transit, even if they don't always specify the minimum TLS version for email (unlike web traffic). You can review the CISA Binding Operational Directive 18-01.
• NIST guidance: NIST (National Institute of Standards and Technology) provides detailed publications, such as SP 800-52r2, which recommend robust TLS configurations for government systems, generally favoring TLSv1.2 and later. These guidelines often extend to broader industry best practices.
• Security vs. Compatibility: While some older systems may only support TLSv1.1, documentation suggests prioritizing the security of TLSv1.2/1.3. Falling back to cleartext or outdated TLS versions means sacrificing security for compatibility, which is generally discouraged for sensitive communications.

Key considerations

• Holistic authentication: TLS complements email authentication standards like SPF, DKIM, and DMARC by securing the transport layer. For a comprehensive overview of these protocols, refer to our simple guide to DMARC, SPF, and DKIM.
• Impact on trust: From a security perspective, using deprecated or no TLS degrades the trust in the communication channel, making it vulnerable to various attacks like passive sniffing or downgrade attacks.
• Future-proofing: Adopting TLSv1.2/1.3 and protocols like MTA-STS ensures compliance with future security mandates and positions your email infrastructure as modern and reliable. This proactive approach is a key part of boosting email deliverability rates.
• Continual measurement: Monitoring TLS handshake success rates and versions used can provide valuable insights into your email ecosystem's security and help identify communication issues with receiving mail servers.