Email security best practices: How to keep your email program safe
This definitive guide to email security covers everything you need to keep your program safe, including best practices and areas to check.
You may have heard about the recent Log4j security exploit. And if you haven’t, you’ve probably heard about companies around the world getting their systems hacked and their email security compromised.
Keeping your email program safe isn’t easy. It involves setting up processes and protections for your APIs, vetting your third-party providers, educating your team, and more.
So how are you supposed to keep track of all of this? In this post, we’ll share email security best practices you need to know to ensure each cog in your email system is ironclad.
The stakes are high when it comes to email security. Hackers, spammers, and cybercriminals worldwide are constantly deploying bots to uncover weak spots. And once they get in…well, the sky’s the limit.
But why do they want to get in? Well, there are a few reasons why bad actors might want to breach your system:
The most common reason for a cybersecurity breach is to take advantage of your healthy sender, domain, and IP reputations. With access to your system, spammers can bulk send emails from your IP and use the trust of your domain to carry out phishing attacks on unsuspecting recipients, which can cost your company a lot of money and damage your email reputation.
Hackers are also hungry for sensitive user data – particularly in the case of healthcare and politics. Often it’s not just email addresses stored on servers, but also full names, phone numbers, and even home addresses. This makes data breaches incredibly dangerous – in the wrong hands, this information can be exploited.
If I can control your inbox, I can control your life. I can learn all the accounts you have (banking, social media, etc.), and then I can start taking over a number of those accounts using an email-based password reset.
An even more concerning reason is the interception of password reset emails. You don’t need an imagination to realize the damage a hacker can do with someone’s password reset email. Virtually any account can be hijacked with a password reset email, and it can all happen in minutes. It’s for this reason that companies push for users to adopt two-factor authentication.
Sounds scary, right? That’s why protecting your data is key when building an email program. To mitigate the risks associated with your email systems, follow these email security practices:
We access our email programs so often that we take account security for granted. Yet it’s just a thin veneer that keeps out bad actors.
Without additional protection methods, even a strong password is at risk of being cracked. That’s why login security has incorporated additional verification processes, like two-factor authentication or single sign-on.
One day, we’ll look back and laugh at how we believed a single password phrase would keep our email infrastructure safe.
Two-factor authentication, otherwise known as multi-factor authentication, requires two forms of proof to establish a user’s identity: something only the user knows (a password) and something only the user has (an authentication device).
Everyone who accesses your email program, regardless of role, should be authenticated using 2FA. This can be done through a third-party app on their phone, a one-time SMS code, or a physical security key.
Depending on how strict your security policy is, 2FA can challenge the user every time they sign on, or it can store the user’s IP address and device, then only prompt additional verification when they try to access from a new location.
Where 2FA adds complexity, single sign-on (SSO) actually makes life a little easier. That’s because we give our trust to an identity provider like Google, Apple, or Okta to handle personal authentication when users sign up for an account and log in.
Enabling SSO helps you manage application access across the organization and gives greater control over the use of third-party applications.
At Mailgun, we have a heuristic-based challenge system in place. So if, for example, someone logs in from a location they have never logged in before, we will block that login and require the user to use a one-time code sent to their email address.
To implement, you will have to navigate to the SAML configuration section in the ESP account settings and enter your identity provider’s details.
As a company scales, account management can very quickly become a high security risk. User settings enable account owners to keep everything organized and, most importantly, safe.
To maximize your email account security, implement the following security protocols:
DMARC, SPF, and DKIM are email authentication protocols required by ISPs to prove you are who you say you are. In turn, you’ll receive higher deliverability rates, and spammers will have a harder time impersonating you and leveraging your brand to send out scams and other types of phishing attacks.
Here are the protocols:
If you manage multiple senders, you must train and delegate this authentication enforcement to your technical account managers (TAMs).
Not having DKIM, DMARC, or SPF set up certainly makes it easier for impersonators to phish. It allows people to impact the reputation of your business. So if a spammer sends out a big blast as you and it goes through as valid, then
Your API keys are the keys to your castle. Whom would you trust with these keys? The soldiers? The servants? The cook?
You need to ensure that only the most security-conscious players in your organization have access to your API keys. Do this by assigning their IP addresses on the allowlist in your ESP settings panel. This can get tedious every time someone changes address, but it’s quick and could save you from a worst-case scenario.
Sometimes, your keys to the castle get cut a few too many times. Rotating your API keys, like changing your passwords, is simply good security practice. Finding the API key regeneration tool and rotating keys within your ESP settings should be a one-click job. Remember to keep your API key active for some time to allow you to update your code with the new key seamlessly.
Finally, if you use an ESP to manage multiple senders, having one API key for the entire account presents a security flaw. Domain Sending Keys allow you to create multiple API keys per domain for additional protection. These API keys are limited to sending messages and cannot make any changes or access information from your account API, which means if one application is compromised, the rest won’t be impacted. Instead, you simply rotate a Domain Sending Key for that one instance.
While most email senders use a centralized ESP to handle server infrastructure, there are still large verticles that hold sensitive data in-house, including governments, healthcare, and financial institutions. While having onsite infrastructure might be beneficial for certain use cases, it also comes with a fresh laundry list of security vulnerabilities.
Below are a few email security best practices to keep in mind, but make sure you enlist a dedicated server specialist to get a bespoke list of areas to monitor.
Every time your server communicates with a recipient’s server to send an email, the recipient’s server will perform a reverse DNS query. Their server is requesting your IP address and domain name (PTR record) to make sure they match their own records independently. While reverse DNS is more important for the receiver’s email security and is not a hard requirement, a server may reject your request, harming your deliverability.
Simple Mail Transfer Protocol (SMTP) is the most commonly used pipeline between servers and recipients. Unfortunately, SMTP is designed without a native security layer and is easily exploited. To ensure your pipeline is ironclad and protected, you need an encryption protocol, so every connection with a receiving server exchanges a security certificate before passing on encrypted information. That way, if the information is intercepted somewhere along the way, the attacker won’t be able to make sense of the information.
The diamond standard of SMTP encryption is SMTP Secure (SMTPS), proposed by the Internet Engineering Task Force (IETF), which uses transport layer security (TLS) as the connection layer. Alternatively, you can use the predecessor, which TLS builds upon – secure sockets layer (SSL). To prevent man-in-the-middle attacks or passive wiretapping, you’ll need an opportunistic TLS, which upgrades plain text connections to a secure encryption layer.
There’s nothing more time-saving than plugging third-party apps into your email software stack. At the same time, there’s nothing more dangerous. Third-party providers, while masters in their specialism, may not be as security conscious as you are.
With the advent of the devastating Log4j Java security vulnerability, many third-party software providers are still scrambling to patch their code. Like Jenga, once third-party code is inserted into your stack, it’s difficult to take it out without toppling the whole system.
Read the story of how the Mailgun security team worked around the clock to combat Log4j threats and pave the way for a safer emailing environment.
Let’s run through some best practices for implementing email plugins.
In today’s security climate, software patches are an everyday occurrence. If you fail to keep your plugins updated, your old code will be ripe for exploitation. Patch management is about staying ahead of the game, so you need a clear process to monitor new software versions from your suppliers. Make sure to test new patches in a staging environment and test the software before pushing any changes live to avoid disruption. Security services like Snyk make minimum changes to your locally installed package files in order to fix vulnerabilities when you can’t upgrade.
ESPs like Mailgun deliver SDKs in various programming languages to assist developers in integrating the platform into their apps. While integrating your ESP’s API, you may be tempted to source or build your own SDK, but doing so may open up major security flaws that your ESP will find difficult to assist with. Stick within the comfort of officially supported SDKs for a smoother, safer implementation, and make sure you’re using the latest version.
We’ve seen Log4j devastate the security space, but what other security threats are lurking around the corner? Even if you choose an ESP with a highly skilled security team, you may still use third-party applications that contain unknown vulnerabilities. It’s for this reason that you need a vulnerability management strategy to prevent potential email threats and stay one step ahead.
Your team is only as effective as your weakest link. Therefore, educating team members in the latest email security best practices is the best weapon in your arsenal. Not everyone needs to get a detailed training on the concrete features of different types of malware or ransomware, but they’ll all need to understand what actions put the company at risk and the potential consequences.
Distributing relevant information is the best way to boost engagement and lower information fatigue. Take the chance to undertake security awareness training in team presentations, start a Slack channel to discuss the latest developments, and encourage colleagues to share concerns.
Here is a list of email security topics that everyone in your email team should know about:
So there you have it – an exhaustive list of email security checks that you can perform quarterly or yearly to ensure you’re safe from attackers.
It’s clear that security is not about who crosses the finish line first – but an ongoing sprint of innovation. While an ESP takes a lot of the heavy lifting off your hands, it’s worth turning the focus onto their own security best practices. As time goes by, the ESP you initially chose may have gotten complacent and failed to implement new security features and patches.
So it’s good practice to analyze different ESPs’ approach to email security, including their data centers, certifications, and compliance. While change (or convincing stakeholders) is never easy, taking some time to compare and test an ESP’s security strategy could save you a lot of hassle down the road.
