Using MTA-STS to enhance email transport security and privacy


SMTP is broken by design. It comes from a time when communication partners trusted each other and the NSA was intercepting facsimiles and phone calls instead of internet traffic.

To enhance privacy, in 2002 RFC 3208 was added to the SMTP protocol. Unfortunately STARTTLS is only optional, it is not allowed to only accept encrypted connections.

The RFC states: A publicly-referenced SMTP server MUST NOT require use of the
STARTTLS extension in order to deliver mail locally

That is really problematic because it leaves SMTP vulnerable to MITM (Man-In-The-Middle) attacks as the connection is first established in clear text and using the STARTTLS command to establish an encrypted session. In that time window, an attacker is able to enforce a clear text communication by suppressing the STARTTLS command. DNS cache poisoning to hijack mail transfer by fake MX records is also an attack vector.

What to do to solve the problem? Well, DANE is a good solution but it requires DNSSEC to work as expected. Unfortunately DNSSEC is not available for all domains, so SMTP MTA Strict Transport Securityβ€œ (RFC 8461) was introduced.

It works similar like HTTP Strict Transport Security (HSTS). It works as “Trust on First Use” or also known as “TOFU”. The policy is announced by a DNS record (which will be cached) and will be retrieved by HTTPS.

MTA-STS is less secure than DANE, but it is a huge step forward.

Who is using it?

There are already some large scale mail providers that make use of MTA-STS. Here are a few of them:

  • Google mail
  • Yahoo
  • GMX

All of them are using the testing mode in the policy.

Announce your policy

The first step is to create the DNS records needed. A TXT record is used to announce the policy and a A (or AAAA) record for the hosting of the policy. For this example I use my test domain The data is STSv1 where v1 stand for the protocol number, where one is the first and only version at the moment. The ID is used to identify changes in the policy. It is good practice to use a timestamp in Zulu time format.

If you are using IPA for your DNS management, its very easy:

[root@ipa1 ~]# ipa dnsrecord-add _mta-sts --txt-rec="v=STSv1;id=$(date -u +'%Y%m%d%H%M%S')Z;"
  Record name: _mta-sts
  TXT record: v=STSv1;id=20181216095025Z
[root@ipa1 ~]#

Create a _smtp._tls record to announce where error reports are sent to. This is usually the postmaster of the domain. This is optional but recommended.

[root@ipa1 ~]# ipa dnsrecord-add _smtp._tls --txt-rec="v=TLSRPTv1;"
  Record name: _smtp._tls
  TXT record: v=TLSRPTv1;
[root@ipa1 ~]#

Be aware for the A/AAAA record(s) there is no _ (underscore) needed.

[root@ipa1 ~]# ipa dnsrecord-add mta-sts --aaaa-rec="2a01:4f8:141:14ce::9"
  Record name: mta-sts
  AAAA record: 2a01:4f8:141:14ce::9
[root@ipa1 ~]# 

The second step is to create a web server instance for https://mta-sts.<your-domain>:443. The x509 certificate must be valid (make sense, right? πŸ˜‰ ) otherwise it will not work. Free certificates can be created using It can also be a SAN (Subject Alternative Name). If you have a web mailer software installed on your mail server it can be reused.

In the web server instance you need to create a file containing your MTA-STS policy. The file contains the protocol version (STSv1), the mode, a list of your mail exchange servers and the maximum age caching your policy. The mode first should be testing so see if it working properly.

mkdir -p /var/www/html/

cat > /var/www/html/ << EOF
version: STSv1
mode: testing
max_age: 86400

Testing your Policy

There are two web based tests available.

    Does not work with IPv6 only setups, it caches DNS requests which is bad when you do some testing and need to correct DNS entries.
  • You need to register to be able to run multiple test. Checks a lot of related configuration parameters as well.

Fetch policies for Postfix on your SMTP Server

Postfix itself does not support MTA-STS. You need a little helper for that: postfix-mta-sts-resolver.

The software is in an early state, it lacks a bit of documentation. That probably will improve over time. The software itself works nicely, I do however don't have any experience on a large scale.

Unfortunately the stock Python version of RHEL7 is too outdated, but it will work with Python 3.6 which is available in the Software Collections.

yum -y install rh-python36-python-pip.noarch

Install postfix-mta-sts-resolver using PIP

/opt/rh/rh-python36/root/bin/pip install postfix-mta-sts-resolver

