If you use email — and, let's face it, how many lawyers do not? — it is vital that you secure it.

You are probably communicating a lot of sensitive information by email, and email is likely to be the system used to reset passwords on other accounts. At the very least, secure your email. However, you should also consider if email is the right tool at all – there are alternatives which may offer security more appropriate to the risk.

If your email account gets compromised, it could be very difficult to unpick it.

If you have used your personal email account to sign up any accounts for work (e.g. social media accounts), follow this guidance for your personal email account too.

• Use a unique password
• Secure your DNS: it's critical
• Host your server (physically) in a suitable country
• Secure the connection between your mail client and your email server
• Secure the connection between your mail server and the mail server of your recipient
• Minimise a fraudster's ability to spoof email from you
• Enable two-factor authentication if you use webmail
• Consider PGP/GPG for email encryption
• If you cannot encrypt your email, consider encrypted attachments
• Do not trust that the sender is who they say they are
• Do not trust unexpected attachments
• Disable automatic loading of remote content
• Don't use tracking pixels or remotely-hosted content
• Be aware of phishing email

You should use a unique password for every account you have, but this is especially true for your email account.

If you have your own domain name, make sure you secure your DNS.

Here.

Here.

Check that your mail server permits encrypted connections, and make sure you use them.

When you set up your mail client (e.g. Outlook, Thunderbird, or macOS's Mail), look for an option like “Use TLS/SSL”.

If you do not do this, someone spying on your connection might be able to see:

• your username and password, and then access your email — they could read your mail, and send email coming from your account.
• the content of your messages, including attachments.

As you cannot be sure whether your recipient has done the same, if you are sending anything sensitive, encrypt it before you send it by email (e.g. by using PGP, or an encrypted .zip folder, or use something other than email.

Ask whoever administers your mail server to configure what is known as “opportunistic TLS”.

When it is correctly configured, when you attempt to send an email to a third party, or someone tries to email you, your server and theirs will have an initial chat, to see if they can make an encrypted connection before transferring the actual email.

You can test if you already have it working for your mail server here.

If it can't, it will still transmit your email anyway, and, in doing so, it will pass unencrypted over the Internet.

Because of this, if you are sending anything sensitive, encrypt it before you send it by email (e.g. by using PGP/GPG, or an encrypted .zip folder, or use something other than email.

A common fraud (example is where a fraudster sends an email pretending to be from a lawyer, asking the recipient to do something expected and reasonable, but in favour of the fraudster rather than the solicitor — for example, getting a house buyer to transfer their deposit to a fraudster's email account, rather than the lawyer's client / trust account.

Spoofing an email — making it look like it has come from your email address — is trivial. You cannot stop someone attempting to spoof an email from your address, but there are some things you can do to lessen the likelihood of it succeeding.

SPF — sender policy framework — involves setting a text record in your domain's DNS, which says which IP addresses are permitted to send mail for your domain. This is another reason why securing your DNS is critical.

When someone receives an email, their server will hopefully check your domain's SPF record, and determine if the email has come from one of the authorised IP addresses. If not, it might be marked as spam / junk, or else rejected.

An example of an SPF record, for domain example.com, is:

example.com.  IN TXT "v=spf1 mx ip4:203.0.113.7/32 ip6:2001:db8::/32"

There are a number of tools to help you generate your domain's SPF record. For example, here.

DKIM — DomainKeys Identified Mail — is a mechanism for signing and verifying messages.

As with SPF, you need to add a text record to your domain's DNS, but, for DKIM, you also need to make changes to your mail server's configuration.

What you will need to do will depend on your email server or service provider, so either check the manual or help pages, or get someone who knows what they are doing to help.

DMARC — Domain-based Message Authentication, Reporting & Conformance — is an authentication and reporting mechanism. It builds on SPF and DKIM, and lets a sender state whether their email are protected by either or both of these things, and what a recipient should do if those tests fail.

Because it builds on SPF and DKIM, get those in place first, before you look at implementing DMARC.

As with SPF and DKIM, this is another text record for your domain's DNS.

From a security point of view, setting your DMARC reject to suggest to recipients that they should reject messages from your domain which fail SPF and/or DKIM checks offers the best security. It requires you to make sure that your SPF and DKIM records are correct and up to date as, otherwise, “genuine” email might be rejected.

If you use webmail — where you can access your email through a web browser — enable two-factor authentication on your login.

If you can only access the webmail interface via a VPN (i.e. it is not exposed to the public), the risk of not having two-factor authentication is reduced.

Securing email is difficult, as you are trying to bring an acceptable level of security to an inherently insecure system.

If you've done the steps above, and still want added security, PGP — Pretty Good Privacy — and its open source implementation, GPG, is a means of encrypting your email and its attachments “end-to-end”, meaning that only the recipient (or someone who has compromised their security credentials) is capable of seeing the content of what you have sent.

PGP/GPG secures only the content of what you have sent, and does not hide the existence of a communication, nor the identity of the sender or recipient, nor — importantly — the subject line.

Because of the way it works, both you and the recipient have to be PGP/GPG users, and you have to have some specific information about them: their “public key”.

PGP/GPG is not perfect, but it is better than not encrypting your email. Depending on your needs, you might want to look at alternatives to email, which offer better security.

• PGP/GPG does not hide the existence of a communication, nor the identity of the sender or recipient, nor — importantly — the subject line.
• If you lose your private key, or forget your passphrase, you cannot access your email.
• If someone gets hold of your private key and your passphrase, they can access all encrypted email sent to you with the corresponding public key, and they can send email pretending to be you, signed with your own private key.

macOS: GPGTools. This is a good "first steps" guide to using GPGtools with the native macOS email client. There is also a version of Canary Mail for macOS.

Windows: Enigmail, used with the Thunderbird email client. Set up guide, by the Electronic Frontier Foundation

iOS: Canary Mail (make sure you use “fetch” rather than “push” mode).

PGP/GPG is not for everyone and, even if you use it, it is of no use if your intended recipient does not.

If you need to transfer something sensitive as a once-off by email, put your message, or the files you want to send, into a directory, and then encrypt the directory. Send that encrypted directory to your recipient, via email, and give them the password by a separate, secure channel.

Do not email the password, as otherwise you have sent both the thing you are protecting, and the password to access it, by the same means: someone monitoring their email would get both elements. Send it some other way, such as by text message, or give it out over the phone.

As with PGP/GPG, this would still leave the subject line and content of the email, along with sender and recipient information, available to anyone.

You will be able to see the name of the attachments and, in the case of files in a zip folder, potentially the names of those files too, so use non-identifying names for the files if that is a concern.

How you do this varies from platform to platform.

On macOS, you can do it using Terminal, but it is not particularly user-friendly.

For Windows, 7zip offers easy-to-use encryption.

It is very easy to make an email look like it has come from someone else — the email you receive from your boss, or client, or someone in another law firm, may not have come from them at all.

It's easier said than done but, before you take action based on an email, especially if anything about it strikes you as unusual (time of sending, tone, the fact that you thought you'd had a conversation about the topic already etc.), check with the sender via a different means of communication already known to you.

An unexpected attachment may be an attempt to attack your systems.

There is no harm in ringing up the purported sender, and asking if it was really from them. But don’t use the phone number in the email itself (as that might not be their actual phone number) — verify some other way, such as using a number you already have on file with them.

Some people tart up their email by adding images hosted on remote computers. When you open those email, you connect to those remote computers and download the images.

When you do this, you leave a footprint on the remote computer. Sometimes, this is used as a tracking technique, using small, invisible images as a means of detecting when you opened an email.

Check that all your email clients have disabled loading of remote content.

For example, in macOS's Mail application, it is in Preferences / Viewing:

In iOS, it's in Settings / Mail:

Although it might be convenient to know who has opened your email and when, using tracking pixels or remotely-hosted content is bad practice.

“Phishing” email are spam email where the sender tries to trick the recipient into handing over sensitive data. It could be someone pretending to be your bank, your accounts department, or even a client. Some phishing attacks are very good, especially when they are targeted at you (for example, based on information obtained from a previous successful attack, or a breach).

See the guidance from the National Cyber Security Centre on how to spot phishing attempts, and mitigate risks.