I've been searching for a while, trying to find a good get of information about the inherent risks of transmitting sensitive data via email. I'm really looking for a comprehensive list of all the vulnerabilities from an outside source that we can use as part of our "IT Security 101 for non-IT business leaders" training initiative. (I did search both here and on Google first. On Google, I keep getting lengthy articles, and I found good bits and pieces here as well as in my Google searches, but not a full list like I'm looking for.)

The background is that I have various people in the business side that just don't get it. They insist on using email and refuse to accept the fact that it's just not secure.

In my current dilemma, we're implementing SSRS for reporting, and we are expecting people to view the reports on the SSRS site. The reason is that most of the reports we deal with contain sensitive data of one form or another, and we just don't want these reports sent via email. State regulations where we operate identify PID as a last name, first initial or name, and any other form of identifying information, such as an address, SSN, account #, email, etc. The state laws also stipulate that a breach leaking 500 or more records containing such PID has to be reported to the state.

Many of the reports do contain PID by this definition, and most have well over 500 records. So IMO a single report picked up by a sniffer, or accidentally sent to the wrong person is a reportable breach - not something we want to deal with.

However, we have certain upper level management that seems to think that the rules don't apply to them, mostly because they don't understand how real the risk is. The good news is that we're making headway in changing their minds. The bad news is that their eyes glaze over when we get too technical. Also, they don't want to just take our word for it.

Examples I can think of:

  • Sniffers can be used to read emails as they are moving across the network.
  • Email gets sent through many servers between the sender and the recipient. Any one of those servers could be intercepting and saving that email.

I'm not too concerned about the list being too technical - We can us analogies that the business will understand to explain the technical concepts. I'm more interested in a list that's got all the risks.

  • 1
    Or maybe it's you who won't get why they cling on to their email. Before you talk them out of using their daily use tool that just happens to work for them, have you sat down with them to ensure you can provide equally good an alternative? And mind you, there's a step from "convenient" to "usable" and then another all the way to "enjoyable" ;) Also, rather than insist that you're right and they're wrong, do you have an informed strategy to bring about change? There might be plenty of better ones than showing people wrong. ;) Oct 5, 2014 at 23:49
  • We had an organisational psychologist telling us about how to implement change strategies in corporations, recommending mindtools.com/pages/article/newPPM_82.htm as a starting point. Just keep in mind that you're taking something important away from them for very relative and hard to understand benefits. You must have a strategy to make your alternative seem profitable and to make it fit in practice. Oct 5, 2014 at 23:53

4 Answers 4


If you want an analogy, read this.

As for the list of vulnerabilities:

  • Emails can be sniffed in transit, since they are not encrypted (some sites will opportunistically employ encryption for transit, but this is not reliably activated).
  • Emails will be stored on physical disks in the servers which are involved in the operation: the sender's email server, the recipient's email server, and any server "in between". Physical disks can be sniffed when decommissioned or through backup tapes. Bored interns in the facilities managing these servers could simply have a look.
  • It is easy to make emails go to the wrong machine by altering the DNS.
  • There are viruses which routinely inspect emails received by infected machines, in search for passwords, credit card data or other juicy information.

The whole email system just assumes that everybody is honest and nice and trustworthy. It is surprising (but morally encouraging) that it works at all.

  • 3
    I'd like to mention the integrity issue, emails can be made to look like they came from virtually anywhere.
    – Adi
    Feb 1, 2013 at 16:43
  • 1
    One reason that isn't really listed here is the persistence of emails. These days emails get persisted and replicated forever on a whole slew of user devices (tablets, cell phones, laptops) on both ends.
    – Ashtonian
    Jun 20, 2018 at 21:41
  • 1
    I do not understand why the exact same reasons do not apply to any other technology. Emails may or may not be encrypted depending on how the server is set up, just like it is with web-sites and other services. SMTPS uses TLS. Web-sites may also store data in databases and on disks where it also may be viewed. If you can alter DNS then you can attack a web-site too, redirecting http-requests. And viruses target browsers too just like they target email-clienets. Yet people claim that Web is more secure than EMail. The system assumes that the two mailing servers are doing good job, that's all.
    – Gherman
    Jul 18, 2022 at 17:54

The simple and deepest answer is that SMTP (Simple Mail Tranfer Protocol), which handles the sending of mail from client to mail server and between mail servers (other protocols such as POP3 and IMAP are typically used to retrieve mail nowadays), was originally designed for use in the ARPANET, which operated in a time when anyone who could use it had a security clearance in the first place. As such, SMTP fails at all of the four key aspects of information security, because when it was designed whose concerns were handled by alternate means, and the protocol has never been updated to attempt to do so.

  • Confidentiality: SMTP e-mails, by default, are not encrypted during transport or at any other time. Anyone can read them while they are being transmitted along an unencrypted channel, or while they are stored on either party's mail servers awaiting retrieval.
  • Integrity: SMTP provides no more error checking than the transport layer protocol used to send it. That is woefully inadequate when you want to ensure that nobody has tampered with the message; TCP is designed to help ensure that the network itself didn't cause data corruption or loss; it's trivial to change the contents of TCP packets enroute if you have control of one of the network nodes along which they're sent.
  • Authenticity: SMTP has no means to verify that the listed sender is actually the person who sent it. Someone halfway across the world can create an e-mail with your address in the "From" field and nobody will know the difference.
  • Non-Repudiation: Because you can't verify that the person listed as the sender actually sent it, or that the e-mail itself is the original content sent by that sender, that person can very cogently deny that what you received is what they sent, or that they ever sent you an e-mail in the first place.

The addition of the SSL/TLS security handshake into SMTP, creating SMTPS, provides confidentiality on the first leg of the trip (from your computer to your "home" e-mail server). That's all; you can't enforce confidentiality along any other leg of the trip, and the other three aspects of InfoSec are unaffected.

  • 1
    "Nobody will know the difference" is a bit of a misnomer. While the difference might not be obvious, if there are signs to make someone suspicious of the origin of the email, the trace headers (especially when compared to other emails from the same alleged sender) will provide fairly conclusive evidence to at least whether the same ISP was used to send both emails. (Now, a lot of the time these days, that ISP is actually Gmail, which by itself doesn't tell you much of anything...)
    – user
    Dec 15, 2014 at 15:30
  • 1) SMTPS is a thing. 2) Does HTTP provide protection from tempering? 3) SPF/DKIM. Basically DNS helps with it. 4) Same applies to HTTP-requests, right? I don't understand how Email is less secure than the web-sites given that it seems that all those reasons apply to web too, and in fact it applies to almost all networking techs. It's just as secure as the servers doing the jobs, just like with web-sites. Except it relies on two servers instead of one.
    – Gherman
    Jul 18, 2022 at 18:02