Create a user for the MTA-STS daemon:

useradd -c "Daemon for MTA-STS policy checks" mta-sts -s /sbin/nologin

Lets install a Systemd unit file:

cat > /etc/postfix-mta-sts.service << EOF
Description=Postfix MTA STS daemon 

# This is the ExecStart path for RHEL7 using python 36 from the Software collections.
# You may use a different python interpreter on other distributions


Enable the service on system startup:

systemctl enable postfix-mta-sts.service

There is a some configuration needed for the MTA-STS daemon itself.

cat > /etc/postfix/mta-sts-daemon.yml << EOF
port: 8461
  type: internal
    cache_size: 10000
  strict_testing: true
  timeout: 4
    strict_testing: false
    timeout: 4

I'm not sure what the configuration statement strict_testing means. Without setting it to true, it will not work when the policy is set to testing. Looks like it overrides the policy from testing to enforcing, handle with care!

Configuring Postfix

The last step is to let postfix know about MTA-STS. This is done with the configuration statement smtp_tls_policy_maps.

smtp_tls_policy_maps = socketmap:inet:

Also ensure that smtp_tls_CAfile is set to make use of your global CA-cert bundle, otherwise sending emails to TLS enabled servers will completely fail since STARTTLS is not opportunistic anymore!

smtp_tls_CAfile = /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

Nice to have: Increase the TLS log level to see if it is working:

smtp_tls_loglevel = 1

Testing your setup

mail:~# postmap -q socketmap:inet:

It should return something like:


Now send an email to a domain using MTA-STS and verify the Posfix log.

