The level of security offered by many of these services varies greatly. As usual, there is no such thing as 100% seure. It is all about levels of security and ensuring the level you select is adequate for the level of risk your exposed to.
The problem with email is that it pre-dates network security concerns. When the SMTP protocol was defined, we had a much higher level of trust and security just wasn't a significant concern. This means that all subsequent attempts to make it more secure involve bolting on additional functionality rather than building on to a base which incorporated security from the ground up.
There are three broad areas where email security is a problem. Most secure email solutions are only able to deal with two of these areas and the thirds is frequently overlooked completely.
SMTP Protocol. Essentially, this is a plain text protocol with an underlying assumption of trust. There have been extensions developed which now encrypt the data, but this is not necessarily enforced. When email was first developed, the networks involved were not as stable or reliable as they are now. To handle this, SMTP was defined with a robust routing approach which could handle networks which were often unavailable or had changes in topology. Many people don't realise that when you send an email from one person to another, your message doesn't necessarily go straight from your mail server to theirs. It is possible that the message will be relayed through a number of intermediate mail servers before reaching its final destination. To make it even worse, you cannot know exactly which mail servers the message will be routed through and therefore, cannot guarantee the level of integrity of the servers involved. Even when you request encrypted extensions, there is no guarantee that all the servers involved will honour that request. While the increased stability and improved connectivity of the Internet has reduced the frequency of mail going through unknown servers and while more servers are configured in a more secure way, there is still no guarantee - essentially, you are relying on the integrity of systems you have no insight into and trusting in the skills of unknown administrators etc.
Client protocols. Even if you are able to guarantee that the mail servers are secure and that all SMTP traffic is being encrypted, you then have to consider how the clients are retrieving the messages i.e. POP or IMAP. Nearly all reputable providers now provide POP/IMAP over SSL/TLS, you cannot guarantee the recipient of your mail is doing so. For backwards compatibility, many providers will still support unencrypted POP/IMAP. Then there is the issue of where the messages end up being left. If you are using POP, then most likely, the message will be downloaded to your client machine and removed from the server (though this is not guaranteed). If you are using IMAP, then the message is most likely left on the server. Does the server use encrypted mail boxes? Probably not and if they do, then probably all the mail is encruypted with the same key and even if it isn't, most likely the sys admins on the system have access to the key.
Client mail storage. This is the most often overlooked area of concern with respect to email. When you send a message, does your client keep a copy of the message on your hard drive? Is that copy encrypted? Often, it does keep a copy and rarely is it encrypted. Likewise, when you retrieve the mail from the server and store it in your inbox, is it encrypted? Probably not. Most compromises occur on client machines i.e. virus/malware and email is frequently a rich source of information.
Very few of the secure mail solutions are able to address all the possible security risks. They frequently focus on addressing the SMTP weaknesses by requiring those sending mail to connect directly to their server and for clients retrieving mail to connect directly to their server. This eliminates the risks associated with SMTP mail routing. The provider has control over all servers involved and therefore can have increased guarantees over how things are managed. In addition, they will enforce good client (both sender and receiver) security, usually be ensuring connections are encrypted and often by providing enhanced authentication, such as personal certificates, multi-factor etc. They will often reduce risks by providing ways to ensure messages are safely deleted after user set grace periods and will ensure that the messages are only stored in encrypted formats. In some cases, they will provide the mailbox owner with encryption keys so that only the owner is able to decrypt the messages and even the sys admins can't read them. However, none of these services can ensure security on the client end - what the sender does with messages they send and what the receiver does with messages once they recieve them.
So, if specialist providers can do this, why don't all providers just do this and we can all have secure mail? Part of the problem is that often the approach does not scale well. However, the real problem is with mail routing. The basic SMTP protocol simply does not provide the ability to specify which mail hosts you willl allow your message to be routed through.
Are secure mail services worthwhile? Well, depending on the service,, yes they can be, but this really depends on your level of risk and therefore needs to be assessed on a case by case basis. There simply is no guaranteed secure mail solution apart from encrypting the data yourself.
So why don't we just encrypt the data ourselves? The main reason is that its too hard to manage. If you encrypt your mail, you need to communicate the decryption key to your recipient. Both you and your recipient need to be setup to handle encrypted mail and you have to manage lots of keys. In some cases, where the risks warrant it, going to this degree of effort is justified, but for most cases, it is more effort than its worth and certainly not a good general solution. The real answer is to develop a whole new email protocol which incorporates security as a fundamental design goal. However, getting everyone to move to such a new protocol and ensuring the millions of servers and clients are updated to support it is a huge task. It is also unlikely to occur as I suspect email is being subsumed by other modes of communication. Although still fundamental in the enterprise, I've observed a significant drop in use by the next generation - talk to a few kids and you will find they hardly ever use email, preferring SMS and IM instead. Even the enterprise is seeing a move towards more collaborative style comms with things like Lync, IM, direct file sharing etc.
