Mailserver Security

When it comes to SSL/TLS configuration, the focus tends to be on web servers rather than on mail servers. But mail servers should also benefit from a strong SSL/TLS configuration with valid certificates. Mail servers that have been configured completely incorrectly quickly become apparent in IMAP and POP3 protocols, but insufficient standards are often set in server-to-server communication. Frequently, invalid certificates are accepted or no certificates at all are required because a connection is more important than security!

SSL/TLS configuration for Postfix

The following is an excerpt from the Postfix Main Configuration, which may however change at any time. Very important options are smtpd_tls_security_level and smtp_tls_security_level, which are set to “none” by default. This means that the server will never use TLS. Therefore, these options should always be set to may or encrypt.

# TLS parameters
tls_high_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!MEDIUM:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_medium_cipherlist = !aNULL:ALL:!EXPORT:!LOW:!DES:!3DES:!MD5:!RC4:@STRENGTH
tls_low_cipherlist = !aNULL:ALL:!EXPORT:!DES:!3DES:!MD5:!RC4:@STRENGTH

smtpd_tls_cert_file = /etc/postfix/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/postfix/ssl-cert-snakeoil.key
smtpd_tls_auth_only = yes
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_ciphers = medium
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_dh1024_param_file = /etc/postfix/dh4096.pem
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtpd_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_ciphers = high
smtp_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4
smtp_tls_protocols = !SSLv2, !SSLv3, TLSv1, TLSv1.1, TLSv1.2
smtp_tls_CApath = /etc/ssl/certs
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

SSL/TLS configuration for Dovecot

This is an excerpt from the Dovecot configuration and shows a possible configuration of the SSL/TLS parameters for Dovecot.

# DH parameters length to use.
ssl_dh_parameters_length = 4096

# SSL protocols to use.
ssl_protocols = !SSLv2 !SSLv3

# SSL ciphers to use

# Prefer the server's order of ciphers over client's.
ssl_prefer_server_ciphers = yes

Sender Policy Framework (SPF)

With the help of SPF (RFC 7208), it is possible to validate if a server which wants to deliver an email is actually authorized to send emails from the corresponding domain.
For example, the server establishes a connection to the server and tries to deliver an email to it from On the basis of SPF, the server can verify if the server is a valid email server for the domain
The corresponding SPF record exists in the DNS system and can look similar to the following: IN TXT "v=spf1 ip4: ip6:2001:db8::1 a ~all"

That means that the email is accepted if one of the following conditions is met:

  • the IP address of the server lies within or 2001:db8::1
  • the DNS A record matches the IP address of the server

In all other cases the email must undergo further checks (which can be defined by the user).

DomainKeys Identified Mail (DKIM) Signatures

The idea behind DomainKeys Identified Mail (DKIM, RFC 6376) is to check that an email was not changed during transit. To ensure this, the header, the content and the attachments of an email message are signed. However, the signature is not applied to the entire header, as certain fields can change during transmission of an email. The RFC proposes to sign the following values:

  • From (REQUIRED)
  • Reply-To
  • Subject
  • Date
  • To, Cc
  • Resent-Date, Resent-From, Resent-To, Resent-Cc
  • In-Reply-To, References
  • List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, List-Owner, List-Archive

DKIM signatures are stored in the header of an email message, the field is called DKIM-Signature. The value of this field includes multiple key/value pairs. The most important are:

  • v: DKIM version
  • a: algorithm (e.g. rsa-sha256)
  • d: signing domain (origin Domain)
  • s: selector

A receiving mail server can request the current domain key via DNS, based on the domain and the selector. The DNS entry looks similar to the following: IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB" )

If an email with the header

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;
s=mail; t=1498137281;

is received, the corresponding TXT DNS record which refers to the key is

Domain-based Message Authentication, Reporting and Conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) expands the two mechanisms DKIM and SPF. If a DKIM header is not present or a SPF record is not found, these two procedures do not trigger any actions and the email is treated as standard. DMARC offers the option to specify how to treat an email which is missing one or both procedures. DMARC is also a little stricter where DKIM handling is concerned, e.g. the From address field must match the domain in the DKIM signature field. Another point facilitated by DMARC is the reporting of incorrectly sent emails. Reports can be requested from receiving mail servers.
In the same way as DKIM, DMARC is published in the DNS. A possible entry looks similar to the following:

Where the individual values have the following meaning:

  • v: Version
  • p: Policy for this domain
  • sp: Policy for subdomains
  • pct: Percentage of “bad” emails, from which the policy is to be applied
  • rua: DMARC report URI address


Manual tests can be carried out with openssl. These are only basic commands, which represent the contents of the server certificate in text form. Cipher suites can also be tested, but since this involves long and numerous commands, it is recommended that existing services (e.g. Hardenize) are used for this purpose. If this is not desirable or is not possible from a technical perspective, SSL decoder can also be installed locally, because the software is Open Source and available on Github.

  • SMTP
$ openssl s_client -connect -starttls smtp 2>/dev/null </dev/zero | openssl x509 -noout -text
  • IMAP
$ openssl s_client -connect -starttls imap 2>/dev/null </dev/zero | openssl x509 -noout -text

Additional features such as SPF and DMARC can be tested very easily by simply checking the DNS records:

# SPF Record
$ dig +short TXT
"v=spf1 ip4: ip6:2001:db8::1 a ~all"

$ dig +short TXT
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDitIQ2xCvJOxGoP/bAGY1pSSrOmtJTMF3ku2i+TaLjXR25XwESFk4E0OprYhbjBYB+QWPaiDrMn2UdadaFJIQTyXF8b5WzgkAifJ7nEc74uNf7p5rb/eDgblrNubmnImrRgd07YiB85vNoZdd/q6dn3BjGGjDpN6M1nLAO0LIlkQIDAQAB"

$ dig +short TXT
"v=DMARC1; p=reject;"

Several providers are suitable for carrying out more comprehensive tests including an evaluation of the contents, for example Hardenize or MX Toolbox.

Further information

It is also worth noting that DNS-based Authentication of Named Entities (DANE) can be used with mail servers as well. This however is beyond the scope of this blog post and will be dealt with in another post. There are also excellent How-To guides for mail servers, and the following two should be mentioned here:


  • MX Toolbox
  • Hardenize