TLS Encryption – Securing Email Communications

If sufficient reason does exist, emails can be signed, encrypted and secured to ensure end-to-end security, thus providing controls over who can open, forward and print messages. However, when one is utilizing a SaaS based email solution like Office 365/EOL, email remains sufficiently secure within the confines of the business.

If you or a business partner using Office 365/EOL sends email between your businesses, these messages are (by default) encrypted utilizing opportunistic TLS Encryption.  No configuration is really needed.  This is very good news for those who presently have their business on Office 365/EOL. (click for more information)

However, in some cases, businesses managing their own email systems ought to take advantage of this particular feature by enabling and making it available to your customers, business partners, etc.

Implementing TLS Encryption

There exists many articles or consultants who can help with, clarify or implement these security elements.  This article though doesn’t cover the necessary “per se” steps.  The purpose of this is to increase the awareness, advantages and benefits of why a business might undergo this effort.  Simply put, the real benefit to enabling secure email is knowing all communications sent between your organization and another will not be subject to prying eyes or eaves dropping.

Businesses today have many partners and external entities.  The first step is to make a list identifying those where sensitive information enforcement is required.  The next step is to launch an initiative to secure these communication channels without impacting production. Although only lightly touched above, other methods can be employed to further secure email transmissions.

To reiterate, as mentioned above, opportunistic TLS is enabled (by default) for all Office 365/EOL customers. Meaning, email which traverses between EOL customers is fully encrypted. This can be validated by analyzing message header information. This is also of particular interest because customers looking to enable or provide TLS communications, who currently reside on Office 365/Exchange Online, already have this feature. This is certainly a plus point.  Another plus point is most major SaaS based email provides, such a gMail, offer (TLS) secure transmission of email.

Unless specifically configured, businesses who manage their own mail services, which do not reside on Office 365/EOL, typically do not have this feature enabled. This could include a Lotus Notes deployment, Exchange on-premises implementation, Iron Port (SPAM/Malware inoculation, SMTP relay), etc.

What does this mean?  It means simply there is an opportunity to make these more secure. The good news is, it can be readily enabled with very little effort.

TLS Integration: Notifications

There are a few other facets one ought to analyze and inspect when transitioning a business to a SaaS email service (such as Office 365/EOL). For instance, most businesses need to maintain some form of internal alerting or notifications via email.  Or perhaps your business maintains an internal database which performs weekly email batches for clients. Most often, this can include lower forms of sensitive information (e.g. Server names, IP Address, customer billing information, etc.). An SMTP relay server is designated for this very purpose – for transmitting internal emails to your EOL or other environments.  Minimally, one ought to look into enabling and certainly validating TLS is enabled and functioning between your on premises and EOL tenant. This by default is not enabled.

For businesses who wish to enable TLS (or encrypted) email for their managed email system, one would need to purchase an x509 certificate from a reputable provider, such as Go-Daddy, Network Solutions, etc.  The DNS “hostname” would need to be registered with your DNS provider, and likewise would need to match the subject name on your purchased x509 certificate. There are also other various certificate requirements that must be met. One could also leverage certificate wildcards or subject alternate names (SAN) if utilizing multiple email servers. As far as the configuration of your managed email server, one would need to refer to your vendor provided the documentation of how to implement TLS.

LATEST VIDEOS