The Modern Marketing Blog covers the latest in marketing strategy, technology, and innovation.

Gmail, TLS Encryption and Why Email Marketers Need to Know About It

Kevin Senne
Senior Director of Global Deliverability

Last week, Gmail announced that they were adding a “broken lock” icon for Gmail on the web senders who didn’t support TLS. For those of you who don’t know, TLS stands for Transport Layer Security. TLS has been around for quite a long time, and was primarily used by financial services companies who were looking for a higher level of security and encryption.

I am not going to go into a deep dive about TLS and how it all works. That’s easy to find if you are interested in the specifics of data encryption.

For most of us, those details might be a little on the boring side. Here’s the short version: TLS is an encryption protocol that uses “keys” to encrypt communications back and forth between 2 parties. Any extra security layers that we can add to email are a good thing.

The thing about TLS is that only some email providers support the protocol. In the past, setting up TLS was more of a “niche ask” for senders. Maybe they had a partner who only accepted TLS encrypted email, and that would be the driver for setting it up. Here’s the cool thing about TLS. You can setup TLS and it only comes into play if the receiving server asks for it. It’s never a bad thing to protect your digital assets, and especially as email becomes more and more personalized.

Here’s Gmail leading the charge once again by not only supporting TLS, but by giving senders a mechanism to check for it. We believe these advancements are great for our industry, and even more important, great for our customers.

So, what will those customers see in Gmail now that these additions are live? 

You can see the broken lock in the top right corner. This will show up when the sending server does not support TLS. Makes sense that you might not want to send account information in an unencrypted format.

The other change shows what receiving an unencrypted message looks like.

There’s nothing shocking or scary here to most recipients, just something an educated Gmail user might be looking for.

In terms of the Oracle platforms, if you are a Responsys user, TLS was enabled over the weekend for all senders. You should not see any of the above conditions. If you are an Eloqua user, you can have TLS enabled by opening up a support request, asking to enable TLS. 

At the end of the day it comes down to achieving deliverability that delivers results. Download the Email Deliverability: Guide for Modern Marketers to learn best practices when it comes to achieving the deliverability you need. 

Join the discussion

Comments ( 2 )
  • Alex Thursday, March 17, 2016
    I will admit to only having a very basic understanding of TLS in email. That said, it was my impression that sending email via TLS requires something custom to be set up on both the sender's MTA and the receiver's MX. Is this the case? And if so, does an ESP need to have a "custom" setup with the different MXs at Gmail, Yahoo, etc.? It seems unlikely that the ISPs would work directly with high-volume senders like this.

    If this is anything remotely close to reality :-), wouldn't using opportunistic TLS only result in a TLS connection with those MXs where something custom is set up? So when some ESPs say that they have started using opportunistic TLS in their message sending, are they really sending a large portion of their messages via TLS or is it sort of just a bluff?
  • Kevin Senne Monday, March 21, 2016
    In the case of Gmail, Yahoo etc, the way opportunistic TLS works is when an ESP connects to an ISP, if the ISP advertises that they support TLS they then provide the certificate to use to encrypt the connection. The ESP then disconnects and reconnects using that certificate to create an encrypted channel to send emails through. This isn't a bluff, it is a higher level of security.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.