MTA-STS Policy File Template: Securing Your Email Transport

As engineers responsible for email infrastructure, you're likely familiar with DMARC and its role in authenticating sending domains. DMARC helps prevent impersonation by verifying SPF and DKIM. However, DMARC doesn't directly secure the transport of email between mail servers. That's where MTA-STS comes in. This article will walk you through crafting and deploying an MTA-STS policy file, a crucial step in ensuring your email communications remain confidential and untampered during transit.

The Problem: Opportunistic TLS and MITM Attacks

Traditionally, SMTP (Simple Mail Transfer Protocol) relies on opportunistic TLS. When one mail server (MTA) attempts to send an email to another, it first tries to establish a TLS-encrypted connection. If TLS fails for any reason – perhaps due to a misconfiguration, a network issue, or a malicious actor – the sending server will often fall back to an unencrypted connection and deliver the email in plain text.

This fallback mechanism, while designed for reliability, creates a significant security vulnerability. An attacker performing a Man-in-the-Middle (MITM) attack can actively strip TLS from the connection, forcing the email to be sent unencrypted. This allows them to read, modify, or even block the email without the sender or receiver being aware of the compromise. Even without an active attack, if a server's TLS certificate is invalid or untrusted, the connection might proceed unencrypted, leaving your data vulnerable to passive eavesdropping.

While DMARC authenticates the sender, it offers no protection against such transport-layer attacks. Your DMARC-validated email could still be read by an attacker if the TLS connection is compromised.

Enter MTA-STS: Mandating TLS and Trust

MTA-STS, or Mail Transfer Agent - Strict Transport Security, is a standard designed to address the vulnerabilities of opportunistic TLS for SMTP. It's essentially HSTS (HTTP Strict Transport Security) for email. MTA-STS provides two critical security enhancements:

  1. Mandatory TLS: It instructs sending MTAs to only deliver mail to your domain over a secure, TLS-encrypted connection. There is no fallback to plain text. If TLS cannot be established, the email is not delivered.
  2. Certificate Validation: It requires sending MTAs to validate your server's TLS certificate against a trusted Certificate Authority (CA). Self-signed or expired certificates will cause delivery to fail, preventing attackers from using invalid certificates to impersonate your mail servers.

By implementing MTA-STS, you're telling the world: "If you send email to my domain, it must be encrypted with valid TLS, or don't send it at all."

How MTA-STS Works: A Quick Overview

For MTA-STS to work, you need to publish two pieces of information:

  1. A DNS TXT record: This record, published under _mta-sts.yourdomain.com, signals to other MTAs that your domain supports MTA-STS and tells them where to find your policy file.
  2. An MTA-STS policy file: This file, served via HTTPS from a specific URL (mta-sts.yourdomain.com/.well-known/mta-sts.txt), contains the actual rules for how other MTAs should interact with your domain.

When a remote MTA wants to send email to your domain, it first checks for the DNS TXT record. If found, it then fetches the policy file via HTTPS. It caches this policy for a specified duration (max_age). Subsequent email deliveries to your domain will then strictly adhere to the rules defined in your policy.

Crafting Your MTA-STS Policy File: The Template

The MTA-STS policy file is a simple text file with key-value pairs, one per line. It must be UTF-8 encoded. Here are the essential fields:

  • version: STSv1: This is a mandatory field and should always be STSv1 for the current version of the standard.
  • mode:: This defines how strict the policy is.
    • testing: This is the recommended starting mode. Sending MTAs will still attempt to establish a TLS connection and validate certificates, but if the STS check fails, they will still deliver the email opportunistically (i.e., fall back to unencrypted or deliver despite certificate issues). Failures should be logged, ideally via TLS-RPT reports (which is a companion standard for reporting MTA-STS failures).
    • enforce: This is the desired end-state. Sending MTAs must adhere to the policy. If TLS cannot be established or certificate validation fails, the email will be rejected and not delivered.
    • none: This disables MTA-STS for your domain. Use this if you need to temporarily roll back or fully disable the policy.
  • mx:: This field specifies the MX hosts that are covered by this policy. You should list all your active MX records here. You can use a wildcard (*.yourdomain.com) to cover all subdomains of your primary MX host, which is often convenient and recommended, provided your certificates cover them. Each MX record should be on its own mx: line.
  • max_age:: This specifies how long (in seconds) sending MTAs should cache your policy. A longer max_age means fewer policy fetches but also slower propagation of policy changes.

Real-World Example: A Basic Policy File

Let's say your domain is example.com, and your mail is handled by mail.example.com and mail2.example.com. Here's what your initial MTA-STS policy file (mta-sts.txt) might look like