Email Security for startups

On one hand, email is probably your most important channel of communication with users. On the other hand, email is old technology. It was built back in the day when people on the internet trusted each other. Email protocols were not built with security in mind, but over time, there have been layers and layers of technologies stacked over email.

By now, it’s nearly impossible to run your own mail servers.

If you are a startup, you mostly want to use a service that handles email for you. There are tons of options out there: Amazon SES, SendGrid, MailGun, etc; you are probably using one of these.

Even if they might be using a managed service, I still see so many startups making mistakes with their email configuration. I wanted to talk about a few steps you should take from a security perspective. (Additional benefit: These steps may even improve your delivery rates!)

Note: There are a ton of abbreviations used in this blog post. I’ve tried to make it as approachable as possible, but please do give me your feedback if you couldn’t follow along!

Use TLS!

Using TLS (Transport Layer Security) with SMTP is basically like using HTTPS — you encrypt your connection to the mail server. In today’s day and age, it is crucial that you use TLS.

This mistake is usually made by people who run their own SMTP servers (or SMTP relays), which are often mis-configured in some way. Any hosted email provider will usually use TLS by default.

If you don’t use TLS:

• The email message is transmitted in cleartext for some part of the journey to the receiver. So, attackers can read the emails you’re sending your customers and steal credentials, etc.
• Providers like Gmail will show a prominent security warning on your emails to your users. You will lose user trust.

Here’s what a warning from Gmail looks like:

If you click on the dropdown icon, Gmail will explicitly mention that the email was not encrypted:

If your emails do not have TLS, make sure to switch it on right now! This should be one of the simplest steps in this guide.

Add SPF Records

Remember, email is a protocol that has built up hacks over decades of usage. SMTP runs on a system of trust — it is technically possible for you to send an email with any ‘from’ address.

In practice, every email server (on the receiver’s end) will use SPF to validate that you are in fact authorised to send that email.

SPF (Sender Policy Framework) works on the domain level and identifies which hosts (IP addresses) are allowed to send email on that domain.

• You publish an SPF policy on your domains’s DNS — in the form of TXT records.
• The SPF policy will identify the set of IP addresses that are allowed to send email for any ‘From’ address on your domain
• The SPF policy also defines what the receiver should do for any email sent from un-authorised IP addresses. Note: it is up to the receiver to actually follow your recommendation — but most public email providers like Gmail or Outlook will honour your SPF policy.

If you do not set SPF records,

1. You have a security issue. It is possible to spoof emails coming from your domain.
2. Users will see a ‘via some provider’ notice on your emails; this message might confuse the user about your identity:

SPF records are simple to set up. Here is a sample SPF record:

"v=spf1 mx include:amazonses.com -all"

Here’s what it means:

• “v=spf1” — header, defines the SPF version.
• “mx” — allows any server mentioned in your MX records to send mail on your domain.
• “include:amazonses.com” — includes the SPF policy[1] published by Amazon SES. This means that any IP authorised by SES can send email for your domain[2].
• “-all” — disallow all other IP addresses from sending email. This is a ‘hard’ failure. Often, providers will tell you to use “~all”, which denotes a ‘soft’ failure. From a security perspective, you want to disallow all other IP addresses, and you should use “-all”.

You can read the full record syntax here. Usually, your email service provider will help you set up the right records — but you probably need to understand the syntax in order to make adjustments manually.

For example, if you are using two providers, you need to understand the record syntax to allow both of them to send mail.

Configure DKIM

Email is a peer to peer protocol. DomainKeys Identified Mail (DKIM) is a way to verify the authenticity of your emails.

With DKIM, you publish a public key in your DNS records. Emails sent by you will contain a digital signature that can be verified against your public key.

DKIM serves two purposes:

• Asserting that you (your mail servers, or some service you have authorised) had sent this email, since this email has been signed with your digital signature.
• Ensuring that the email cannot be tampered with in-transit. The signature will report a hash mismatch if the email is tampered with in any manner.

Enabling DKIM is the right thing to do for the security of your users.

Other implications:

• Absence of DKIM will be a signal to spam filters, who are much more likely to mark your email as spam.

• Providers like gmail will show your email sender with a question mark instead of the standard sender avatar, like the screenshot above.

Each provider has guides to setting up DKIM. Usually, the provider will give you a TXT record that you should publish as-is. These steps for enabling DKIM are usually specific to your email provider, please follow them carefully!

Enable DMARC

DMARC stands for “Domain-based Message Authentication, Reporting and Conformance”, which is a mouthful.

DMARC is basically a feedback and control mechanism for SPF and DKIM. Once you publish a DMARC policy on your domain, email services like Gmail will give you statistics on the SPF and DKIM compliance level of your emails.

You can also control what they will do for messages that do not comply with your policies — ignore them, mark them as spam, or completely reject them.

DMARC requires you to:

• Publish a DMARC policy on your domain, as a TXT record at _dmarc.your-domain.com
• This policy also defines an email endpoint where DMARC reports will be mailed to. These reports are in a structured format.

I strongly recommend using a service like Postmark’s DMARC digests to consume these reports. Postmark will help you set up DMARC properly and get weekly statistics.

To get started with, your DMARC policy should be be something like:

v=DMARC1; p=none; pct=100; rua=dmarc-reports@domain.com;

This configures DMARC in reporting-only mode (p=none, take no action on emails that fail DKIM or SPF) for all your emails (pct=100). The DMARC reports will be mailed to the specified email address.

You should keep it in this mode for a few weeks, to understand how many of your emails fail validation. Use this time to go and fix your SPF / DKIM policies to make your emails more compliant.

Once you’re confident of your email setup, you can start being stricter:

v=DMARC1; p=quarantine; pct=50; rua=dmarc-reports@domain.com;

This policy tells the receiving mail servers to apply stricter measures on non-complying email (p=quarantine, basically mark the email as spam) for 50% of your email traffic (pct=50).

Once you are fully satisfied with your email configuration, you can enable a very strict policy:

v=DMARC1; p=reject; pct=100; rua=dmarc-reports@domain.com;

This policy will reject all emails that do not comply. Make sure that you do this gradually — this is hardcore mode, you cannot make mistakes once this is enabled.

Following these steps is a good start. If you want to learn about SPF, DKIM, DMARC etc in more detail, I strongly recommend reading Postmark’s Guides on these topics — they’ve the best I’ve read.

Footnotes

1. You can use the command line to see the TXT records on any domain. For example: $ dig txt amazonses.com
2. This is a broad include. Anyone with a SES account can send email on your domain. Some providers give you dedicated sending IP addresses, and let you specify SPF records with those specific IP addresses.