Skip to main content
  1. Blog Posts/

A Crash Course in e-mail Security

··1119 words·6 mins

Introduction #

Hey all, this is more of a granular blog than usual here. As part of our backend overhaul, we’re upgrading our email security. Here, I’ll break down the email security standards in common circulation, and how we’re using them.

Before that, some fundamentals. Emails are sent via SMTP - the Simple Mail Transfer Protocol. This is a vestige of pre-Internet communication that has no inherent security or authentication; those are bolted on with the standards that’ll soon follow. Conversely, emails are often retrieved with IMAP - the Internet Message Access Protocol. Both IMAP and SMTP are encrypted in-transit as per RFC 8314. An SMTP transmission will look something like this, with a [c]lient sending to a [s]erver:

S: 220 ESMTP server-id
S: 250 greets
S: 250-8BITMIME #extension for non-ASCII character support
S: 250 OK
S: 250 OK
S: 250 OK
S: 354 start mail input; end with <CRLF>.<CRLF>
C: From: "Oscar Lupton" <>
C: To: "Steve Lupton" <>
C: Cc: <>
C: Date: Wed, 23 Jun 2077 21:09:19
C: Subject: Partnership with Arasaka Corporation
C: Hey Steve,
C: The sponsorship meeting with these guys went pretty well, should have the new implants over soon. Call me on a secure line to talk some more.
C: Cheers.
C: .
S: 250 OK
S: 221 closed conection

Finally, on DNS records. At a minimum, mail servers require “A” and “MX” records to reach the Internet (technically, “CNAME” records can substitute for the former, but that’ll wait for another blog post). These may look like:


Email security standards #

SPF - Sender Policy Framework #

SPF is a response to the fact that anyone can write any email address in the MAIL FROM part of an SMTP transmission. An admin will add a “TXT” record in the mail server’s DNS records, which may look like: v=spf1 ip4: a -all. The “a” is a test that will pass if the domain name given in the email resolves to the IP address given in this SPF policy. The ‘minus’ in “-all” means that every email that fails the prior test will be rejected.

Another feature of SPF is “INCLUDE”, which uses the policy of another domain to. For example, as MonSec uses Google Workspace, our record looks like:

TXTmonsec.iov=spf1 -allAuto

How to implement #

Most email hosts will provide an SPF record to copy into your DNS provider as a TXT record; copy this verbatim if you are unsure. If you are hosting from your own server, ensure that you have a static IP address, and that you set this in your SPF record accordingly.

DKIM - DomainKeys Identified Mail #

DKIM is essentially digital signatures for emails, proving that an email originated from a given domain. Like SPF, DKIM uses TXT records to associate data with a domain. A DKIM record contains a public key, with our record looking like:

TXTgoogle._domainkeyv=DKIM1; k=rsa; p=MIIBIjANBgk<...>Auto

When a mail server using DKIM sends an email, it includes a digital signature, generated with the sender’s private key and the contents of the email. With this, the receiving server can check the email against the public key to ensure the validity of the origin, and that the contents have not been modified.

How to implement #

As before, follow the instructions of your hosting provider. If running your own server, ensure that your DKIM private key is stored securely.

DMARC - Domain-based Message Authentication, Reporting, and Conformance #

DMARC uses the results of SPF and DKIM tests to guide a receiving server on how to handle an email. In the DMARC TXT record, an admin can specify whether emails from that domain must pass an SPF test, DKIM test, or both in order to be accepted by the recipient. The three policies that can be set are:

  • “none” - no requirements are set by the domain admin
  • “quarantine” - the receiver should take caution with the email, such as flagging as spam
  • “reject” - do not accept the email DMARC records also contain an email address to receive DMARC reports- these show which emails are failing SPF and DKIM, whether they be legitimate or malicious. Our DMARC record looks like:
TXT_dmarcv=DMARC1; p=quarantine; rua=mailto:dmarc-reports@monsec.ioAuto

How to implement #

This is another simple TXT record, which may be generated by your hosting provider. If you have a system for processing DMARC reports, such as a SIEM platform, you may have to enter a corresponding email address. Take care with using p=reject, as it may cause unexpected delivery failures without proper preparation.

SMTP MTA-STS - Mail Transfer Agent Strict Transport security #

MTA-STS mitigates MITM attacks by using TLS encryption for an entire email exchange. Traditionally, SMTP uses “opportunistic encryption” to switch from cleartext to encrypted comms (such as with the 250 STARTTLS code). There are two steps to implement this. The first is with a TXT record to indicate the usage of MTA-STS; our record looks like:


The ID number here is used by external servers to monitor for updates to your MTA-STS policy. The second step is publishing that policy. The policy must be a mta-sts.txt file, with our file as follows for reference:

version: STSv1
mode: testing
max_age: 604800

This must be uploaded to a subdomain starting with mta-sts, in directory .well-known. The MonSec policy, for example, is at

SMTP TLS Reporting #

MTA-STS works hand-in-hand with TLS reporting, which is similar in some regards to DMARC reporting. TLS reports will indicate failures in TLS appplication, and will be sent to the address elected in the record. Our record looks as such:


These configurations may be generated by your hosting provider, and the MTA-STS policy should be set to testing until ensuring that everything works as expected.

Conclusion #

While we don’t touch on end-to-end encryption standards like PGP and S/MIME, these are the simplest ways to comply with modern email security standards.

References #

Standards #

Guides #