Email is perhaps the most important component of any professional organisation’s IT setup. As such, it deserves a regular check-up to make sure that best practices are being adhered to. Whilst it’s difficult to put a complete audit list in a blog post, here are the top five mistakes that we see most often.
1. Not Giving Each Person Their Own Login
First up we have the single biggest security issue in email: not giving each individual person their own login credentials. Without this, there is no traceability in who did what or who replied to whom. If both Jane and Adam share the same username and password to the same email account, there’s no way to track who did something, giving both of them plausible deniability.
This isn’t the same as them both using their own password to log in to a shared mailbox, here we are talking about both using the same password to log in to a personal mailbox. For example, Adam might be Jane’s assistant and needs access to her email. There are two ways this could be done:
The wrong way: Jane writes her password to her jane@example.com email down on a piece of paper and gives it to Adam, and he logs in and is able to (as far as IT is concerned) act like her.
The right way: Adam is given his own login, adam@example.com, and then is given access rights to manage Jane’s email. This way, what Adam does can be logged, and if Adam moves to be somebody else’s assistant, access rights can be easily changed.
2. Not Using Shared Mailboxes, Email Distribution Lists, and Aliases
You may have read our first point and thought to yourself, “but what about when two people on a team need to share email?”. Most email providers have a solution for this: Shared Mailboxes (Google Workspace calls them Collaborative Inboxes). Using shared mailboxes to share common email addresses (such as sales@ or support@) amongst many employees is the recommended solution these days. It allows team members to come and go without issues.
One problem, in particular, is worth calling out: using a common team email (such as sales@) as the personal email of a single employee, just because that employee is the only member of that team – so far… Let’s take an example. Alex is the only member of the sales team. To keep things simple Alex use sales@example.com as their email address. Alex uses this not just for sales but also for discussions with HR and Payroll and other private matters. Sales are going great, and it’s time to add a team member (Sam) – but how do we handle email?
Because Alex’s personal emails are intermingled with sales-related emails, it’s impossible to give another person access to that mailbox. The only solution is to move sales to a shared mailbox and give Alex and Sam both their own personal emails in addition to this. This migration is far easier to do before you’re forced to.
3. Not Using Your Own Domain Name
Luckily, we’re seeing this one less and less, but it still pops up from time to time. If you’re advertising a Gmail or ISP address to your clients or suppliers, stop now. If you’re still getting emails sent occasionally to one, get it updated. It takes years to fully migrate email addresses, as you can basically guarantee people won’t stop sending emails to an old address until the server stops accepting it.
Which looks more professional: randomcompany-ceo@gmail.com, or jane.smith@randomcompany.com? It’s a no-brainer.
There is a singular exception to the use-your-own-domain-name rule: at least one of the login email addresses for your domain registrar (where you registered your domain, such as Crazy Domains or GoDaddy) should be a non-corporate address. This ensures you have a recovery method in case there are problems with your domain name. Just make sure you know what that email is and keep it updated as needed. For example, if the domain is registered to the CEO’s Gmail address, and the CEO changes – you need to make sure that login is updated! We see this problem most commonly in the boards of smaller non-profits, as they tend to have a higher turnover of staff.
4. Not Enabling 2FA
Two-factor authentication is the fancy IT security terminology for “asking you for something else in addition to a password”. What could that something else be? There are three ‘factors’:
- Something you know (this is the password).
- Something you have (like a phone, or a house key).
- Something you are (this is biometrics, like a fingerprint or DNA).
Because biometrics causes all sorts of data privacy issues, the second – something you have – is most common in the IT world. These days, that usually takes the form of software on your mobile phone that generates numbers according to a set pattern. These numbers change every 30 seconds. The numbers appear random if you don’t know the pattern (agreed to by the individual phone and by the email provider), which makes it good security as nobody else can guess it.
Why is this so important? Because if you rely exclusively on passwords, and that password gets discovered by an attacker, all they need to do is enter the password and they have complete access. However, if they also needed access to the user’s mobile phone, the chances of that happening become much smaller.
When enabling 2FA for your organisation, we recommend taking a month or two after announcing the change before enforcing that 2FA must be used. This way, people have a chance to get used to it in their own time. We don’t recommend leaving it longer than a month or two though. 2FA has such high value to your organisation’s security that it would be a bad idea to leave it longer.
A final benefit of 2FA is that it stops users from sharing passwords with others to get around corporate security policies that limit who has access to what. This gets a lot harder if they need the time-based 2FA codes as well.
5. Expiring Passwords
Finally, we get to a contentious problem: expiring passwords. The advice on this has changed over the years, but the consensus is now that passwords should not expire. The reason for this is that while in an ideal world expiring passwords might be great, we don’t live in an ideal world.
In our practical, imperfect world, if people can’t remember their passwords, they write them on sticky notes and leave them next to the computer. This basically bypasses all security. In addition, most people, when forced to renew an expired password, just add the month or year to the end of the old password to make up a new one. We’ve seen this in the real world many times.
The best practice is now to use a unique password for every service and store those passwords in a password manager. Making passwords expire is a roadblock in the path of that best practice.
Conclusion
There are a lot of factors to take into account when reviewing your organisation’s use of email. These best practices will greatly help your marketing, human resources, and IT security departments achieve their goals.