I was reading through different posts here about email security. After reading these I still have some questions.

I understand that S/MIME can be used to transfer email securely between servers.

  1. Is S/MIME used by Gmail, Yahoo, or Hotmail when I send e-mail from one of their accounts?

  2. Or is SSL/TLS the sole mechanism for providing security?

  3. Do all major e-mail providers use SSL/TLS?

  4. Under what conditions are e-mails commonly sent unsecured?

5 Answers 5


TL;DR - Without end-to-end encryption, such as S/MIME or PGP, being supported and used by both sender and recipient, it's a fair presumption that your e-mail has been transmitted or stored in the clear, or otherwise readable by a third-party, somewhere along the way.

I think you have some mis-conceptions of what S/MIME and SSL/TLS are, or how they work.

S/MIME is a mechanism for providing end-to-end message security. Encryption, digital signature, decryption, and signature verification are all done at the endpoints by the client software. The intervening e-mail servers and service providers have nothing to do with this, as the messages get passed along just like any other. Further, and perhaps most importantly, S/MIME must be supported by both the sending and receiving clients in order to work. This is beyond the ability of any single e-mail provider to ensure.

That being said, I'm not aware of any common freemail provider (i.e.: GMail, Yahoo, Hotmail) that is currently facilitating S/MIME in their browser-based clients. Certainly none of them are, nor would they want to be, enabling it as a default.

The reason this cannot work at the service provider level is because of the requirement for both endpoint clients to support the protocol. Since the service provider of the sender has no control over the client software used by the recipient, enforcing S/MIME use on outbound messages would result in many (if not most) recipients not being able to read the sender's e-mails.

The only conditions under which S/MIME will work are when all participants in the e-mail conversation have S/MIME-compatible clients, and everyone has (and has verified) each others' public keys. Again, this is not something that any individual e-mail service provider can effect. They may conceivably be able to facilitate this between their own users, but they do not have the same power to protect e-mails going to/from external endpoints.

SSL/TLS are technologies commonly used to secure communications between clients and servers and from server-to-server. However, here we again run into a similar situation as with S/MIME - both parties to the conversation must support it. While some service providers may do this, no service provider can guarantee you that SSL/TLS will be applied to every message you send because they do not have control over what the receiving server is configured to support.

To address your concerns more concisely, point-by-point:

  1. None of the above use S/MIME. While it would be a nice feature for them to support in their web clients, it would be infeasible for them to guarantee that it will work for all recipients. You can get around this to some degree by using your own e-mail client with S/MIME support, instead of using the web interfaces. However, again, this will only work where you have coordinated this with your intended recipients.

  2. SSL/TLS is commonly used to protect the web sessions by which e-mails are composed, and the client connections by which they are sent. It's also used to protect server-to-server communications along the way, but no service provider can guarantee that every recipient's e-mail servers or client will support and maintain that protection along the way.

  3. Many providers do use SSL/TLS, but you should check with yours yourself if you're concerned. Again, though, this cannot guarantee that your e-mail is protected through transmission and storage every step along the way to every recipient.

  4. Any time you are sending/receiving e-mail which is not protected by S/MIME, PGP, or a similar end-to-end encryption solution, you must assume that the message has been transmitted or stored in the clear, or in another form readable by a third-party, somewhere.

The last point touches on an issue I've not yet addressed - e-mail storage on the server. All e-mail service providers, by the nature of their service, must store e-mails exactly as they were received or by using some form of encryption that they themselves can reverse. Otherwise, they will not be able to forward the e-mail on in a readable format to others or display it to you in your web browser. If you're not using end-to-end encryption, that means your e-mail is being effectively stored in the clear. This leaves it vulnerable to malicious insiders, or anyone who manages to hack into your e-mail account or the server's database.

  • There is also "lawful interception". It seems like many big email providers share millions of emails with intelligence services. Commented Mar 29, 2012 at 9:25
  • 1
    As I understand it, S/MIME can be used to sign an email, regardless if the receiver supports S/MIME. And IF the receivers client supports S/MIME, after receiving a signed message from you, he can than send encrypted messages to you, since he has your public key, that was in the signature. Right? This can be achieved by using a client program that supports S/MIME. The freemail providers webmail clients don't, but e.g. Microsoft Outlook and Apple Mail do. So if you use such a client with a freemail account, you can have encrypted communications with S/MIME. Or am I missing something here? Commented Aug 16, 2017 at 13:46
  1. No
  2. SSL is used but not as an S/MIME replacement
  3. Gmail, Yahoo and Hotmail allow you to access your e-mail via SSL. And similarly will send e-mails using SSL but only where possible. It's difficult to say whether all providers do either.
  4. Pretty much always. It is very difficult to guarantee security with these providers without using something on top like PGP. Sure if you send from Gmail to Gmail there's a good chance it will be safe but no guarantee.
  • Wish I had you around to write the TL;DR section for my answer. Good job keeping it short here, while pretty well covering all the essentials.
    – Iszi
    Commented Mar 29, 2012 at 13:12
  • Thanks, I thought you wrote a great answer that could do with a little cutting down! :)
    – Andy Smith
    Commented Mar 29, 2012 at 14:21

2 SSL is used in two ways and while the providers seem to be pretty consistent about using it for server to client communications, they vary using it for server to server communication.

I ran some tests and while Gmail and Yahoo both use encryption if both sides support it, Hotmail never uses it for server to server communications. This means that communication between Hotmail and other internet providers is always in clear text


1) In general S/MIME is not supported by Gmail, Yahoo, etc when using their web-based email client (i.e. going to www.gmail.com). If you want to use S/MIME with these services you have to use a 3rd party email client (i.e Mozilla Thunderbird, MS Outlook, etc) and have a way to manage and distribute your public and private keys. The reason it is not easy to use S/MIME with Gmail etc is because the primary source of revenue for these companies is targeted advertising. The primary source of information used to target that advertising is the content of your emails. If they make it easy for you to use S/MIME for end-to-end encryption (so that they can no longer scan your emails) it undercuts their primary source of revenue (information about you).

2) Yes, but keep in mind that protection is often partial or incomplete. Just because the email service provider allows you to connect via SSL/TLS does not mean they support SSL/TLS connections to other email service providers. See 4) below.

3) No, ~50% of emails travel to or through providers that do not support SSL/TLS. I believe AOL only started supporting SSL/TLS connections in 2014 (via their web-based email client). See 4) below.

4) Under common conditions emails are not secure for several reasons. First, the email provider is scanning the incoming and outgoing emails to provide targeted advertising. Second, ~50% of the time the connections between the various email service providers do not support ANY encryption so the emails traveling between these providers must be sent as plain text. You have no ability to control this process because it is the connection between the providers. For example, if you send a email from your Gmail account to a friend with a Yahoo account the email must be transmitted from Google's servers to Yahoo's servers. The security of that connection depends he willingness of on Google and Yahoo to work together. I believe Google and Yahoo only recently started supporting encrypted connections to each-other. Google posted some data about this in June (2014). You can read the details here: http://googleblog.blogspot.com/2014/06/transparency-report-protecting-emails.html


How commonly is SSL/TLS used by e-mail providers?

Google provides some great up-to-date stats on domains that are using TLS to encrypt email between hops.


How much email was encrypted in transit?

Who supports email encryption in transit

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .