Email security includes providing three fundamental guarantees:

1. Authenticity: The email really comes from the claimed origin.
2. Integrity: The contents of the email have not been altered in transit.
3. 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.

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 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.

SPF

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?

DKIM

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:

1. It was necessary to know that an email hadn’t been modified by a server in transit.
2. If an email is sent from a mail forwarder, the IP won’t match SPF.
3. 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?

DMARC

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

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.

Chapter 1: SPF Record Syntax 

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.

Chapter 2: MTA-STS

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.

Chapter 3: DKIM Selector

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.

Chapter 4: DMARC vs DKIM

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.

Chapter 5: DMARC Office 365

Refresh your knowledge of SPF, DKIM, and DMARC and follow the instructions to configure them on Office 365 for your email service.

Chapter 6: SPF Failure

Undertand the failure scenarios of Sender Policy Framework (SPF) and learn how to avoid issues other than when detecting a fraudulent behavior.

Chapter 7: SPF Softfail vs Hardfail

Understand the semantic and syntactic differences between softfail and hardfail. Learn when to use each through best practices and uses cases.

Chapter 8: What Helps Protect from Phishing

Learn how to defend against speark phishing by using email security protocols, vendor-specific security integrations, browser extensions, and layered security

Chapter 9: Fixing the Error “No DMARC Record Found”

Addressing this error requires two steps – confirm that the DMARC record actually is missing and then publishing a DMARC policy for your domain.

Chapter 10: DKIM Office 365: Tutorial & Instructions

Learn how to deploy DKIM on Office 365 and critical limitations admins should understand as important factors in its security landscape.

Chapter 11: How to Configure DMARC Policy to Reject or Quarantine

If this warning comes up, your policy either doesn’t exist or is set to monitoring only. Monitoring is great, yet its problematic for email security – makes it easier for hackers to forge.

Conclusion

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.