Email Security Best Practices and Protocols
Email security best practices include 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 email security protocols and standards.
Email was originally developed via an insecure suite of protocols on the early internet, but using modern email 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.
Email Security Best Practices
Let’s begin with a brief overview that summarizes the ways that you can follow email security best practices.
- Adhere to digital “hygiene”, such as multifactor authentication (MFA)
- Deploy a strong DMARC policy
- Protect your brand with BIMI
- Train employees in antiphishing awareness
- Consult with external auditors to find holes in your security
This series of articles will focus primarily on how technical protocols like DMARC can help you make email safer. If you want to know how accompanying strategies like BIMI and antiphishing, check out our guides on those topics: Guide to BIMI, and Guide to Phishing Prevention.
How a DMARC Policy Works
Before diving into detail on email security best practices, we’ll introduce some basic terms to prevent confusion later on.
|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).
|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.
|Domain-based Message Authentication, Reporting, and Conformance. Establishes a reporting mechanism for SPF and DKIM violations.
|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?
Success Rate Frame
Marketplace Apps Identified
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.
Refresh your knowledge of SPF, DKIM, and DMARC and follow the instructions to configure them on Office 365 for your email service.
Understand the failure scenarios of Sender Policy Framework (SPF) and learn how to avoid issues other than when detecting fraudulent behavior.
Understand the semantic and syntactic differences between softfail and hardfail. Learn when to use each through best practices and uses cases.
Learn how to defend against spear phishing by using email security protocols, vendor-specific security integrations, browser extensions, and layered security
Addressing this error requires two steps—confirming that the DMARC record actually is missing and then publishing a DMARC policy for your domain.
Learn how to deploy DKIM on Office 365 and critical limitations admins should understand as important factors in its security landscape.
If this warning comes up, your policy either doesn’t exist or is set to monitoring only. Monitoring is great, yet it’s problematic for email security—makes it easier for hackers to forge.
Learn Must-Know Email Security Best Practices
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 email security stronger, and we look forward to giving you more top-quality content.
Subscribe to our LinkedIn Newsletter to receive more educational contentSubscribe now