Dec 16 13:32:24 mail postfix/smtp[3583]: Verified TLS connection established to[2a00:1450:400c:c0c::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

It states Verified not just Trusted πŸ™‚


MTA-STS is a way that enhances security without DNSSEC. It is still in its early stage, IETF just released the first version of RFC 8461 in September 2018.

The critical point is the MTA-STS lookup to be done by the MTA. There is not much choice of software that can be used to achieve the goal of an MTA-STS capable MTA. I only made some tests with the most poplar MTA, Postfix, solutions for others like Sendmail and Exim may, or may not exist.

Another problem is the MTA-STS agent. It is a possible new attack vector for the bad guys, input sanitation for policies is key.

At the end of the day, lets give it a try and enable our MTAs out there.

Have fun πŸ™‚

Install and configure DKIM with Postfix on RHEL7

Signed Email


DKIM (Domain Keys Identified Mail) is a measure against email spoofing, Phishing and SPAM mails. Its easy to implement as you will learn in this article.

DKIM signs emails on the outgoing SMTP server, the receiving SMTP can verify the signature by looking up the mail._domainkey TXT DNS record of the respective domain to check if the email originates from that domain or if it is forged.

This howto can be used to implement DKIM on a SMTP server responsible for both, in- and out-going mails.

It has been standardized in 2007 as the successor of DomainKeys introduced by Yahoo in 2004. The latest standard revision is defined in defined in RFC 6376.


  • A running Postfix SMTP server
  • Access to the RHEL 7 Optional Software Channel/Repo (rhel-x86_64-server-optional-7)
  • EPEL repository available

Installing the Software

The dependencies will be installed automatically

mail:~# yum -y install opendkim

Enable DKIM on system startup

mail:~# systemctl enable opendkim.service

Configure OpenDKIM

Add/Uncomment the following lines in /etc/opendkim.conf

Socket inet:12341@localhost # Choose any free services number
Mode    sv
KeyTable        /etc/opendkim/KeyTable
SigningTable    refile:/etc/opendkim/SigningTable
InternalHosts   refile:/etc/opendkim/TrustedHosts
SignatureAlgorithm      rsa-sha256


In this file you configure a whitelist which domains and/or IP addresses are considered as trusted. This is usually just localhost.


Here the definition of your private key is set up


Here comes the definitions of email address patterns


Create the keypair

mail:~# mkdir /etc/opendkim/keys/
mail:~# cd /etc/opendkim/keys/
mail:~# opendkim-genkey -s mail -d
mail:~# chown opendkim:opendkim mail.private

The file /etc/opendkim/keys/ contains the public key which must be added to a DNS server authoritative for the domain. It looks as following:

mail._domainkey IN      TXT     ( "v=DKIM1; k=rsa; "
          "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9grq0kphBEtp9biB09/X0rS42s87yHbxq4DsR0SYBNGTdendDzsFaGZeQMu0bGkY488Jm2OjmT4vXBy7FvTdqFIUKvKWXl0uKbH6nn0NcJe/Q71YnmNsGI1/EFa+YXIHqdbUjCVoQOzXQ1UiB+jZiw/G0Hhs45FW9sR8LFwaj6QIDAQAB" )  ; ----- DKIM key mail for

If you are running (Free)IPA or Redhat Identity Management responsible as a DNS server, do the following:

[root@ipa1 ~]# ipa dnsrecord-add --txt-rec="p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC9grq0kphBEtp9biB09/X0rS42s87yHbxq4DsR0SYBNGTdendDzsFaGZeQMu0bGkY488Jm2OjmT4vXBy7FvTdqFIUKvKWXl0uKbH6nn0NcJe/Q71YnmNsGI1/EFa+YXIHqdbUjCVoQOzXQ1UiB+jZiw/G0Hhs45FW9sR8LFwaj6QIDAQAB" mail._domainkey

Configure Postfix

Thanks to Postfix Milter Implementation its a nobrainer to configure postfix:

mail:~# postconf milter_protocol=2
mail:~# postconf milter_default_action=accept
mail:~# postconf smtpd_milters=inet:localhost:12341
mail:~# postconf non_smtpd_milters=inet:localhost:12341

Restart the Services

mail:~# systemctl restart opendkim.service
mail:~# systemctl restart postfix.service


Write an email to to test your set up. A few seconds later you will get an automated response which shows the results.

Do not get confused by DomainKeys check: neutral in the test results, they are for the legacy Yahoo DomainKeys. The important stuff is DKIM.

You can also write your self an email and check the source of it, it will be looking simulat to this:

Return-Path: <>
Received: from (unknown [])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	(Authenticated sender:
	by (Postfix) with ESMTPSA id 3D1CFA34
	for <>; Sun, 19 Feb 2017 17:20:37 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.11.0 3D1CFA34
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail;
	t=1487521237; bh=asdfasdfasasdfasfasdfsadfsdaf=;
From: Joe Doe <>
Subject: test

Read further

Have fun! πŸ™‚

Integrate Dovecot IMAP with (Free)IPA using Kerberos SSO

Dovecot can make use of Kerberos authentication and enjoying Single-Sign-On when checking emails via IMAP. This post shows you how you enable this feature. With IPA its rather simple to do so.

First enroll your mail server to the IPA domain with ipa-client-install as described in various previously posted articles.

Creating a Kerberos Service Priciple

Ensure you have a Kerberos ticket as admin user

ipa1:~# kinit admin
Password for admin@EXAMPLE.COM: 
ipa1:~# ipa service-add imap/
Added service "imap/"
  Principal name: imap/
  Principal alias: imap/
  Managed by:

Fetch and install the Kerberos Keytab for Dovecot

Log in to your mailserver and get a Kerberos ticket as well:

mail:~# kinit admin
Password for admin@EXAMPLE.COM: 

Fetch the Keytab:

mail:~# ipa-getkeytab -s -p imap/ -k /etc/dovecot/dovecot-krb5.keytab
Keytab successfully retrieved and stored in: /etc/dovecot/dovecot-krb5.keytab

A common mistake is to have the wrong ownership and access rights on the keytab file.

mail:~# chown dovecot:dovecot /etc/dovecot/dovecot-krb5.keytab
mail:~# chmod 600 /etc/dovecot/dovecot-krb5.keytab

Edit the following lines in /etc/dovecot/conf.d/10-auth.conf

auth_krb5_keytab = /etc/dovecot/dovecot-krb5.keytab
auth_mechanisms = plain gssapi login
auth_gssapi_hostname =
auth_realms = EXAMPLE.COM
auth_default_realm = EXAMPLE.COM

A note about auth_mechanisms: Usually you dont want to use Kerberos only authentication but plain (over TLS/SSL) as well.


In /var/log/maillog check if you see messages similar to this:

Feb 19 11:43:25 mail dovecot: imap-login: Login: user=, method=GSSAPI, rip=, lip=, mpid=5195, TLS, session=<asdfasdfasdf>

How about LDAP?

Since identity lookup is done with sssd, LDAP integration is not needed in such a case, there is not benefit using LDAP.