Email Security Best Practices
Email security includes providing three fundamental guarantees:
- Authenticity: The email really comes from the claimed origin.
- Integrity: The contents of the email have not been altered in transit.
- Confidentiality: Prying eyes have been prevented from reading the email via strong encryption.
To achieve these goals, email providers have worked to develop security standards. Email was originally developed via an insecure suite of protocols on the early internet, but using modern security protocols can make it a lot safer. That’s why we’ve prepared a series of illustrated, detailed guides to the most important, need-to-know email security protocols and their respective best practices.
How a DMARC Policy Works
Before diving into detail on best practices, we’ll introduce some basic terms to prevent confusion later on.
|SPF||Sender Policy Framework. Uses a DNS comment to prove that an email was sent from the server it claims (using the “from” address in the envelope).|
|DKIM||DomainKeys Identified Mail. Leverages public key cryptography and DNS to prove that the “from” address in the email body is correct and that the email was not tampered with.|
|DMARC||Domain-based Message Authentication, Reporting and Conformance. Establishes a reporting mechanism for SPF and DKIM violations.|
|MTA-STS||SMTP Mail Transfer Agent Strict Transport Security. Enables mandatory TLS encryption for incoming mail.|
Let’s go through these technologies one by one to get an idea of how each contributes to the overall picture of email security.
Let’s say I’m sending mail from an IP, and in the envelope of the email, I claim that it’s from thegov.test. How would the recipient know whether my mailserver’s IP is authorized to send from thegov.test? One solution is SPF. Using SPF, I create a TXT record in thegov.test’s DNS saying “these IP addresses are allowed to send mail for this domain.” Only if the email is sent from one of these IP addresses does it pass SPF.
For a more thorough explanation of SPF, check out our blog post on it: What is SPF?
Because SPF only verifies the “envelope” from the address and not the one in the email headers that’s actually visible to recipients, admins found it inadequate to protect users from fraud. Three specific issues arose:
- It was necessary to know that an email hadn’t been modified by a server in transit.
- If an email is sent from a mail forwarder, the IP won’t match SPF.
- There was a need to be able to verify the “from address” inside the email.
Because an allowed sender might still forge which user they were on the system, or pretend to be from another system entirely, it was necessary to create a more robust solution to fraudulent email. That’s where DKIM comes in. DKIM uses public-key cryptography to ensure that an email is from the server it claims to be. Additionally, signing is used to verify that the message has not been changed by any intermediaries during delivery.
For a deeper understanding of DKIM, check out What is DKIM?
What happens to an email that fails DKIM or SPF? Instead of letting it silently fail, we can set up a reporting and enforcement protocol called DMARC. Using DMARC allows us to gain visibility for debugging and early attack detection and to provide a central source of authority for what to do with non-compliant mail.
A more thorough introduction can be found at What is DMARC?
MTA-STS is used to ensure that all incoming mail uses TLS encryption, to prevent prying eyes from intercepting messages. Like all of the other security protocols outlined here, MTA-STS is published via DNS and is an easily configured, convenient way to improve your email security practices.
Now that we’ve taken a glance at the bigger picture, you’re ready to learn about the many more specific considerations for email security that administrators and security managers should consider. This guide provides additional information and context to help administrators make those decisions.
SPF is simple enough, but admins can get caught up over which attribute does what. Instead of copying and pasting mystery code from the internet, the article on SPF Record Syntax thoroughly breaks down and explains the features and functionality available in an SPF record.
Learn how to set up an MTA-STS policy file and publish it via DNS. This protocol is the only one that implements the “third” guarantee of email security mentioned in the introduction: confidentiality. Because SMTP (the protocol for sending email) does not offer TLS support by default, it’s still possible for senders to transmit email without any encryption. This is not acceptable because any “man in the middle” who intercepts the traffic will be able to read the conversation.
MTA-STS insists on encryption to mitigate precisely this risk.
DKIM can be quite the labyrinth of concepts to learn, but we’ve found that, of all the associated concepts, the selector is the most difficult for many admins to comprehend. The selector is a part of DKIM used to identify where the public key will be hosted in DNS.
DMARC and DKIM are commonly confused because they’re both popular security mechanisms for email. As we noted before, DKIM cryptographically verifies the integrity and authenticity of emails. DMARC, however, offers reporting and enforcement controls for DKIM as well as for SPF. The above article explores these differences in greater depth, highlighting how exactly these two protocols differ.
The above content should be a great head start at understanding the nitty gritty of mastering email security best practices. But that’s not the end! More chapters are on the way, so be sure to check back every now and then for new articles similar to those above that dive deep into technical topics that are of importance to email admins. Our mission is to make your security stronger, and we look forward to giving you more top-quality content.