You might think that your company email is sent over encrypted connections, but have you ever checked? Did that include both incoming and outgoing? With our free tool you can verify and test the encryption of your outbound email connection at the click of a button.
Just send a blank email to: dmarc@emailsecurity.im.
The encryption checker ensures your emails pass DMARC, SPF and DKIM checks alongside also checking that your outgoing email is sent over a correctly encrypted connection. Results for this will vary from:
✅ STRONG ENCRYPTION – successfully verified strong outbound email encryption
⚠️ WEAK ENCRYPTION – outbound email encryption needs attention
⛔ NO ENCRYPTION – emails are sent unencrypted and pose a cyber risk, resolve with priority
The Opportunity
Most modern email services will incorporate what is known as ‘Opportunistic TLS’. This means that if both sender and recipient are capable, they can negotiate with each other and agree to use an encrypted connection to send and receive your email securely. There are other protocols that can be used to apply encryption and other safeguards – these are less widely available and less used, but Opportunistic TLS is available on every modern system that sends email and is easily configured.
The big problem is that it requires ‘both’ parties. Your email service may be fully equipped and 100% capable of ensuring all email traffic connections are encrypted, but if the other party you are communicating with is weak it makes no difference, the email is exposed.
It is wrong to assume that trusted parties you regularly deal with will have modern systems that ensure encryption. You must trust but also verify to protect your business and client data.
Unfortunately, we have seen an increasingly worrying trend, especially in systems that use automated email, or with online email services. These systems are often installed and configured under time pressure, either because the business needs the system yesterday, or because there was a fixed price and every minute counts. The natural approach is, once the email connectors have been configured, to jump online and use any one of a multitude of tools to test the email certificate and its encryption. The result comes back all clear – the certificate and its chain are valid, email traffic is encrypted, data is secure in transit, green light to go live. Only the online tool tested incoming email connections – not outgoing. Email systems often have 2 connectors to be configured to make the email work. An inbound connector, and an outbound connector, both often configured separately.
The Habits
We have seen an alarming number of cases of well-known application vendors, ISP support desks, trusted accountants, sensitive payroll, and many other email services (some specializing in email security!) from both small and large (often global) operators, receive email over properly encrypted connections, but respond to them with no encryption at all. When we inform those entities or their clients, there are some alarming responses:
“Email is insecure anyway so you should treat it all as in the public domain.”
It is insecure if you don’t secure it!
“All our email is secure – here is the screen shot of the ‘use TLS’ tick box we ticked.”
So, you haven’t bothered checking the email connection logs, just screenshotted the inbound connector configuration and missed the point! Or perhaps you don’t keep the logs!
“We don’t really send anything confidential anyway.”
You do, and besides, your suppliers and customers email you – don’t you feel obliged to keep their data safe!
If your email is unencrypted it can be intercepted and read, and often is. You are then wide open. Consider the following scenario, which is one of many that can and do happen:
Spear Phishing Example
Bill@InBusiness.com & Bob@InBusiness.com the company directors are discussing a large 3rd party transaction with Dave@OutsideLawyers.com the company’s law firm and Joe@OutsideAccountants.com the company’s accountant. Their email system is properly configured and capable of encrypting all email traffic using strong TLS. Their IT guys have used the usual online tools to double check each 3rd party’s email is encrypted as they regularly discuss very high value deals. Following a call to agree terms it’s all confirmed by email and Bill then instructs Joe@OutsideAccountants.com to transfer funds once Dave (copied) has the clients signoff, and he includes the client bank details. Bob@InBusiness.com, who was copied in, also adds his approval to the thread to comply with the company payments policy. Dave@OutsideLawyers.com then confirms client signoff. Joe then receives another email on the same thread, from Bill@lnBusiness.com (with Bob@lnBusiness.com copied in) stating he gave Joe the wrong bank details. Bob@lnBusiness.com follows up with another approval. Joe makes the transfer and the funds are moved but never received by the client.
What actually happened was the law firm uses a CRM system to record all communication with clients keeping such conversations on one ticket for ease of retrieval in case of disputes. The CRM is not configured properly to encrypt the connection on outgoing email, and the IT guys at InBusiness.com didn’t test that because they don’t have credentials for OutsideLawyers.com to test their outbound connections. The emails from Dave@OutsideLawyers.com were being intercepted and read by a bad actor at the ISP (Internet Service Provider). The bad actor had registered a new domain name lnBusiness.com (the first character has been changed from ‘I’ to ‘l’), and the last two emails, which contained the whole conversation, used language that Bill & Bob would use, were indeterminable from the original thread, and passed straight through the email filter because they were totally genuine emails, were, you guessed it – sent by the bad actor.
Changing Habits
Whilst email service providers continue to treat their traffic as insecure, and vendors and support desks continue their complacency when implementing their systems, the bad actors will continue to compromise businesses and critical or personal data that invariably finds its way into the email service that has been neglected. This is why email is insecure – not by design, and not by technical or protocol limitation, but through complacency.
I trust the information, example, and free test I have detailed are of use to you and your business. Whatever the results of the test, I commend you for taking action to verify.
If I or our company, Riela Tech, can be of any further assistance with outbound email encryption connections or other email related enquiry, do not hesitate to contact us today.
This article is a copy from Tim Bliss’ LinkedIn posts here.
Subscribe to our newsletter
Stay updated with our latest blogs and company updates.