One of the main reasons I don't like using e-mail for transporting any sensitive information is simply because once the e-mail with sensitive information has left your organization, you've instantly lost any control you may have had over it.

For example

  • User has sensitive e-mails in their inbox, just sitting there. If account is compromised you now have free reign over any e-mail with all sorts of sensitive information
  • You no longer have any knowledge whether or not that receiving user will forward the e-mail to parties that should not receive that information
  • You now have two potential points for compromise - servers that have sent the e-mails and servers that have received the e-mails. You place a lot of trust in the admins of those servers and you just hope they aren't snoopy and look at information they shouldn't be seeing
  • You have no governance over retention rules or archiving practices on the receiving side. Documents that should have limited lifespans can potentially live forever on a server with no archiving or deletion practices

I would almost always recommend an alternative solution to sending sensitive information via e-mail for the reasons I've listed above.


What insecure could mean?

  • Confidentiality -> Yes, mail is insecure, but you could use an encryption layer (like PGP) when needed.
  • Efficiently -> No: mail is one of the simplest and safest way to transmit information to specific persons.

Don't forget that security have many vectors. The perennity and efficiency are important security vectors too.


Mail system network work likely in the same way than real post:

  • once could write anything in a paper letter
  • add toxical material to paper
  • faking sender address
  • faking enveloppe sender address
  • encapsulating in another enveloppe to send through another citie's post office.

All this is very unsecure, but anyway, everybody continue to exchange by real post.

When people harm agaisnt post security, it's more about the fact a letter may be loose than other...

The main difference is the cost of sending one mail. This implie more junk but nothing else.

So my point of vue is to say smtp is a well worked protocol, very sercurised about what's original goal.

About confidentiality

Like sending sensitive informations through real post. Having to do such kind of things implie subsequent securisation efforts.

So simply: Never send sensitive information in clear text.

Use another way to exchange keys and valid fingerprints, in order of preference: meetings, phone, fax, sms (with care).

  • 1
    I think you meant "never send sensitive information in clear text".
    – Ed Brannin
    Oct 5, 2014 at 20:27
  • Good advice, until the end: SMS is even less secure than email Aug 24, 2020 at 14:43
  • @InterLinked Yes, but It's another exchange channel. So by using both Internet AND SMS, you could improve confidence level... At least a little bit.. But you're right, I'ts easy to send fake SMS, as trapping SMS by using faked SIM card. Aug 24, 2020 at 21:52
  • Well, much easier than that really. I won't go into details but SMS is inherently untrusted. Providers are even moving away from it for 2FA/MFA, it's so insecure. Email is much better than SMS when done right, but there are so many more secure alternatives that SMS is inexcusable. Aug 24, 2020 at 22:54

You must log in to answer this question.

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